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

[Stuart Hughes]

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
>