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

[Kevin Wells]

Hi Tim,

Usually these things go really smooth, but changes in OSes, software
updates, etc. all cause a bunch of speed bumps in the best plans...

thanks,
Kevin

> -----Original Message-----
> From: address@hidden [mailto:ltib-
> address@hidden On Behalf Of Tim Nelson
> Sent: Thursday, July 29, 2010 12:52 PM
> To: address@hidden
> Subject: Re: [Ltib] Build success for LPC32xx target, kernel issues :-(
> 
> My apologies for the silence on my behalf. I've been working with Kevin
> directly on some of the issues I'm having. It turns out the kernel
> produced by my LTIB was not valid. So, I'm past that and working on
> other problems. I've been doing ARM stuff for some time now and this
> has got to be the most troublesome board to get up and running :-).
> 
> --Tim
> 
> ----- "Stuart Hughes" <address@hidden> wrote:
> > 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