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: Stuart Hughes
Subject: Re: [Ltib] Build success for LPC32xx target, kernel issues :-(
Date: Thu, 29 Jul 2010 21:42:28 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080707)

Hi Tim,

Could I suggest to you both that you keep the dialog on the list, or at
least summarise the issue/resolution when you're done.  That way
everyone can benefit, which is the purpose of the public forum.

Regards, Stuart

Tim Nelson wrote:
> 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
> 



reply via email to

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