ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wells
Subject: RE: [Ltib] Build success for LPC32xx target, kernel issues :-(
Date: Thu, 29 Jul 2010 23:33:00 +0200

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]