* Re: Loop at starting pid 164, tty '': '/sbin/getty'
From: ramkumarj Ramkumar @ 2007-12-24 9:20 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-embedded
In-Reply-To: <20071224040915.GA20380@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]
Hi Olof,
Thanks a lot for replying to the query posted. It works now. Initially I had
created the device file tts/0 instead of ttyS0 and still faced the same
issue. Now I have the ttyS0 created and created tty0 and also modified the
inittab as below,
--------------------------------------------------------------------------
Original Config ( Not Working )
--------------------------------------------------------------------------
::sysinit:/etc/init.d/rcS
#::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/sbin/getty 38400 tts/0
Created the following devices in /dev through
mknod -m 660 console c 5 1
mknod -m 660 xsa b 254 0
mknod -m 660 xsa1 b 254 1
mknod -m 660 xsa2 b 254 2
mknod -m 660 xsa3 b 254 3
mkdir tts
cd tts
mknod -m 660 0 b 4 64
cd ..
mknod -m 660 null c 1 3
-------------------------------------------------------------------------
Working Config
-------------------------------------------------------------------------
# cat inittab
::sysinit:/etc/init.d/rcS
#::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/sbin/getty -L ttyS0 38400 vt100
Created the following devices in /dev
# ls -al
drwxr-xr-x 5 root root 1024 Jan 1 00:00 .
drwxr-xr-x 17 root root 1024 Dec 21 2007 ..
crw--w--w- 1 root root 5, 1 Jan 1 00:00 console
srw-rw-rw- 1 root root 0 Jan 1 00:00 log
crw-rw---- 1 root root 1, 3 Dec 21 2007 null
drwxr-xr-x 2 root root 1024 Dec 21 2007 pts
drwxr-xr-x 2 root root 1024 Dec 21 2007 shm
drwxr-xr-x 2 root root 1024 Dec 21 2007 tts
crw--w--w- 1 root root 4, 0 Dec 24 2007 tty0
crw------- 1 root root 4, 64 Jan 1 00:12 ttyS0
brw-rw---- 1 root root 254, 0 Dec 21 2007 xsa
brw-rw---- 1 root root 254, 1 Dec 21 2007 xsa1
brw-rw---- 1 root root 254, 2 Dec 21 2007 xsa2
brw-rw---- 1 root root 254, 3 Dec 21 2007 xsa3
#
Now I m able to see the login prompt :) .
I would be very grateful if the following questions could be addressed,
1. Does the inittab format changed for Linux 2.6. The old one was from
mkrootfs (which I think is pretty old). I could see some changes in the
"respawn" line.
2. Is it required to run the tty0 along with ttyS0. Is this is mandatory. I
assumed all these days console and ttyS0 should be sufficient.
3. A very basic question : What is the clear difference between ttyS0 ( UART
Driver ), console and tty0. To my understanding, ttyS0 is the first port
UART 's driver (for 16550/8250) which deals with the hardware as such by
writing and reading the registers. tty0 is virtual console, something to do
with telnet sessions. But I dont clearly understand why console and tty0 are
both required or not. Please correct me if my understanding is wrong.
Merry Christmas.
Thanks and Regards,
Ramkumar
On Dec 24, 2007 12:09 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> On Sat, Dec 22, 2007 at 04:51:16PM +0800, ramkumarj Ramkumar wrote:
>
> > I m trying to run Linux 2.6 ( From Grant) on ML-403. I used the
> > busybox-1.7.2. During booting, I found the following logs and it keeps
> > trying to respawn the getty.It keeps looping and I never see the login
> > prompt. Am I missing something.
> >
> > process '/sbin/getty 38400 tts/0' (pid 163) exited. Scheduling it for
> > restart.
>
> Do you have a /dev/ttys/0? First serial port is normally /dev/ttyS0.
>
>
> -Olof
>
[-- Attachment #2: Type: text/html, Size: 5595 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2007-12-24 11:01 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20071223230342.GA20636@localhost.localdomain>
Hi David,
>> + localbus@8000000 {
>> + compatible = "betaresearch,dbox2-localbus";
>
> Is this bus interface really board specific? I would have thought the
> localbus bridge would have been part of the SoC in which case the
> compatible string should mention the 823 rather than the dbox.
>
>> + #address-cells = <1>;
>
> It's also usual for these localbus things, to have #address-cells of
> 2, with the chipselect explicitly present as the first cell.
The setup of the localbus is already done in the boot loader. However, i'll
recode this to reflect the mapping of addresses to chipselects.
>> + #size-cells = <1>;
>> + reg = <8000000 18000000>;
>> +
>> + ranges = <0 8000000 18000000>;
>> +
>> + enx@0 {
>> + compatible = "c-cube,enx";
>
> What are these mysterious enx, gtx, etc. devices? Some comments might
> be nice.
Those are mostly devices for video processing (MPEG demux, on screen display, MPEG decoder, etc).
Drivers (for ARCH=ppc) are available on cvs.tuxbox.org with GPL license. A work in progress port
to ARCH=powerpc is at git://git.bocc.de/dbox2.git.
>> + // Port D is LCD exclusive. Don't export as GPIO
>> + CPM1_PIO: pio@970 {
>> + compatible = "fsl,cpm1-pario";
>> + reg = <970 180>;
>> + num-ports = <3>;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + lcd@970 {
>> + reg = <970 10>;
>> + compatible = "samsung,ks0713";
>
> Is this representing an LCD controller, or the display itself. Either
> way I'm surprised there's something here in the SoC that has a
> compatible string that's not "fsl,something"
It's a LCD controller wired to PortD. PortD is used for four 1bit lines
and one 8bit bus.
Would something like this be better?
CPM1_PIO: pio@970 {
compatible = "fsl,cpm1-pario";
reg = <970 180>;
num-ports = <4>;
#gpio-cells = <2>;
};
lcd@0 {
compatible = "samsung,ks0713";
gpio-parent = <&CPM1_PIO>;
gpio-port = 3;
}
And then run gpio_request() for all lines on this port in the driver?
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-24 12:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476DD544.2050807@freescale.com>
On Sat, Dec 22, 2007 at 09:25:56PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >2. QE SCCs (slow UCCs, used as an UARTs)
>
> I a posted a driver that provides this support, I'm just waiting for
> Kumar to apply it.
Yup. I've seen it, thanks. I'm going to test it as well. ;-)
> What revision of the 8360 does this board use?
MPC8360E, Rev: 21. Are you aware of any known issues on this chip
regarding UCC serials?
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-24 12:17 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476DD5DF.5020806@freescale.com>
On Sat, Dec 22, 2007 at 09:28:31PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >+ qe@e0100000 {
> >+ #address-cells = <1>;
> >+ #size-cells = <1>;
> >+ compatible = "fsl,qe";
> >+ ranges = <0 0xe0100000 0x00100000>;
> >+ reg = <0xe0100000 0x480>;
> >+ /* filled by u-boot */
> >+ brg-frequency = <0>;
>
> You need "bus-frequency" here too
Hm..
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
^^ David Gibson suggested to get rid of it.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCHv2] powerpc: DBox2 Board Support
From: Arnd Bergmann @ 2007-12-24 12:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <476E9930.6000205@scram.de>
On Sunday 23 December 2007, Jochen Friedrich wrote:
> This patch adds device tree source, default config and setup code for
> DBox2 devices.
Cool stuff. I used to have one of these boxes myself, maybe I should
get one again when it's hitting mainline.
Is this already a complete port, or do you also need some device
drivers or boot wrapper code to go along with it?
> + memory {
> + device_type = "memory";
> + reg = <0 2000000>;
> + };
I thought there are both models with 32MB and 16MB available.
If that's true, shouldn't this be filled out by the boot loader?
> +#
> +# Frame buffer hardware drivers
> +#
> +# CONFIG_FB_OF is not set
> +# CONFIG_FB_VGA16 is not set
> +# CONFIG_FB_S1D13XXX is not set
> +# CONFIG_FB_IBM_GXT4500 is not set
> +# CONFIG_FB_VIRTUAL is not set
> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
No hardware framebuffer driver? Can't you use
the FB_OF driver by default? I'd guess that a
set-top box without output is rather pointless ;-)
> +# DOS/FAT/NT Filesystems
> +#
> +CONFIG_FAT_FS=y
> +CONFIG_MSDOS_FS=y
> +CONFIG_VFAT_FS=y
> +CONFIG_FAT_DEFAULT_CODEPAGE=437
> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> +# CONFIG_NTFS_FS is not set
What media can you connect that use the FAT file system?
I'd guess that if you can get rid of these, you can also
disable the entire block layer, which should free up
some kernel memory.
> @@ -0,0 +1,30 @@
> +/*
> + * A collection of structures, addresses, and values associated with
> + * the DBox2.
> + *
> + * Author: (c) 2007 Jochen Friedrich
> + *
> + * This file is licensed under the
> + * terms of the GNU General Public License version 2. This program is licensed
> + * "as is" without any warranty of any kind, whether express or implied.
> + */
> +
> +#ifdef __KERNEL__
> +#ifndef __ASM_DBOX2_H__
> +#define __ASM_DBOX2_H__
You don't need the #ifdef __KERNEL__ any more if you don't have
any user-visible parts in the header. Just leave it out of the
list of exported header files (as you already do).
> +
> +/* Vendor information in BR Bootloader
> + */
> +
> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
> +
> +enum dbox2_mid {
> + DBOX2_MID_NOKIA = 1,
> + DBOX2_MID_PHILIPS = 2,
> + DBOX2_MID_SAGEM = 3,
> +};
> +
> +enum dbox2_mid dbox2_get_mid(void);
Can you move this functionality from the kernel to the boot wrapper?
It looks like this is something that really belongs into the device
tree.
> +static void __init dbox2_setup_arch(void)
> +{
> + struct device_node *np;
> + static u8 __iomem *config;
> +
> + cpm_reset();
> + init_ioports();
> +
> + /* Enable external IRQs for AVIA chips */
> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x00000c00);
This smells like a hack. What are AVIA chips, and shouldn't
their driver enable the IRQs?
> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
> + np = of_find_node_by_path("/localbus@8000000/enx@0");
> + else
> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +
> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
> + else
> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +}
What is this code for? Why do you want to detach nodes from the device
tree that have been put in there by the boot loader?
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .name = "soc", },
> + { .name = "cpm", },
> + { .name = "localbus", },
> + {},
> +};
Shouldn't this check for 'compatible' properties instead of 'name'?
> +static int __init declare_of_platform_devices(void)
> +{
> + /* Publish the QE devices */
> + if (machine_is(dbox2))
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
This is a candidate for the new platform_initcall stuff.
I also once did a patch that let you have a default 'of_bus_ids'
member in the ppc_md. I never got around to submitting that, but
if there is interest, I can dig it out again.
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
> +
Don't hide #includes or platform specific #defines in #ifdef.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: update 440EP(x)/440GR(x) identical PVR issue workaround
From: Valentine Barshak @ 2007-12-24 12:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712212056.41798.sr@denx.de>
Stefan Roese wrote:
> Hi Valentine,
>
> On Friday 21 December 2007, Valentine Barshak wrote:
>>> Good catch. I'll have to look more closely to see if anything else
>>> would be broken by changing the cpu node name from "PowerPC,xxxx@0" to
>>> "cpu@0".
>>>
>>> josh
>> Looks like we need a u-boot update for 405Ex Kilauea board.
>> Mine (U-Boot 1.3.0-rc3-gccc2fe86-dirty (Oct 25 2007 - 12:18:41))
>> fails to boot with new cpu node changes:
>>
>> Uncompressing Kernel Image ... OK
>> Booting using the fdt at 0x400000
>> le to update property /cpus/PowerPC,405EX@0:timebase-frequency,
>> err=FDT_ERR_NOTFOUND
>> Unable to update property /cpus/PowerPC,405EX@0:clock-frequency,
>> err=FDT_ERR_NOTFOUND
>
> Already done. :) Please take a look at the current implementation in the
> for-1.3.2 branch of the u-boot-ppc4xx custodian repo:
>
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-ppc4xx.git;a=shortlog;h=for-1.3.2
>
> This works for both cpu node names.
Great, thanks :)
Valentine.
>
> Best regards,
> Stefan
^ permalink raw reply
* Re: [PATCH 1/21] [POWERPC] Reworking machine check handling and Fix 440/440A
From: Josh Boyer @ 2007-12-24 16:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071223193210.1d06f33f@zod.rchland.ibm.com>
On Sun, 23 Dec 2007 19:32:10 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 21 Dec 2007 15:39:21 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Index: linux-merge/arch/powerpc/kernel/traps.c
> > ===================================================================
> > --- linux-merge.orig/arch/powerpc/kernel/traps.c 2007-12-20 11:34:43.000000000 +1100
> > +++ linux-merge/arch/powerpc/kernel/traps.c 2007-12-20 11:35:40.000000000 +1100
>
> [snip]
>
> > -#elif defined (CONFIG_E500)
> > + return 0;
> > +}
> > +#elif defined(CONFIG_E500)
> > +int machine_check_e500(struct pt_regs *regs)
>
> This...
>
> > +{
> > + unsigned long reason = get_mc_reason(regs);
> > +
> > printk("Machine check in kernel mode.\n");
> > printk("Caused by (from MCSR=%lx): ", reason);
> >
> > @@ -403,7 +416,14 @@ static int generic_machine_check_excepti
> > printk("Bus - Instruction Parity Error\n");
> > if (reason & MCSR_BUS_RPERR)
> > printk("Bus - Read Parity Error\n");
> > -#elif defined (CONFIG_E200)
> > +
> > + return 0;
> > +}
> > +#elif defined(CONFIG_E200)
> > +int machine_check_e200(struct pt_regs *regs)
>
> ... and this cause build failures for most of the mpc8xxx defconfigs.
> The reason is that e200 and e500 are both lumped under CONFIG_FSL_BOOKE
> in cputable.c, but you have them segregated more here. I've added a
> fix that just does CONFIG_FSL_BOOKE here to match cputable.c.
Actually, reverse that. There are other places where e200 and e500 are
separated by ifdefs, so I made cputable.c match the rest.
josh
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Kumar Gala @ 2007-12-24 16:53 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <476D61DB.2090201@scram.de>
>
> diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/
> mpc8xx.h
> index 2be014b..b6fd7d6 100644
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
> +
> #ifdef CONFIG_PCMCIA_M8XX
> extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> #endif
is this really needed? if so why. we should work towards not having
to do this going forward.
(I cant believe its needed since dbox2.h doesn't seem to have anything
defined we'd need anywhere else).
- k
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Timur Tabi @ 2007-12-24 17:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071223152613.GA4817@lixom.net>
Olof Johansson wrote:
> Sounds like a board rework document on your support site is the right
> place for this.
Except that no one would know to look there. I don't even know who to
contact to get that kind of information on that site.
> We normally don't document board reworks required in
> the linux sources, do we?
I do, if I can find a discrete place for it. The patch for my QE UART
driver has a similar comment in the DTS for the 8323E MDS.
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Timur Tabi @ 2007-12-24 17:39 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, david
In-Reply-To: <20071224121715.GB7903@localhost.localdomain>
Anton Vorontsov wrote:
>> You need "bus-frequency" here too
>
> Hm..
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
>
> ^^ David Gibson suggested to get rid of it.
It looks to me like he's just suggesting that we rename it to
clock-frequency. That may be a better name, but for now changing it
will only confuse U-Boot and any other code that's looking for
bus-frequency. If we want to rename it, I suggest we do that in a
different patch. Having some DTS files with "bus-frequency" and others
with "clock-frequency" is bad.
^ permalink raw reply
* Re: Build breakage on powerpc with 2.6.24-rc6-mm1
From: Olof Johansson @ 2007-12-24 19:27 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, akpm, balbir, linux-kernel, linuxppc-dev
In-Reply-To: <20071224044912.GA10690@suse.de>
On Sun, Dec 23, 2007 at 08:49:12PM -0800, Greg KH wrote:
> > Hi Greg, do you even build with your patches applied?
>
> For the power architecture, no, I do not. I used to, but my cross-build
> box died and I haven't taken the time to set it all up again.
Crosstool makes it really easy. It's demo-powerpc-970.sh will build a
toolchain that can build both 32- and 64-bit powerpc kernels. It's got
a demo-s390.sh as well, but I haven't tried that one myself.
-Olof
^ permalink raw reply
* Re: Loop at starting pid 164, tty '': '/sbin/getty'
From: Olof Johansson @ 2007-12-24 19:38 UTC (permalink / raw)
To: ramkumarj Ramkumar; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030712240120m30d68b37g8b5f099294c6d769@mail.gmail.com>
Hi,
On Mon, Dec 24, 2007 at 05:20:10PM +0800, ramkumarj Ramkumar wrote:
> I would be very grateful if the following questions could be addressed,
>
> 1. Does the inittab format changed for Linux 2.6. The old one was from
> mkrootfs (which I think is pretty old). I could see some changes in the
> "respawn" line.
Inittab isn't tied to the kernel, but to the init process. So no, it
should not have changed between 2.4 and 2.6.
> 2. Is it required to run the tty0 along with ttyS0. Is this is mandatory. I
> assumed all these days console and ttyS0 should be sufficient.
tty0 is normally one of the vga consoles. It shouldn't be needed if all
you have is serial.
> 3. A very basic question : What is the clear difference between ttyS0 ( UART
> Driver ), console and tty0. To my understanding, ttyS0 is the first port
> UART 's driver (for 16550/8250) which deals with the hardware as such by
> writing and reading the registers. tty0 is virtual console, something to do
> with telnet sessions. But I dont clearly understand why console and tty0 are
> both required or not. Please correct me if my understanding is wrong.
ttyS<x> are normally 8250-compatible uarts, yes. pts/<x> is remote
connections such as telnet or ssh-based ones. tty<x> are normally the
local vga consoles.
-Olof
^ permalink raw reply
* i2c device for a linux 2.6 in XUPV2P
From: Josep Maria Batlle @ 2007-12-24 21:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi all,
I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300 config
file).
Now I am trying to use the i2c in the user-space. First of all: is it
possible?
My first attempts have not worked. I have made this:
1) I enable "I2C Support" and "I2C device interface" in the kernel
recompilation.
2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
3) then I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel documentation) that returns this errno
message: "No such device".
I have tried to use the device number 1, 2, 3, 4 but these have not worked.
I have tried to use the device "i2cn" but not worked. I have tried to use
all the BSP's from the EDK (7.1i) and then only the "xparameters_ml300.h" in
the compilation. After all of this, now I am modifying the RFS for "mdev"...
Somebody can tell me what I am doing wrong if this use is possible?
I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox 1.7.2.
Thanks.
[-- Attachment #2: Type: text/html, Size: 1142 bytes --]
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Olof Johansson @ 2007-12-24 23:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476FEB43.8050507@freescale.com>
On Mon, Dec 24, 2007 at 11:24:19AM -0600, Timur Tabi wrote:
> Olof Johansson wrote:
>
> > Sounds like a board rework document on your support site is the right
> > place for this.
>
> Except that no one would know to look there.
Why do you expect people to look at the device tree source file instead?
It seems even more remote to me.
> I don't even know who to contact to get that kind of information on
> that site.
That's a pretty lame excuse. :)
> > We normally don't document board reworks required in
> > the linux sources, do we?
>
> I do, if I can find a discrete place for it. The patch for my QE UART
> driver has a similar comment in the DTS for the 8323E MDS.
Are freescale customers really used to going to the linux device tree
sources to find out how to modify their boards to achieve certain
functionality with their eval boards?! I guess you guys are taking the
"device trees are used to describe the hardware" statement to it's
fullest extent.
-Olof
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: David Gibson @ 2007-12-25 1:04 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <476F918F.4050909@scram.de>
On Mon, Dec 24, 2007 at 12:01:35PM +0100, Jochen Friedrich wrote:
> Hi David,
>
> >> + localbus@8000000 {
> >> + compatible = "betaresearch,dbox2-localbus";
> >
> > Is this bus interface really board specific? I would have thought the
> > localbus bridge would have been part of the SoC in which case the
> > compatible string should mention the 823 rather than the dbox.
> >
> >> + #address-cells = <1>;
> >
> > It's also usual for these localbus things, to have #address-cells of
> > 2, with the chipselect explicitly present as the first cell.
>
> The setup of the localbus is already done in the boot loader. However, i'll
> recode this to reflect the mapping of addresses to chipselects.
Sure, that's normal. But to the greatest extent possible, the device
tree should describe the hardware, not the configuration that's been
set up by the firmware/bootloader. It's usually not possible to get
all the way there, but encoding the chipselect information this way
gets you closer. It means that if you later need to adapt the device
tree to the same board with a firmware that does things differently,
only the "ranges" property should need changing. Or, if you later
need a kernel port to a version with no-firmware or minimal firmware
that doesn't configure the bus, the necessary information is in the
tree to configure the bridge.
> >> + #size-cells = <1>;
> >> + reg = <8000000 18000000>;
> >> +
> >> + ranges = <0 8000000 18000000>;
> >> +
> >> + enx@0 {
> >> + compatible = "c-cube,enx";
> >
> > What are these mysterious enx, gtx, etc. devices? Some comments might
> > be nice.
>
> Those are mostly devices for video processing (MPEG demux, on screen display, MPEG decoder, etc).
> Drivers (for ARCH=ppc) are available on cvs.tuxbox.org with GPL license. A work in progress port
> to ARCH=powerpc is at git://git.bocc.de/dbox2.git.
Ok. Again, some comments so a casual read of the tree tells you
roughly what they are would be nice.
> >> + // Port D is LCD exclusive. Don't export as GPIO
> >> + CPM1_PIO: pio@970 {
> >> + compatible = "fsl,cpm1-pario";
> >> + reg = <970 180>;
> >> + num-ports = <3>;
> >> + #gpio-cells = <2>;
> >> + };
> >> +
> >> + lcd@970 {
> >> + reg = <970 10>;
> >> + compatible = "samsung,ks0713";
> >
> > Is this representing an LCD controller, or the display itself. Either
> > way I'm surprised there's something here in the SoC that has a
> > compatible string that's not "fsl,something"
>
> It's a LCD controller wired to PortD. PortD is used for four 1bit lines
> and one 8bit bus.
I'm still kind of confused here. Does the pio@970 node above
represent the PortD controller? If the LCD controller is accessed
solely through PortD, then it should be a child of the PortD node.
At present, pio and lcd have overlapping reg resources which is
certainly wrong.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* 4xx: for-2.6.25 branch created
From: Josh Boyer @ 2007-12-25 1:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Just in time for the holidays, I created my for-2.6.25 branch. It
contains the commits below. I'll let it sit for a couple days given
the timing of things, and ask Paul to pull a bit later.
If I've missed something, let me know.
josh
Benjamin Herrenschmidt (19):
[POWERPC] Reworking machine check handling and Fix 440/440A
[POWERPC] 4xx: Improve support for 4xx indirect DCRs
[POWERPC] 4xx: PLB to PCI-X support
[POWERPC] 4xx: PLB to PCI 2.x support
[POWERPC] 4xx: PLB to PCI Express support
[POWERPC] 4xx: PCI support for Ebony board
[POWERPC] 4xx: Add early udbg support for 40x processors
[POWERPC] 4xx: EP405 boards support for arch/powerpc
[POWERPC] 4xx: Add PCI to Walnut platform
[POWERPC] 4xx: Wire up PCI on Bamboo board
[POWERPC] 4xx: Wire up 440EP USB controller support to Bamboo board
[POWERPC] 4xx: Adds decoding of 440SPE memory size to boot wrapper library
[POWERPC] 4xx: Add mfspr/mtspr inline macros to 4xx bootwrapper
[POWERPC] 4xx: Add CPR0 accessors to boot wrapper
[POWERPC] 4xx: Rework clock probing in boot wrapper
[POWERPC] 4xx: Base support for 440SPe "Katmai" eval board
[POWERPC] 4xx: remove bogus "ranges" property in Bamboo EBC node
[POWERPC] 4xx: PCI-E Link setup improvements
[POWERPC] pci32: 4xx embedded platforms want to reassign all PCI resources
Hugh Blemings (1):
[POWERPC] 4xx: Base support for 440GX Taishan eval board
Josh Boyer (11):
[POWERPC] 4xx: Fix 440grx setup function to call 440A fixup
[POWERPC] 4xx: Include missing header
[POWERPC] 4xx: libfdt and pci fixes for Rainier
[POWERPC] 4xx: Rename CPU nodes to avoid dtc incompatibility
[POWERPC] 4xx: Update Kilauea, Rainier, and Walnut defconfigs
[POWERPC] 4xx: Mark of_bus structures as __initdata
[POWERPC] Conditionally compile e200 and e500 platforms in cputable
[POWERPC] Remove unneeded variable declarations from mpc837x_mds
[POWERPC] 4xx: Use machine_device_initcall for bus probe
[POWERPC] 4xx: Minor coding style cleanups for 4xx bootwrapper
[POWERPC] 4xx: Update defconfigs
Stefan Roese (11):
[POWERPC] 4xx: Add 440SPe revA runtime detection to PCIe
[POWERPC] 4xx: Fix TLB 0 problem with CONFIG_SERIAL_TEXT_DEBUG
[POWERPC] 4xx: Add 405EX CPU type needed for EMAC support on Kilauea
[POWERPC] 4xx: Change Kilauea dts to support new EMAC device tree properti
[POWERPC] 4xx: Add Kilauea PCIe support to dts and Kconfig
[POWERPC] 4xx: Set ibpre for 405EX in 4xx PCIe driver
[POWERPC] 4xx: Add aliases node to 4xx dts files
[POWERPC] 4xx: Change Kilauea PCIe bus ranges in dts file
[POWERPC] 4xx: Add AMCC Makalu board support to platforms/40x
[POWERPC] 4xx: Makalu dts
[POWERPC] 4xx: Makalu defconfig
Valentine Barshak (12):
[POWERPC] 4xx: 440EPx Sequoia USB OHCI DTS entry
[POWERPC] 4xx: 440GRx Rainier bootwrapper.
[POWERPC] 4xx: 440GRx Rainier DTS.
[POWERPC] 4xx: 440GRx Rainier board support.
[POWERPC] 4xx: 440GRx Rainier default config
[POWERPC] 4xx: make UIC use generic level irq handler
[POWERPC] 4xx: rework UIC cascade irq handling
[POWERPC] 4xx: Correct 440GRx machine_check callback
[POWERPC] 4xx: Add PCI entry to 440EPx Sequoia DTS.
[POWERPC] 44x: Sequoia and Rainier updates for 2.6.25
[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround
[POWERPC] 4xx: Add PCI entry to 440GRx Rainier DTS.
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Timur Tabi @ 2007-12-25 20:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071224231042.GA4588@lixom.net>
Olof Johansson wrote:
> Are freescale customers really used to going to the linux device tree
> sources to find out how to modify their boards to achieve certain
> functionality with their eval boards?! I guess you guys are taking the
> "device trees are used to describe the hardware" statement to it's
> fullest extent.
Well, I've always been a rebel.
Honestly, I just thought it would be harmless and a lot easier (for me)
than trying to convince some documentation dude to write it up and
publish it.
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Timur Tabi @ 2007-12-25 20:44 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071224121546.GA7903@localhost.localdomain>
Anton Vorontsov wrote:
> Yup. I've seen it, thanks. I'm going to test it as well. ;-)
If they work for you, please let Kumar know.
> MPC8360E, Rev: 21. Are you aware of any known issues on this chip
> regarding UCC serials?
Yep. You need a microcode upload. My patches describe everything.
^ permalink raw reply
* Re: More patches added to for-2.6.25 and master branches of powerpc.git
From: Benjamin Herrenschmidt @ 2007-12-25 21:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18282.19253.485799.233476@cargo.ozlabs.ibm.com>
> [POWERPC] Disable PCI IO/Mem on a device when resources can't be allocated
Can you revert that one ? I messed up the flags (mixed up IORESOURCE_*
flags with command register bits).
I'll send a fixed up version when I'm back.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Olof Johansson @ 2007-12-26 2:18 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47716B3A.9050008@freescale.com>
On Tue, Dec 25, 2007 at 02:42:34PM -0600, Timur Tabi wrote:
> Olof Johansson wrote:
>
>> Are freescale customers really used to going to the linux device tree
>> sources to find out how to modify their boards to achieve certain
>> functionality with their eval boards?! I guess you guys are taking the
>> "device trees are used to describe the hardware" statement to it's
>> fullest extent.
>
> Well, I've always been a rebel.
>
> Honestly, I just thought it would be harmless and a lot easier (for me)
> than trying to convince some documentation dude to write it up and publish
> it.
Heh. Well, it's up to Kumar what to do about this one upstream, it
just seemed like a weird choice to document board reworks in the device
tree comments.
Having it somewhere that sticks to google's database is better than
nothing at all, I suppose. :)
-Olof
^ permalink raw reply
* (no subject)
From: chengk_thomson @ 2007-12-26 9:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 61 bytes --]
linuxppc-embedded@ozlabs.org
2007-12-26
chengk_thomson
[-- Attachment #2: Type: text/html, Size: 882 bytes --]
^ permalink raw reply
* Re: Time for cell code reshuffle?
From: Ishizaki Kou @ 2007-12-26 11:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, cbe-oss-dev, arnd, jk
In-Reply-To: <1198357215.6686.8.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote:
> > > It seems platforms/cell should have the shared and/or generic code,
> > and the other
> > > stuff moved into a new platform directory, but is it worth the
> > effort?
> >
> > There is very little code in platforms/cell that can not be generic,
> > so I think
> > it's not worth splitting it. The only IBM blade specific files are
> > cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything
> > else could
> > be shared by about any generic implementation without a hypervisor.
>
> Another option is to have:
>
> platforms/celleb -> platforms/beat
>
> and withing platforms/cell, rename blade specific files to
> something (can't find what, works on CAB too) and add celleb
> "bare metal" files.
>
> A platform directly doesn't have to deal with one platform. For example,
> platforms/44x contains a lot of board support.
>
> Now, one question is how far can we merge celleb support with the common
> blade/CAB code...
Celleb-native needs own machine definition and setup code due to HW
and FW deferences between CellBlade and Celleb. Of course, because
Celleb-native and Celleb-Beat use some codes commonly, we need a place
to put Celleb common codes.
But I don't know your idea is better or not.
Best regards,
Kou Ishizaki
^ permalink raw reply
* [PATCH] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-26 13:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: paulus, linuxppc-dev
This fixes the boot image wrapper script to not fail the kernel
build if mkimage is not available.
As some distributions don't ship the mkimage program and some people are not
interested in uboot images anyway, we don't want to fail the whole kernel
build process because of this unneeded dependency.
Simply drop an error message, but don't fail the build.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Josh Boyer is working on merging mkimage into the kernel tree.
Until that happened, please merge the patch below into the mainline kernel
to avoid build breakage for people without installed uboot tools.
Index: wireless-2.6/arch/powerpc/boot/wrapper
===================================================================
--- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-23 20:10:07.000000000 +0100
+++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-23 20:22:41.000000000 +0100
@@ -195,6 +195,14 @@ if [ -n "$version" ]; then
fi
case "$platform" in
+cuboot* | uboot)
+ if ! [ -x mkimage ]; then
+ echo "mkimage not available. Can not create $platform image."
+ exit 0
+ fi
+esac
+
+case "$platform" in
uboot)
rm -f "$ofile"
mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
^ permalink raw reply
* Re: [PATCH] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-26 14:47 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <200712261453.41849.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> + if ! [ -x mkimage ]; then
What is this supposed to test?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCHv2] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2007-12-26 15:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Scott Wood, linuxppc-dev, linux-kernel, linuxppc-embedded
In-Reply-To: <200712241318.02299.arnd@arndb.de>
Hi Arnd,
>> This patch adds device tree source, default config and setup code for
>> DBox2 devices.
>
ia > Cool stuff. I used to have one of these boxes myself, maybe I should
> get one again when it's hitting mainline.
>
> Is this already a complete port, or do you also need some device
> drivers or boot wrapper code to go along with it?
Currently, it needs the u-boot patches from cvs.tuxbox.org and some
external device drivers (however, they can all be loaded as modules).
The port is complete enough to get a console on the serial port and
a rootfs either on flash or on nfs.
>> + memory {
>> + device_type = "memory";
>> + reg = <0 2000000>;
>> + };
>
> I thought there are both models with 32MB and 16MB available.
> If that's true, shouldn't this be filled out by the boot loader?
IIRC, the cuImage wrapper overwrites this with the boot loader
parameters.
OTOH, the memory is part of the localbus (CS1). Should it be a child
of localbus in this case?
>> +#
>> +# Frame buffer hardware drivers
>> +#
>> +# CONFIG_FB_OF is not set
>> +# CONFIG_FB_VGA16 is not set
>> +# CONFIG_FB_S1D13XXX is not set
>> +# CONFIG_FB_IBM_GXT4500 is not set
>> +# CONFIG_FB_VIRTUAL is not set
>> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
> No hardware framebuffer driver? Can't you use
> the FB_OF driver by default? I'd guess that a
> set-top box without output is rather pointless ;-)
I didn't check FB_OF. On Dbox2, the avia driver creates a
framebuffer device.
>> +# DOS/FAT/NT Filesystems
>> +#
>> +CONFIG_FAT_FS=y
>> +CONFIG_MSDOS_FS=y
>> +CONFIG_VFAT_FS=y
>> +CONFIG_FAT_DEFAULT_CODEPAGE=437
>> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
>> +# CONFIG_NTFS_FS is not set
>
> What media can you connect that use the FAT file system?
>
> I'd guess that if you can get rid of these, you can also
> disable the entire block layer, which should free up
> some kernel memory.
There are two mods available using the block layer, although currently i don't
support any of them:
1. using the GPIO lines of the modem port, it's possible to connect a SD card.
It might be possible to use it using the GPIO SPI driver (but it would need
some glue code to create a platform device).
2. using the memory expansion port and CS2, there is an IDE interface available
with a CPLD acting as localbus/IDE bridge. There is a device driver for
ARCH=ppc.
Unfortunately, i don't own any of these modifications.
>> +
>> +/* Vendor information in BR Bootloader
>> + */
>> +
>> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
>> +
>> +enum dbox2_mid {
>> + DBOX2_MID_NOKIA = 1,
>> + DBOX2_MID_PHILIPS = 2,
>> + DBOX2_MID_SAGEM = 3,
>> +};
>> +
>> +enum dbox2_mid dbox2_get_mid(void);
>
> Can you move this functionality from the kernel to the boot wrapper?
> It looks like this is something that really belongs into the device
> tree.
OK.
>> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
>> + np = of_find_node_by_path("/localbus@8000000/enx@0");
>> + else
>> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
>> +
>> + if (np) {
>> + of_detach_node(np);
>> + of_node_put(np);
>> + }
>> +
>> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
>> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
>> + else
>> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
>> +
>> + if (np) {
>> + of_detach_node(np);
>> + of_node_put(np);
>> + }
>> +}
>
> What is this code for? Why do you want to detach nodes from the device
> tree that have been put in there by the boot loader?
There are small differences between the 3 manufacturers. I guess this
should go to the boot wrapper, as well.
This is even more important if the localbus uses #address-cells = <2>, as
the differen manufacturers set up the address mapping for CS3, CS5 and CS7
differently.
>> +static void __init dbox2_setup_arch(void)
>> +{
>> + struct device_node *np;
>> + static u8 __iomem *config;
>> +
>> + cpm_reset();
>> + init_ioports();
>> +
>> + /* Enable external IRQs for AVIA chips */
>> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x00000c00);
>
> This smells like a hack. What are AVIA chips, and shouldn't
> their driver enable the IRQs?
No. This just configures the Pin as IRQ input. Maybe, the new GPIO
functions could be used for this, instead. Then it could be done
in the driver (the driver should't directly mess with SIU internals).
>> +static struct of_device_id __initdata of_bus_ids[] = {
>> + { .name = "soc", },
>> + { .name = "cpm", },
>> + { .name = "localbus", },
>> + {},
>> +};
>
> Shouldn't this check for 'compatible' properties instead of 'name'?
I copied this from mpc885ads_setup.c.
>> +static int __init declare_of_platform_devices(void)
>> +{
>> + /* Publish the QE devices */
>> + if (machine_is(dbox2))
>> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
>> +
>> + return 0;
>> +}
>> +device_initcall(declare_of_platform_devices);
>
> This is a candidate for the new platform_initcall stuff.
>
> I also once did a patch that let you have a default 'of_bus_ids'
> member in the ppc_md. I never got around to submitting that, but
> if there is interest, I can dig it out again.
That would be nice :)
>> --- a/include/asm-powerpc/mpc8xx.h
>> +++ b/include/asm-powerpc/mpc8xx.h
>> @@ -23,6 +23,10 @@
>> #include <platforms/8xx/mpc885ads.h>
>> #endif
>>
>> +#if defined(CONFIG_DBOX2)
>> +#include <platforms/8xx/dbox2.h>
>> +#endif
>> +
>
> Don't hide #includes or platform specific #defines in #ifdef.
As soon as the manufacturer info is included in the device tree,
dbox2.h is no longer needed.
Thanks,
Jochen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox