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

[Kevin Wells]

Hi Stuart,

Sorry about that. I'll make sure these follow-ups get posted to the list
a bit quicker..

thanks,
Kevin


> -----Original Message-----
> From: address@hidden [mailto:ltib-
> address@hidden On Behalf Of Stuart Hughes
> Sent: Thursday, July 29, 2010 1:42 PM
> To: Tim Nelson
> Cc: address@hidden
> Subject: Re: [Ltib] Build success for LPC32xx target, kernel issues :-(
> 
> 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
> >
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib