[U-Boot] Problem with U-Boot with running in RAM
Hi
I have a problem with running the U-Boot on my own board. The target porcesser is a MPC8377E with DDR2 ram.
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. But the thing is that this is not every time uboot try to relocate itself to RAM.
It is only sometimes it fails, and it is not the same place in the RAM. If i use my J-Tag (lauterbach), to see what data there is in the RAM, where register r7 point to when the rellocate fails. And also look at the data on the r8 which is in FLASH. Then I see that my data in RAM is not steady. But if I stop with reading this data. And instead look another place in ram(0x0). It is steady. If I then view where the register r7 point to then the data on place 0x0 start switching.
Little example on how the data is switching place.
0x1FF80000 _ _ _ _ _ _ _ _ _ _ _ _ _ _ X X _ _ 0x1FF80008 _ _ _ _ _ _ _ _ _ _ _ _ _ _ X X _ _ 0x1FF80010 _ _ _ _ _ _ _ _ _ _ _ _ _ _ X X _ _ 0x1FF80018 _ _ _ _ _ _ _ _ _ _ _ _ _ _ X X _ _
The data on place X X Correct Switched data data 12 34 23 56 34 12 56 23
All other data is steady, and I tried to write different pattern in the RAM. When U-Boot is up running correct I had tried to do some mtest with the uboot memory testcommand.
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. And I thought that only bursted mode access was possible to the RAM on DDR2?
So a lot of information hope anyone will help me a little bit. Or maybe someone has seen a problem seminary.
Thanks for your time.
/LSkov
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
participants (2)
-
Lasse Skov -
Wolfgang Denk