[LinuxBIOS] 440BX progress.
segher at kernel.crashing.org
Fri Dec 1 01:05:39 CET 2006
>> Be careful
>> to set the enable bit (bit 7 in 0xe7) last.
> Yep. As the last step in sdram_set_registers() or as the last step
> in RAM init in general?
The last step of setting the registers e0..ef.
>> Also, you probably didn't program the MRS on the memory.
> Yes, I'm quite sure I messed that up.
Heh, nothing will work then ;-)
> In general, in do_ram_command() I
> have to set DRAMC bits 7-5 to the respective command and then read32
> () from
> some memory location for the change to "take effect", right?
Write to that location, instead. It's not that you make
"a change take effect" -- it directly sends a command on
the memory bus, instead.
> If so, which memory location is that? Does it depend on some input
0x1d0 in the rank, typically. There is some tiny
documentation in the intel sheet; the idea is to send
the correct pattern on the DRAM address pins (use the
selected map to figure out what pattern that is).
> I still don't really understand this part of the RAM init, so the code
> might be very, very wrong...
SDRAM requires an initialisation sequence to work
properly. One of the steps of that init sequence
is programming the MRS register, so the DRAM knows
what CAS latency (CL) is in use, what burst length
>> You should do that with the register at 0x76. The correct
>> sequence is:
>> - precharge all banks, wait tRP
>> - refresh, wait tRC (do this step 8 times)
>> - write to MRS, wait 2 memory cycles
> I think I got this part right mostly.
How about you show the code, much easier to diagnose
that way :-)
> Attached is my stripped-down raminit.c which does the bare minimum
> hardcoding of the values and nothing more.
I'll have a look at it later.
> It doesn't work, and
> after quite a lot of testing I can't seem to find the problem(s).
> Shifting by 15 causes a hang in ram_check() so I tried 23 (looking at
> the v1 code). Again, I don't know what I'm doing here ;-)
I'm not too sure either, but I'll see what I can find.
> Btw, I'm now running ram_check(0x1000, 0x4000000); which should check
> all of the 64MB of RAM, right?
Well except for the low 4kB, heh ;-)
More information about the coreboot