sporadic kernel panic during boot (MPC8xx, FEC)
On 04/11/2002 05:31 PM, Tom Rini wrote: >On Thu, Apr 11, 2002 at 09:23:11AM +0200, Steven Scholz wrote: >> >> Christian Pellegrin wrote: >> >> > not really sure this will help you, but I had similar problem (spurious >> > hangs during boot/insmod on 823 and 850 MPCs). The ppc mm for 8xx in 2.4 >> > repository is broken, use that in 2.4-devel that works fine. AFA net >> > devices are concerned check that rx start is done in open and not in init >> > since linux doesn't like packets before a device is opened. >> >> Thanks for your reply. >> >> I got the kernel from the linuxppc_2_4_devel tree using >> >> bk export ... -rv2.4.18 >> >> So I guess I do have a 2.4-devel. Right? > >No. -rv2.4.18 got you 2.4.18 from kernel.org, no PPC changes at all. > You mean it's identical to linux-2.4.18.tar.gz from kernel.org? [I'm just curious what I really get with the above command.] Thanks, Wolfgang. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
building glibc eabi vs. elf
Hello all.
I am running into problems building glibc 2.2.5 using my powerpc-eabi-gcc
compiler. I had no problems using this compiler to build newlib, ppcboot, and
the linux kernel. I am getting the feeling, though, that I should be using
powerpc-elf-gcc instead.
I believe my current build error is because in sysdep.h __ELF__ is not defined
and therefore some macros don't get defined either. Is this sounding familiar
to anyone? Here's the output of "make":
make -r PARALLELMFLAGS="" CVSOPTS="" -C ../../src/glibc-2.2.5 objdir=`pwd` all
make[1]: Entering directory `/usr/src/glibc-2.2.5'
make -C csu subdir_lib
make[2]: Entering directory `/usr/src/glibc-2.2.5/csu'
powerpc-eabi-linux-gnu-gcc -B/usr/local/powerpc-eabi/bin/
../sysdeps/powerpc/elf/start.S -c -I../include -I.
-I/usr/build/glibc-2.2.5/csu -I.. -I../libio -I/usr/build/glibc-2.2.5
-I../sysdeps/powerpc/elf -I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/powerpc -I../sysdeps/unix/sysv/linux/powerpc
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common
-I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/powerpc/fpu -I../sysdeps/powerpc -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/powerpc/soft-fp -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/generic -nostdinc -isystem
/usr/local/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.0.4/include -isystem
d:/src/linux-2.4.18/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h -DHAVE_INITFINI -DASSEMBLER
-I/usr/build/glibc-2.2.5/csu/. -Wa,-mppc -o /usr/build/glibc-2.2.5/csu/start.o
../sysdeps/powerpc/elf/start.S: Assembler messages:
../sysdeps/powerpc/elf/start.S:28: Error: Unrecognized opcode:
`l(start_addresses):'
../sysdeps/powerpc/elf/start.S:30: Warning: rest of line ignored; first ignored
character is `('
../sysdeps/powerpc/elf/start.S:31: Warning: rest of line ignored; first ignored
character is `('
../sysdeps/powerpc/elf/start.S:32: Warning: rest of line ignored; first ignored
character is `('
../sysdeps/powerpc/elf/start.S:33: Error: Unrecognized opcode:
`asm_size_directive(L(start_addresses))'
../sysdeps/powerpc/elf/start.S:36: Error: Unrecognized opcode: `entry(_start)'
../sysdeps/powerpc/elf/start.S:47: Error: syntax error; found `(' but expected
`,'
../sysdeps/powerpc/elf/start.S:47: Error: junk at end of line:
`(start_addresses)@ha'
../sysdeps/powerpc/elf/start.S:48: Error: junk at end of line: [EMAIL
PROTECTED](8)'
../sysdeps/powerpc/elf/start.S:50: Error: syntax error; found `(' but expected
`,'
../sysdeps/powerpc/elf/start.S:50: Error: junk at end of line:
`(__libc_start_main)'
make[2]: *** [/usr/build/glibc-2.2.5/csu/start.o] Error 1
make[2]: Leaving directory `/usr/src/glibc-2.2.5/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/usr/src/glibc-2.2.5'
make: *** [all] Error 2
Any helpful tips would be appreciated.
Pete
P.S. My powerpc-eabi-ld can create an ELF image.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 05:03:41PM -0700, Tom Rini wrote: > I assume once the custom HW is 'ready', you'll be able to stop doing > that tho. I think you'll spend more time trying to get everything just > right than you would building 2 kernels a few times (I bet much of the > pain comes from the current kbuild crap. You might wanna play w/ the > current kbuild-2.5 stuff if you're going to pick a kernel rev & stay for > a while, it gets the deps right so you only recompile the needed files > in cases like this). We already have a few boards running but right now we have to fight over them. With the Walnuts we can build and test kernel changes without holding up other people using the boards. So far doing 2 builds has been ok, but it shouldn't be too much work to get things working for both. I am not looking at the code now, but for a 405 you just need to do a board header and a C file. The amount of work these things do is small, but they all define the same functions. That doesn't lend itself to working for more than one board. It should be easy enough to put those functions in a structure do things dynamicaly. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
Tom Rini wrote: > > I got the kernel from the linuxppc_2_4_devel tree using > > > > bk export ... -rv2.4.18 > > > > So I guess I do have a 2.4-devel. Right? > > No. -rv2.4.18 got you 2.4.18 from kernel.org, no PPC changes at all. Well Tom, I do a "bk pull" from http://ppc.bkserver.net/linuxppc_2_4_devel once in a while. And when I do a "bk export -r2.4.18 ..." I definetly get PPC stuff in the resulting tree. Otherwise it would be easy to notice that there is something strange! Anyway, from noe on I try to remember not to use the tags but the changeset to export the tree. BTW does anyone know a good and easy way to get the changes from the bitkeeper tree into a local CVS? For now I "bk pull" then "bk export" and then "cvs import" and then merge... :-( Cheers, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 04:28:49PM -0700, andrew may wrote: > On Thu, Apr 11, 2002 at 04:10:56PM -0700, Tom Rini wrote: > > On Thu, Apr 11, 2002 at 03:36:42PM -0700, andrew may wrote: > > > > > This patch is to remove the need for the BASE BAUD define. > > > > Only if you get this information from somewhere else, yes? This isn't > > currently something we grab from OpenBIOS, or could, right? > > If you look at the patch you see the only thing we need to know is the clock > rate of the CPU. Then you can to a mfdcr() to calc the base baud. If there > is an external clock then we need the basebaud from somewhere else. Ah, right.. [snip] > > More seriously, if someone wants to try and do that there's lots of > > other things which would need to be changed first. > > Yes there is a lot of work to do, but I would like to see it happen. > Right now we have to do seperate builds for our custum board and one for > our Walnut boards and that is a pain. I assume once the custom HW is 'ready', you'll be able to stop doing that tho. I think you'll spend more time trying to get everything just right than you would building 2 kernels a few times (I bet much of the pain comes from the current kbuild crap. You might wanna play w/ the current kbuild-2.5 stuff if you're going to pick a kernel rev & stay for a while, it gets the deps right so you only recompile the needed files in cases like this). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tlbwe, rfci instructions and gcc cross assembler
I wrote about trouble compiling linuxppc_2_4
kernel on i686->powerpc cross compiler:
[...]
> /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__
> -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o
> head_4xx.o head_4xx.S
> head_4xx.S: Assembler messages:
> head_4xx.S:111: Error: Unrecognized opcode: `tlbwe'
> head_4xx.S:112: Error: Unrecognized opcode: `tlbwe'
> head_4xx.S:420: Error: Unrecognized opcode: `rfci'
> make[1]: *** [head_4xx.o] Error 1
> make[1]: Leaving directory
I have a bit more info. Looking through my binutils
(v. 2.12.90.0.4) I see some references to "tlbwe" so
I would think my binutils is recent enough...but
perhaps still broken?
So thinking maybe I wasn't running the assembler
I thought I was running, I did this:
cd /home/scameron/ppc/testdir/arch/ppc/kernel
strace /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S
[...]
access("/usr/local/ppc/powerpc-linux/bin/as", X_OK) = 0
vfork() = 16198
wait4(-1, head_4xx.S: Assembler messages:
head_4xx.S:111: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:112: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:420: Error: Unrecognized opcode: `rfci'
[WIFEXITED(s) && WEXITSTATUS(s) == 1], 0, NULL) = 16198
--- SIGCHLD (Child exited) ---
stat64("head_4xx.o", 0xb780)= -1 ENOENT (No such file or directory)
stat64("/tmp/cc7egQ8n.s", {st_mode=S_IFREG|0600, st_size=49044, ...}) = 0
unlink("/tmp/cc7egQ8n.s") = 0
_exit(1)= ?
So, I'm running /usr/local/ppc/powerpc-linux/bin/as
for my assembler, which seems right. Let me try:
strings /usr/local/ppc/powerpc-linux/bin/as | grep tlbwe
tlbwe
tlbwelo
tlbwehi
So...looks like my assembler has at least _some_ kind
of knowledge of the tlbwe instruction. Looking through
my binutils source, I see the "tlbwe" instruction in
a big table along with other instructions in
opcodes/ppc-opc.c
Hmmm, running out of ideas here.
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 04:10:56PM -0700, Tom Rini wrote: > On Thu, Apr 11, 2002 at 03:36:42PM -0700, andrew may wrote: > > > This patch is to remove the need for the BASE BAUD define. > > Only if you get this information from somewhere else, yes? This isn't > currently something we grab from OpenBIOS, or could, right? If you look at the patch you see the only thing we need to know is the clock rate of the CPU. Then you can to a mfdcr() to calc the base baud. If there is an external clock then we need the basebaud from somewhere else. We dumped OpenBIOS and put on PPCBoot, but I think OpenBIOS provides the clock speed. > > If we ever start > > trying to get a single kernel to build for multiple 405 boards that run at > > various clock rates it becomes helpful to calc the base baud for the serial > > ports rather than forcing it at compile time. > > If we ever start trying to get a single kernel to build for multiple 405 > boards something has gone wrong. :) > > More seriously, if someone wants to try and do that there's lots of > other things which would need to be changed first. Yes there is a lot of work to do, but I would like to see it happen. Right now we have to do seperate builds for our custum board and one for our Walnut boards and that is a pain. I though it would be good to start small and see how things go, before another fork got started :). ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 04:05:38PM +, Armin wrote: > This patch did not remove BASE_BAUD from the headers??? Having an option > for early boot is a good thing, this patch removes that option. Your > patch would only affect the walnut? David's is at least in setup.c > where more boards have access to the early serial init code. This patch was more a proof of concept. I need it on our devel board that may run at different speeds. It becomes hard to find a good overall base baud rate that will work for multiple clock speeds, that doesn't cause rounding errors that throw off the final baud rate. Since BASE_BAUD is defined in the platform section I though to put the code in the same area. I did not look around for the best place to put it so setup.c may be a better spot. If a external serial clock is used the BaseBaud still needs to be correct. So that is one reason not to remove the define completely, but for anything that uses the internal clock BaseBaud could be set to 0. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 03:36:42PM -0700, andrew may wrote: > This patch is to remove the need for the BASE BAUD define. Only if you get this information from somewhere else, yes? This isn't currently something we grab from OpenBIOS, or could, right? > If we ever start > trying to get a single kernel to build for multiple 405 boards that run at > various clock rates it becomes helpful to calc the base baud for the serial > ports rather than forcing it at compile time. If we ever start trying to get a single kernel to build for multiple 405 boards something has gone wrong. :) More seriously, if someone wants to try and do that there's lots of other things which would need to be changed first. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 02:53:36PM +, Armin wrote: > > John Tyner wrote: > >I remember seeing something awhile ago about early boots, but I didn't > >think it was for Walnut. Where is it/would it be? > > > > David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a > few header files imb405gp.h Ah, here's some of the confusion. David G did the work for CONFIG_SERIAL_TEXT_DEBUG or so. What this does is setup drivers/char/serial.c dynamically instead of statically. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
andrew may wrote: > On Thu, Apr 11, 2002 at 02:53:36PM +, Armin wrote: > >>John Tyner wrote: >> >>>I remember seeing something awhile ago about early boots, but I didn't >>>think it was for Walnut. Where is it/would it be? >>> >>>On Thu, 11 Apr 2002, Armin wrote: >>> >>> >>> John Tyner wrote: >> >>David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a >>few header files imb405gp.h >> > > This patch is to remove the need for the BASE BAUD define. If we ever start > trying to get a single kernel to build for multiple 405 boards that run at > various clock rates it becomes helpful to calc the base baud for the serial > ports rather than forcing it at compile time. > > This patch did not remove BASE_BAUD from the headers??? Having an option for early boot is a good thing, this patch removes that option. Your patch would only affect the walnut? David's is at least in setup.c where more boards have access to the early serial init code. armin ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
andrew may wrote: >On Thu, Apr 11, 2002 at 02:53:36PM +, Armin wrote: > >>John Tyner wrote: >> >>>I remember seeing something awhile ago about early boots, but I didn't >>>think it was for Walnut. Where is it/would it be? >>> >>>On Thu, 11 Apr 2002, Armin wrote: >>> >>> John Tyner wrote: >> >>David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a >>few header files imb405gp.h >> > >This patch is to remove the need for the BASE BAUD define. If we ever start >trying to get a single kernel to build for multiple 405 boards that run at >various clock rates it becomes helpful to calc the base baud for the serial >ports rather than forcing it at compile time. > ok, let me clean this sentence up a bit... A single kernel for multiple 405 boards does not fit the current design goals of the 4xx port, so I hope there are better reasons for this patch. > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
> This does not fit the current design goals of the 4xx port Why not? I can't possibly understand why not having to know the BASE_BAUD ahead of time isn't a good thing. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
andrew may wrote: >On Thu, Apr 11, 2002 at 02:53:36PM +, Armin wrote: > >>John Tyner wrote: >> >>>I remember seeing something awhile ago about early boots, but I didn't >>>think it was for Walnut. Where is it/would it be? >>> >>>On Thu, 11 Apr 2002, Armin wrote: >>> >>> John Tyner wrote: >> >>David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a >>few header files imb405gp.h >> > >This patch is to remove the need for the BASE BAUD define. If we ever start >trying to get a single kernel to build for multiple 405 boards that run at >various clock rates it becomes helpful to calc the base baud for the serial >ports rather than forcing it at compile time. > This does not fit the current design goals of the 4xx port, so I hope there are better reasons for this patch. > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
On Thu, Apr 11, 2002 at 02:53:36PM +, Armin wrote: > > John Tyner wrote: > > I remember seeing something awhile ago about early boots, but I didn't > > think it was for Walnut. Where is it/would it be? > > > > On Thu, 11 Apr 2002, Armin wrote: > > > > > >>John Tyner wrote: > >> > > > David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a > few header files imb405gp.h This patch is to remove the need for the BASE BAUD define. If we ever start trying to get a single kernel to build for multiple 405 boards that run at various clock rates it becomes helpful to calc the base baud for the serial ports rather than forcing it at compile time. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8xx fpu support and compiling glib.
Hello All, I was wondering a few things about MPC8xx FPU support. If I build a kernel with fpu-emulation do I have to pass the CFLAGS "-msoft-float -D_SOFT_FLOAT" when compiling glibc? Does it save me any ram if I don't? I know if I don't my performance will drop but our aplication doesn't use floating point except for ping mabey. Thanks in advance, Conn -- * If you live at home long enough, your parents will move out. * Conn Clark Engineering Stooge clark at esteem.com Electronic Systems Technology Inc. www.esteem.com Stock Ticker Symbol ELST "clark at esteem.com" Copyright 2000 By Electronic Systems Technology This email address may be used to communicate to Conn Clark provided it is not being used for advertisement purposes, unless prior written consent is given. This email address may not be sold under any circumstances. All other rights reserved. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tlbwe, rfci instructions and gcc cross assembler
On Thu, Apr 11, 2002 at 04:53:18PM -0500, Cameron, Steve wrote: [snip] > strace /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ > -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S -Wa,-m405 is missing here. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
K?ri, > I have had this "random crashes" for linux 2.4.18-pre1 from > linuxppc-2_4_devel for some time now... > ... > I got 2.4.19-pre6 last weekend from the rsync source at mvista, merged > and compiled. Since > then I had the board in my "reboot loop" and rebooted some 6000 times. > Not one single crash... Thanks. I just pulled cs-1.900. It seems to work fine and solved at least one other problem for me! :o) Thanks a lot, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
Wolfgang, > AFAIK, this relase tag applies ony to Linus's part of the tree. > The PPC part is somehow undefined and might be quite old. > I usually search "bk changes" for "v2.4.18" and then take a > change-set shortly afterwards e.g.: > > bk export -r1.900 Hmm. Yeah. Damn. You're right - of course. I forgot about this. Thanks a million! Steven BTW cs-1.900 seems not to have this kernal panic problem. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
John Tyner wrote: > I remember seeing something awhile ago about early boots, but I didn't > think it was for Walnut. Where is it/would it be? > > On Thu, 11 Apr 2002, Armin wrote: > > >>John Tyner wrote: >> David G did something and he hit the head_4xx.S & ppc4xx_setup.c and a few header files imb405gp.h armin ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
I remember seeing something awhile ago about early boots, but I didn't
think it was for Walnut. Where is it/would it be?
On Thu, 11 Apr 2002, Armin wrote:
> John Tyner wrote:
> > Here is a patch to setup the serial ports early. It works fine on our
> > walnut boards.
> >
> > --- arch/ppc/platforms/walnut.c.origThu Apr 11 12:55:55 2002
> > +++ arch/ppc/platforms/walnut.c Thu Apr 11 12:58:35 2002
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -247,6 +248,11 @@
> > void __init
> > board_init(void)
> > {
> > + struct serial_struct serial_req;
> > + bd_t *bip = (bd_t *) __res;
> > + u32 chrcr;
> > + int div;
> > + ulong bb;
> > #ifdef CONFIG_PPC_RTC
> > ppc_md.time_init = todc_time_init;
> > ppc_md.set_rtc_time = todc_set_rtc_time;
> > @@ -254,4 +260,40 @@
> > ppc_md.nvram_read_val = todc_direct_read_val;
> > ppc_md.nvram_write_val = todc_direct_write_val;
> > #endif
> > + chrcr = mfdcr(DCRN_CHCR0);
> > + div = ((chrcr&0x3e)>>1)+1;
> > + div *= 16;
> > + bb = bip->bi_intfreq/div;
> > +
> > + if( !(chrcr & CHR0_U0EC) ){
> > + memset(&serial_req, 0, sizeof(serial_req));
> > + serial_req.line = 0;
> > + serial_req.baud_base = bb;
> > + serial_req.port = 0;
> > + serial_req.irq= UART0_INT;
> > + serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> > + serial_req.io_type= SERIAL_IO_MEM;
> > + serial_req.iomem_base = (u8 *)UART0_IO_BASE;
> > + serial_req.iomem_reg_shift = 0;
> > +
> > + if (early_serial_setup(&serial_req) != 0) {
> > + printk("Early serial init of port 0 failed\n");
> > + }
> > + }
> > +
> > + if( !(chrcr & CHR0_U1EC) ){
> > + memset(&serial_req, 0, sizeof(serial_req));
> > + serial_req.line = 1;
> > + serial_req.baud_base = bb;
> > + serial_req.port = 1;
> > + serial_req.irq= UART1_INT;
> > + serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> > + serial_req.io_type= SERIAL_IO_MEM;
> > + serial_req.iomem_base = (u8 *)UART1_IO_BASE;
> > + serial_req.iomem_reg_shift = 0;
> > +
> > + if (early_serial_setup(&serial_req) != 0) {
> > + printk("Early serial init of port 1 failed\n");
> > + }
> > + }
> > }
> >
> >
> >
> >
> >
>
> I thought we all ready had an early boot for walnut?
>
> armin
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
John Tyner wrote:
> Here is a patch to setup the serial ports early. It works fine on our
> walnut boards.
>
> --- arch/ppc/platforms/walnut.c.orig Thu Apr 11 12:55:55 2002
> +++ arch/ppc/platforms/walnut.c Thu Apr 11 12:58:35 2002
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -247,6 +248,11 @@
> void __init
> board_init(void)
> {
> + struct serial_struct serial_req;
> + bd_t *bip = (bd_t *) __res;
> + u32 chrcr;
> + int div;
> + ulong bb;
> #ifdef CONFIG_PPC_RTC
> ppc_md.time_init = todc_time_init;
> ppc_md.set_rtc_time = todc_set_rtc_time;
> @@ -254,4 +260,40 @@
> ppc_md.nvram_read_val = todc_direct_read_val;
> ppc_md.nvram_write_val = todc_direct_write_val;
> #endif
> + chrcr = mfdcr(DCRN_CHCR0);
> + div = ((chrcr&0x3e)>>1)+1;
> + div *= 16;
> + bb = bip->bi_intfreq/div;
> +
> + if( !(chrcr & CHR0_U0EC) ){
> + memset(&serial_req, 0, sizeof(serial_req));
> + serial_req.line = 0;
> + serial_req.baud_base = bb;
> + serial_req.port = 0;
> + serial_req.irq= UART0_INT;
> + serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + serial_req.io_type= SERIAL_IO_MEM;
> + serial_req.iomem_base = (u8 *)UART0_IO_BASE;
> + serial_req.iomem_reg_shift = 0;
> +
> + if (early_serial_setup(&serial_req) != 0) {
> + printk("Early serial init of port 0 failed\n");
> + }
> + }
> +
> + if( !(chrcr & CHR0_U1EC) ){
> + memset(&serial_req, 0, sizeof(serial_req));
> + serial_req.line = 1;
> + serial_req.baud_base = bb;
> + serial_req.port = 1;
> + serial_req.irq= UART1_INT;
> + serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + serial_req.io_type= SERIAL_IO_MEM;
> + serial_req.iomem_base = (u8 *)UART1_IO_BASE;
> + serial_req.iomem_reg_shift = 0;
> +
> + if (early_serial_setup(&serial_req) != 0) {
> + printk("Early serial init of port 1 failed\n");
> + }
> + }
> }
>
>
>
>
>
I thought we all ready had an early boot for walnut?
armin
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] early serial init
Here is a patch to setup the serial ports early. It works fine on our
walnut boards.
--- arch/ppc/platforms/walnut.c.origThu Apr 11 12:55:55 2002
+++ arch/ppc/platforms/walnut.c Thu Apr 11 12:58:35 2002
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -247,6 +248,11 @@
void __init
board_init(void)
{
+ struct serial_struct serial_req;
+ bd_t *bip = (bd_t *) __res;
+ u32 chrcr;
+ int div;
+ ulong bb;
#ifdef CONFIG_PPC_RTC
ppc_md.time_init = todc_time_init;
ppc_md.set_rtc_time = todc_set_rtc_time;
@@ -254,4 +260,40 @@
ppc_md.nvram_read_val = todc_direct_read_val;
ppc_md.nvram_write_val = todc_direct_write_val;
#endif
+ chrcr = mfdcr(DCRN_CHCR0);
+ div = ((chrcr&0x3e)>>1)+1;
+ div *= 16;
+ bb = bip->bi_intfreq/div;
+
+ if( !(chrcr & CHR0_U0EC) ){
+ memset(&serial_req, 0, sizeof(serial_req));
+ serial_req.line = 0;
+ serial_req.baud_base = bb;
+ serial_req.port = 0;
+ serial_req.irq= UART0_INT;
+ serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
+ serial_req.io_type= SERIAL_IO_MEM;
+ serial_req.iomem_base = (u8 *)UART0_IO_BASE;
+ serial_req.iomem_reg_shift = 0;
+
+ if (early_serial_setup(&serial_req) != 0) {
+ printk("Early serial init of port 0 failed\n");
+ }
+ }
+
+ if( !(chrcr & CHR0_U1EC) ){
+ memset(&serial_req, 0, sizeof(serial_req));
+ serial_req.line = 1;
+ serial_req.baud_base = bb;
+ serial_req.port = 1;
+ serial_req.irq= UART1_INT;
+ serial_req.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
+ serial_req.io_type= SERIAL_IO_MEM;
+ serial_req.iomem_base = (u8 *)UART1_IO_BASE;
+ serial_req.iomem_reg_shift = 0;
+
+ if (early_serial_setup(&serial_req) != 0) {
+ printk("Early serial init of port 1 failed\n");
+ }
+ }
}
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
On Thu, Apr 11, 2002 at 09:06:02PM +0200, Wolfgang Grandegger wrote: > On 04/11/2002 05:31 PM, Tom Rini wrote: > > >On Thu, Apr 11, 2002 at 09:23:11AM +0200, Steven Scholz wrote: > >> > >> Christian Pellegrin wrote: > >> > >> > not really sure this will help you, but I had similar problem (spurious > >> > hangs during boot/insmod on 823 and 850 MPCs). The ppc mm for 8xx in 2.4 > >> > repository is broken, use that in 2.4-devel that works fine. AFA net > >> > devices are concerned check that rx start is done in open and not in init > >> > since linux doesn't like packets before a device is opened. > >> > >> Thanks for your reply. > >> > >> I got the kernel from the linuxppc_2_4_devel tree using > >> > >> bk export ... -rv2.4.18 > >> > >> So I guess I do have a 2.4-devel. Right? > > > >No. -rv2.4.18 got you 2.4.18 from kernel.org, no PPC changes at all. > > > You mean it's identical to linux-2.4.18.tar.gz from kernel.org? Yes. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel size
I know that this list is usually reserved for discussions of bringing up kernels, but I have a question on kernel size. What is the smallest size of kernel (including tcp/ip) that people have been able to build? Do the folks on this list see the large size as an issue to further adoption of linux on the PowerQuicc processors? Ken ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
I have had this "random crashes" for linux 2.4.18-pre1 from linuxppc-2_4_devel for some time now, it was not to annoying, since so much other stuff has been unstable for us. Theses crashses ware mostly during booting of the kernel, i.e. if the kernel made it through the boot it seemed to run stable. I collected at one point some statistics and it crashed in 0.5% - 1% cases of reboot. I got 2.4.19-pre6 last weekend from the rsync source at mvista, merged and compiled. Since then I had the board in my "reboot loop" and rebooted some 6000 times. Not one single crash. So I am happy, and recomend to you to go get the latest version from linuxppc_2_4_devel (well I have version 2.4.19pre6 gotten from the rsync source at mvista last weekend). Regards, K.D. > -Original Message- > From: Steven Scholz [mailto:steven.scholz at imc-berlin.de] > Sent: 11. apr?l 2002 07:08 > To: LinuxPPC > Subject: sporadic kernel panic during boot (MPC8xx, FEC) > > > > Hi there, > > I am using the linux kernel from bitkeepers > linuxppc_2_4_devel exported > as of -rv2.4.18 on a MPC855T based board. > > From time to time I see a kernel panic while booting. I suppose it > related to FEC (or MII) interrupts. The time the kernel panic > occurs is > different every time. > > Two examples: > == > > --- > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 50MHz system bus speed for PIO modes; override with > idebus=xx > IDE phys mem : fe00...fe000200 (size 0200) > hda: probing with STATUS(0x50) instead of ALTSTATUS(0x00) > hda: HITACHI_DK239A-65, ATA DISK drive > ide0 at 0xc200-0xc207,0xc2000106 on irq 2 > hda: 12685680 sectors (6495 MB) w/512KiB Cache, CHS=13424/15/63 > Partition check: > hda: hda1 hda2 > Oops: kernel access of bad area, sig: 11 > NIP: C00AE7E8 XER: LR: C0003984 SP: C01E9DC0 REGS: c01e9d10 > TRAP: 0300Not tainted > MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: 00D0, DSISR: 0129 > TASK = c01e8000[1] 'swapper' Last syscall: 120 > last math last altivec > GPR00: F002 C01E9DC0 C01E8000 000A C01D5400 C01E9E30 C0122608 > C01F6000 > GPR08: C0154018 0001 24008022 100198C8 00FE3A00 > 007FFF83 > GPR16: 0001 007FFF00 1032 001E9E20 > C000298C > GPR24: C0003A28 0140 C01E9E30 C01F6720 000A F000 C01D5400 > FFF00E00 > Call backtrace: > C0104CF0 C0003984 C0003A84 C000298C C00032A4 C0003440 C014FE9C > C014E740 C014E77C C0150608 C014D76C C01477C8 C0147810 C0002558 > C0004D28 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > <0>Rebooting in 180 seconds.. > --- > C0104CF0 C0003984 C0003A84 C000298C C00032A4 C0003440 C014FE9C > C014E740 C014E77C C0150608 C014D76C C01477C8 C0147810 C0002558 > C0004D28 > 0xc0104cf0 -- 0xc010461c + 0x06d4 vsnprintf > 0xc0003984 -- 0xc00037f4 + 0x0190 ppc_irq_dispatch_handler > 0xc0003a84 -- 0xc0003a28 + 0x005c do_IRQ > 0xc000298c -- 0xc000298c + 0x ret_from_intercept > 0xc00032a4 -- 0xc00031b0 + 0x00f4 setup_irq > 0xc0003440 -- 0xc000339c + 0x00a4 request_8xxirq > 0xc014fe9c -- 0xc014fc98 + 0x0204 fec_enet_init > 0xc014e740 -- 0xc014e710 + 0x0030 network_probe > 0xc014e77c -- 0xc014e76c + 0x0010 net_device_init > 0xc0150608 -- 0xc015038c + 0x027c net_dev_init > 0xc014d76c -- 0xc014d754 + 0x0018 device_init > 0xc01477c8 -- 0xc0147798 + 0x0030 do_initcalls > 0xc0147810 -- 0xc01477e8 + 0x0028 do_basic_setup > 0xc0002558 -- 0xc0002544 + 0x0014 init > 0xc0004d28 -- 0xc0004cfc + 0x002c kernel_thread > > == > > ... > eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 10, addr > 00:a0:33:00:37:e8 > eth0: Phy @ 0x0, type LXT971 (0x001378e2) > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 1024 bind 1024) > eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. > IP-Config: Complete: > device=eth0, addr=192.168.11.225, mask=255.255.255.0, > gw=255.255.255.255, > host=idif3, domain=, nis-domain=(none), > bootserver=192.168.11.91, rootserver=192.168.11.91, rootpath= > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Looking up port of RPC 13/2 on 192.168.11.91 > eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation > complete. > Looking up port of RPC 15/1 on 192.168.11.91 > Oops: kernel access of bad area, sig: 11 > NIP: C00F8510 XER: LR: C00F84C4 SP: C01E9DB0 REGS: c01e9d00 > TRAP: 0300Not tainted > MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: C013C2C4, DSISR: 8200 > TASK = c01e8000[1] 'swapper' Last syscall: 120 > last math last altive
Interrupt notification in PPCBug
Hi, I'm sorry if this is an OT question, but many of you are also PPCBug expert and I hope someone of you can help me for this little trouble. I have a MCPN765 non-system board and whenever some pci device raise an interrupt (also behind the transparent bridge of my system board) PPCBug notify this. This behaviour prevent me to use my system board as the bootp/tftp/nfs server to boot linux for the non-system board because notification of the interrupts of the NIC on the system board break the NBO command. There is a way to disable this behaviour on PPCBug ? Thanks in advance. Stefano. ++ ! Stefano Coluccini ! CAEN SpA - Computing Div. ! ! Via Vetraia, 11 ! 55049 Viareggio (LU)-ITALY ! ! Tel. +39 0584 388 398 ! Fax +39 0584 388 959 ! ! s.coluccini at caen.it ! www.caen.it/computing ! ++ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel size
Ken Applebaum wrote: > > I know that this list is usually reserved for discussions of bringing up > kernels, but I have a question on kernel size. > > What is the smallest size of kernel (including tcp/ip) that people have been > able to build? Do the folks on this list see the large size as an issue to > further adoption of linux on the PowerQuicc processors? > > Ken > It all depends on what size you are refering to. Is it the size of the compressed zImage, the compressed bzImage , the uncompressed image, or the runtime RAM usage? Our zImage is just about 400,000 bytes. Our uncompressed image is about 1 MB. The others sizes I haven't looked at. Our kernel could be smaller if we left out fpu emulation and other modules. I see this as an issue that is becoming less and less important as RAM and flash storage technology increase in size and drop in price. See what Wolfgang accomplished here. http://www.denx.de/embedded-ppc-en.html Its about mid page under the heading "PowerPC based Web Server" . Hope this is helpful Conn -- * If you live at home long enough, your parents will move out. * Conn Clark Engineering Stooge clark at esteem.com Electronic Systems Technology Inc. www.esteem.com Stock Ticker Symbol ELST "clark at esteem.com" Copyright 2000 By Electronic Systems Technology This email address may be used to communicate to Conn Clark provided it is not being used for advertisement purposes, unless prior written consent is given. This email address may not be sold under any circumstances. All other rights reserved. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
On Thu, 11 Apr 2002, Steven Scholz wrote: > > bk export ... -rv2.4.18 > > So I guess I do have a 2.4-devel. Right? > bk pull to sync to the last version, but AFAIK it's 2.4-devel :-) Bye! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
On 04/11/2002 09:07 AM, Steven Scholz wrote: >Hi there, > >I am using the linux kernel from bitkeepers linuxppc_2_4_devel exported >as of -rv2.4.18 on a MPC855T based board. > AFAIK, this relase tag applies ony to Linus's part of the tree. The PPC part is somehow undefined and might be quite old. I usually search "bk changes" for "v2.4.18" and then take a change-set shortly afterwards e.g.: bk export -r1.900 Hope it helps, Wolfgang. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
Christian Pellegrin wrote: > not really sure this will help you, but I had similar problem (spurious > hangs during boot/insmod on 823 and 850 MPCs). The ppc mm for 8xx in 2.4 > repository is broken, use that in 2.4-devel that works fine. AFA net > devices are concerned check that rx start is done in open and not in init > since linux doesn't like packets before a device is opened. Thanks for your reply. I got the kernel from the linuxppc_2_4_devel tree using bk export ... -rv2.4.18 So I guess I do have a 2.4-devel. Right? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
On Thu, 11 Apr 2002, Steven Scholz wrote: > > Hi there, > > I am using the linux kernel from bitkeepers linuxppc_2_4_devel exported > as of -rv2.4.18 on a MPC855T based board. > ... > > Any ideas? > > Thanks, > not really sure this will help you, but I had similar problem (spurious hangs during boot/insmod on 823 and 850 MPCs). The ppc mm for 8xx in 2.4 repository is broken, use that in 2.4-devel that works fine. AFA net devices are concerned check that rx start is done in open and not in init since linux doesn't like packets before a device is opened. Bye! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
sporadic kernel panic during boot (MPC8xx, FEC)
Hi there, I am using the linux kernel from bitkeepers linuxppc_2_4_devel exported as of -rv2.4.18 on a MPC855T based board. >From time to time I see a kernel panic while booting. I suppose it related to FEC (or MII) interrupts. The time the kernel panic occurs is different every time. Two examples: == --- Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx IDE phys mem : fe00...fe000200 (size 0200) hda: probing with STATUS(0x50) instead of ALTSTATUS(0x00) hda: HITACHI_DK239A-65, ATA DISK drive ide0 at 0xc200-0xc207,0xc2000106 on irq 2 hda: 12685680 sectors (6495 MB) w/512KiB Cache, CHS=13424/15/63 Partition check: hda: hda1 hda2 Oops: kernel access of bad area, sig: 11 NIP: C00AE7E8 XER: LR: C0003984 SP: C01E9DC0 REGS: c01e9d10 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 00D0, DSISR: 0129 TASK = c01e8000[1] 'swapper' Last syscall: 120 last math last altivec GPR00: F002 C01E9DC0 C01E8000 000A C01D5400 C01E9E30 C0122608 C01F6000 GPR08: C0154018 0001 24008022 100198C8 00FE3A00 007FFF83 GPR16: 0001 007FFF00 1032 001E9E20 C000298C GPR24: C0003A28 0140 C01E9E30 C01F6720 000A F000 C01D5400 FFF00E00 Call backtrace: C0104CF0 C0003984 C0003A84 C000298C C00032A4 C0003440 C014FE9C C014E740 C014E77C C0150608 C014D76C C01477C8 C0147810 C0002558 C0004D28 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing <0>Rebooting in 180 seconds.. --- C0104CF0 C0003984 C0003A84 C000298C C00032A4 C0003440 C014FE9C C014E740 C014E77C C0150608 C014D76C C01477C8 C0147810 C0002558 C0004D28 0xc0104cf0 -- 0xc010461c + 0x06d4 vsnprintf 0xc0003984 -- 0xc00037f4 + 0x0190 ppc_irq_dispatch_handler 0xc0003a84 -- 0xc0003a28 + 0x005c do_IRQ 0xc000298c -- 0xc000298c + 0x ret_from_intercept 0xc00032a4 -- 0xc00031b0 + 0x00f4 setup_irq 0xc0003440 -- 0xc000339c + 0x00a4 request_8xxirq 0xc014fe9c -- 0xc014fc98 + 0x0204 fec_enet_init 0xc014e740 -- 0xc014e710 + 0x0030 network_probe 0xc014e77c -- 0xc014e76c + 0x0010 net_device_init 0xc0150608 -- 0xc015038c + 0x027c net_dev_init 0xc014d76c -- 0xc014d754 + 0x0018 device_init 0xc01477c8 -- 0xc0147798 + 0x0030 do_initcalls 0xc0147810 -- 0xc01477e8 + 0x0028 do_basic_setup 0xc0002558 -- 0xc0002544 + 0x0014 init 0xc0004d28 -- 0xc0004cfc + 0x002c kernel_thread == ... eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 10, addr 00:a0:33:00:37:e8 eth0: Phy @ 0x0, type LXT971 (0x001378e2) NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 1024) eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. IP-Config: Complete: device=eth0, addr=192.168.11.225, mask=255.255.255.0, gw=255.255.255.255, host=idif3, domain=, nis-domain=(none), bootserver=192.168.11.91, rootserver=192.168.11.91, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 13/2 on 192.168.11.91 eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation complete. Looking up port of RPC 15/1 on 192.168.11.91 Oops: kernel access of bad area, sig: 11 NIP: C00F8510 XER: LR: C00F84C4 SP: C01E9DB0 REGS: c01e9d00 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: C013C2C4, DSISR: 8200 TASK = c01e8000[1] 'swapper' Last syscall: 120 last math last altivec GPR00: C013C2A0 C01E9DB0 C01E8000 0001 C01F68C0 C01E9E4C C01F6000 GPR08: 0038 0001 06E0 C013C2B4 24008022 100198C8 00FE3A00 007FFF83 GPR16: 0001 007FFF00 00FDDD70 C010DDBC 00FA0740 C015 GPR24: C014 00FE5288 007FFEC0 C01E9E58 C01E9EA8 C0FF0E50 C01E9DC8 C01E9DC8 Call backtrace: C00F84C4 C00F8358 C0070A48 C0070970 C014C838 C014C89C C014ABB8 C000242C C000255C C0004D28 Kernel panic: Attempted to kill init! --- Reading symbols from System.map C00F84C4 C00F8358 C0070A48 C0070970 C014C838 C014C89C C014ABB8 C000242C C000255C C0004D28 0xc00f84c4 -- 0xc00f847c + 0x0048 rpc_call_setup 0xc00f8358 -- 0xc00f82d8 + 0x0080 rpc_call_sync 0xc0070a48 -- 0xc00709a4 + 0x00a4 nfs_gen_mount 0xc0070970 -- 0xc007095c + 0x0014 nfs_mount 0xc014c838 -- 0xc014c7cc + 0x006c root_nfs_get_handle 0xc014c89c -- 0xc014c874 + 0x0028 nfs_root_data 0xc014abb8 -- 0xc014ab6c + 0x004c mount_root 0xc000242c -- 0xc00023bc + 0x0070 prepare_namespace 0xc000255c -- 0xc0002544 + 0x0018 init 0xc0004d28 -- 0xc0004cfc + 0x002c kernel_thread =
sporadic kernel panic during boot (MPC8xx, FEC)
On Thu, Apr 11, 2002 at 09:23:11AM +0200, Steven Scholz wrote: > > Christian Pellegrin wrote: > > > not really sure this will help you, but I had similar problem (spurious > > hangs during boot/insmod on 823 and 850 MPCs). The ppc mm for 8xx in 2.4 > > repository is broken, use that in 2.4-devel that works fine. AFA net > > devices are concerned check that rx start is done in open and not in init > > since linux doesn't like packets before a device is opened. > > Thanks for your reply. > > I got the kernel from the linuxppc_2_4_devel tree using > > bk export ... -rv2.4.18 > > So I guess I do have a 2.4-devel. Right? No. -rv2.4.18 got you 2.4.18 from kernel.org, no PPC changes at all. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ROOT-NFS problem for PPC440 kernel!
An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020411/ac9b72a4/attachment.txt
