[U-Boot-Users] Problems writing to memory with mw

[Jerry Van Baren <gerald.vanbaren@ge.com>]

robert lazarski wrote:
> On Nov 20, 2007 9:54 AM, Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
>> robert lazarski wrote:
>>> Hi all,
>>>
>>> I'm trying to track down problems loading a linux kernel on my custom
>>> 8548 board off of 1.3RC3 - it loads sometimes via a ramdisk and gives
>>> me a bash shell - but most times it crashes in unusual, different
>>> places.
>>>
>>> I ram mtest in the monitor and it crashes at 00000a90 . When using mw I get:
>>>
>>> => mw 00000a90 cafecafe
>>> NIP: CAFECAFC XER: 00000000 LR: 1FFC109C REGS: 1ff9dc40 TRAP: 0700 DAR: 00000000
> <snip>
>>> I can write to  00000a90 via the bdi . u-boot otherwise runs
>>> perfectly. Any ideas?
>>> Robert
>> 98% probability you have a SDRAM configuration problem.  2% probability
>> you have a hardware problem.  I'm rooting for SDRAM config problem, you
>> probably should too. ;-)
>>    <http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation>
>>
>> Writing to location 0x0A90 doesn't sound like a good idea to me.  I'm
>> not familiar with the 8548, but this is in the middle of the exception
>> vectors.  You are probably overwriting exception handling code (check
>> your 85xx UM), so that would be an invalid test (red herring).
>>
>> gvb
>>
> 
> Ahh, seems my test is invalid - thanks for pointing that out. I
> defined and ran my boards testram() succesfully when I brought the
> board up - that seems to write to 0x0A90 et all when its safe to do
> so. I'll try again but its a long test.
> 
> I see no problems with u-boot - relocation seems to work. The link
> suggested following my memory specs "to the letter" . So far I'm just
> calling spd_sdram() like most 85xx boards do - should I look there?
> Since my kernel boots sometimes into bash, but usually doesn't, I'm
> trying to confirm my memory is functioning. When the kernel fails to
> boot the eldk 85xx uRamdisk, its crashes at several different places
> before it loads the RFS. A few times everything just worked fine,
> which makes me think its a hardware issue. Any suggestions to tracking
> that type of problem down?
> 
> Thanks, Robert

Hi Robert,

The configuration SDRAM problems typically show up when cache is enabled 
because that is when the pipelining really becomes active and config 
errors show up.  There isn't a good way to debug this that I'm aware of, 
other than reading the users manuals/data sheets repeatedly (!!!) and 
working out the numbers (painfully!).  My recollection of SPD is that 
mapping SPD values to SDRAM controller configuration is not nearly as 
straight forward as you would expect.

You could try different memory sticks to see if a different manufacturer 
and/or speed rating stops the crashing.

You could also try running caching disabled (start with both data and 
instruction disabled, then the other 3 combinations) - it slows the boot 
down substantially, but if it runs, it is an indication that you likely 
have a configuration problem.

WRT hardware problems, probably you can dial back the speed of your bus. 
  If disabling caching doesn't fix the problem but dialing back the 
speed does, it would indicate a hardware problem.

For hardware problems, I would suspect trace problems: perhaps the 
traces are not acceptably close to equal length (outside of the spec) or 
if they are routed poorly (through a noisy part of the board).  Looking 
at the layout may show up something.  I've seen poor routing cause 
problems that were "solved" by slowing down the bus.

Good luck,
gvb