Re: [Ltib] Build success for LPC32xx target, kernel issues :-(

[Tim Nelson]

Well, I'm able to successfully load the kernel provided by Kevin as well as the 
second kernel I built(2.6.34 with ethernet issues...) using all default 
options. I'm going to attempt another build of a 2.6.27 kernel so I have proper 
ethernet support.

In the meantime, booting the board using the kernel provided by Kevin or the 
kernel that came preloaded on NAND, I appear to be unable to boot from NFS or 
having issues with the LTIB generated rootfs.

When I boot to the LTIB generated rootfs, I'm getting "Kernel panic - not 
syncing: Attempted to kill init!" after the kernel fully initializes and the 
NFS export is mounted. My kernel cmd line is as follows:

bootargs=console=ttyS0,115200n81 root=/dev/nfs rw 
nfsroot=172.16.23.170:/usr/src/ltib_clean_postcrcerrors/ltib/rootfs ip=dhcp 
init=/sbin/init

Thoughts?

**SLIGHTLY OT**
I'm also attempting to boot into a rootfs generated by 'debootstrap' from 
Debian Lenny. I've used this very successfully in the past. However, it appears 
my NFS server configuration isn't quite right or the client mount options are 
incorrect. I'm unable to create device nodes using 'mknod' and therefore 
'debootstrap --second-stage' is failing. Any points on what needs to be done to 
allow NFS to mount or serve up an export with permissions for device nodes?
**SLIGHTLY OT**

Thank you for your continued suggestions!

--Tim

----- "Kevin Wells" <address@hidden> wrote:

> As long as you are using zImage or uImage as the bootable image, you
> should be
> able to put the downloaded image anywhere (even below 0x80008000).
> piggy.gz
> will move data around and may even relocate its own code to make it
> work..
> 
> This applies to ARM, but I'm not sure about the other architectures.
> 
> (The ATAG list is at 0x80000100. It might not be good to put I
> anywhere near
> there.)
> 
> Thanks,
> Kevin
> 
> > -----Original Message-----
> > From: address@hidden [mailto:ltib-
> > address@hidden On Behalf Of Stuart Hughes
> > Sent: Thursday, July 29, 2010 12:39 PM
> > To: Tim Nelson
> > Cc: address@hidden
> > Subject: Re: [Ltib] Build success for LPC32xx target, kernel issues
> :-(
> > 
> > Hi Tim,
> > 
> > I think Peter is on the right track. My suspicion is that the kernel
> is
> > overwriting itself when it gets uncompressed.  The tftp address and
> the
> > kernel run address look too close to me.  The load address looks a
> bit
> > odd to my, but Kevin can probably give a better answer.  I think
> you
> > need to raise the tftp load address so that as it uncompresses the
> > kernel into it's target ram address, that does not overwrite the
> image
> > being uncompressed.
> > 
> > There's an article here that has a picture that helps to understand
> > this:
> >
> http://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-
> > qemu-arm/
> > 
> > Unfortunately there's no set load addresses and all sorts of
> > complications depending on targets.
> > 
> > Regards, Stuart
> > 
> > Tim Nelson wrote:
> > > I tried your suggestion of doing a memory compare. Here are the
> > results:
> > >
> > > ---BEGIN---
> > > Phytec LPC3250 board
> > > Build date: Dec  4 2008 11:44:18
> > > Autoboot in progress, press any key to stop
> > >
> > > U-Boot 1.3.3 (May 15 2009 - 12:30:25)
> > >
> > > DRAM:  64 MB
> > > NAND:  32 MiB
> > > In:    serial
> > > Out:   serial
> > > Err:   serial
> > > Hit any key to stop autoboot:  0
> > > uboot> tftpboot 0x80000000 uImage
> > >         HW MAC address:  00:01:90:xx:xx:xx
> > > ENET:auto-negotiation complete
> > > ENET:Link status up
> > > ENET:FULL DUPLEX
> > > ENET:100MBase
> > > TFTP from server 172.16.23.44; our IP address is 172.16.23.91
> > > Filename 'uImage'.
> > > Load address: 0x80000000
> > > Loading: T
> > #################################################################
> > >          ######################################################
> > > done
> > > Bytes transferred = 1737596 (1a837c hex)
> > > uboot> tftpboot 0x82000000 uImage
> > >         HW MAC address:  00:01:90:xx:xx:xx
> > > ENET:auto-negotiation complete
> > > ENET:Link status up
> > > ENET:FULL DUPLEX
> > > ENET:100MBase
> > > TFTP from server 172.16.23.44; our IP address is 172.16.23.91
> > > Filename 'uImage'.
> > > Load address: 0x82000000
> > > Loading: T
> > #################################################################
> > >          #####################################################
> > > done
> > > Bytes transferred = 1737596 (1a837c hex)
> > > uboot> cmp.b 0x80000000 0x82000000 0x1a837c
> > > Total of 1737596 bytes were the same
> > > ---END---
> > >
> > > So, it appears the DRAM is good, at least on the blocks tested...
> > >
> > > --Tim
> > >
> > > ----- "Kevin Wells" <address@hidden> wrote:
> > >
> > >> Hi Tim,
> > >>
> > >>> I feel I'm getting VERY close, but unfortunately still having
> > >> issues
> > >>> getting the board bootstrapped. Any thoughts?
> > >> You mentioned this was a new design earlier? Try writing a
> program
> > to
> > >> hammer SDRAM
> > >> to see if your SDRAM is having occasional data errors.
> > >>
> > >> You can also try lowering the system clocking a bit to see if
> the
> > >> error goes away.
> > >> If the issue does goes away, check your power supply for
> excessive
> > >> noise or voltage
> > >> drop while SDRAM is under load. Is S1L ported to your board?
> > >>
> > >> You can also try loading your kernel to 2 different locations in
> > SDRAM
> > >> and then
> > >> using the u-boot cmp command to make sure they match. If not,
> some
> > >> SDRAM debug
> > >> may be in order...
> > >>
> > >> uboot> tftpboot 0x80000000 uImage
> > >>         HW MAC address:  00:01:90:00:C0:81
> > >> ENET:auto-negotiation complete
> > >> ENET:FULL DUPLEX
> > >> ENET:100MBase
> > >> TFTP from server 192.168.1.41; our IP address is 192.168.1.188
> > >> Filename 'uImage'.
> > >> Load address: 0x80000000
> > >> Loading:
> > >>
> #################################################################
> > >>
> > >> ###############################################################
> > >> done
> > >> Bytes transferred = 1877708 (1ca6cc hex)
> > >> uboot> tftpboot 0x82000000 uImage
> > >>         HW MAC address:  00:01:90:00:C0:81
> > >> ENET:auto-negotiation complete
> > >> ENET:FULL DUPLEX
> > >> ENET:100MBase
> > >> TFTP from server 192.168.1.41; our IP address is 192.168.1.188
> > >> Filename 'uImage'.
> > >> Load address: 0x82000000
> > >> Loading:
> > >>
> #################################################################
> > >>
> > >> ###############################################################
> > >> done
> > >> Bytes transferred = 1877708 (1ca6cc hex)
> > >> uboot> cmp.b 0x80000000 0x82000000 0x1ca6cc
> > >> Total of 1877708 bytes were the same
> > >> uboot>
> > >>
> > >> thanks,
> > >> Kevin
> > >
> > > _______________________________________________
> > > LTIB home page: http://ltib.org
> > >
> > > Ltib mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/ltib
> > >
> > 
> > _______________________________________________
> > LTIB home page: http://ltib.org
> > 
> > Ltib mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/ltib