Dear Lasse Skov,
In message 4F4169B21905494EBD47A304F02192C92772357B6B@XCH-HQ-01.kk.local you wrote:
The problem is that the U-Boot has a problem when it try to rellocate itself to RAM. I know that this could be some timing settings for the SDRAM and the RAM controller.
Not only the timing settings, but also the whole RAM init sequence must mnatch the reauirements of your RAM chips to the letter. Make sure to study the chip manufacturer's manual. See the FAQ.
But the thing is that this is not every time uboot try to relocate itself to RAM.
Random behaviour, yes.
In the FAQ there is this. "Standard memory tests are not effective in identifying this type of problem because they do not cause stressful cache burst read/write operations. "
But what exactly does this mean? On my target I has DDR2 ram.
It means that you cannot stress test RAM by just reading and writing it. The really critical accesses happen in burst mode, which is during cache fill / flush operations and DMA.
And I thought that only bursted mode access was possible to the RAM on DDR2?
Even if you manage to cause a burst, there is still a big difference whether this is an isolated event, or when you are running burst mode accesses back-to-back over some time. Compiling a Linux kernel natively on the target with root file system over NFS gives an excellent stress test, as you hve both lots of code running and context switches and cache fills and flushes combined with lots of DMA (from the network interface) at the same time.
Go back to square one, dig out the RAM chip manual, and re-check your code. Ideally, have somebody else but the original implementor check it.
Best regards,
Wolfgang Denk