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