* Uwe Hermann uwe@hermann-uwe.de [061126 22:03]:
On Sun, Nov 26, 2006 at 07:02:51PM +0100, Segher Boessenkool wrote:
Is that the canonical way to test whether RAM init works?
I suggest you compare the copied image with the original. CONFIG_COMPRESS=0 should make this easier..
src/cpu/x86/car/copy_and_run.c or src/arch/i386/init/crt0.S.lb depending on whether you use CAR or not.
If you use CAR, you need to make sure it is disabled before you do the jump.
Sure, if I could boot Linux or memtest my problems would be solved. But currently I haven't yet managed to do so. The problem now is, that I don't know whether booting memtest fails because I need to setup more of the mainboard-specific stuff or because my RAM init doesn't work yet.
Your problem is a lot earlier. You are not even executing linuxbios_ram yet. This is long before it even looks at the payload.
There _are_ differences, but nothing related to the RAM config registers as far as I can see.
Its probably safe to try poking those values hardcoded into the north bridge.
Hint: Try testing the lower memory:
ram_check(0x10000000, 0x2000000); is going for 256-512 Megs.
The LinuxBIOS image is copied to _RAMBASE which normally defaults to 0x4000 (@16k). So you might have 2 dimms a 256M and while the upper one works, the lower one doesnt.
In the end the ram_check() function does not reliably test your memory. It will not detect whether your memory works, but it will detect whether it fails ;-)
Also note: the order in which your registers are set may play a role. For example there might be a register with a DRAM_ENABLE bit which must be set last, after all other DRAM related bits are set, or the values set later on might be ignored.
Grouping the register value hardcode pokes might be a good idea, to find out which registers have to be set in which context...
Stefan