[coreboot] v2: The elfboot process with 128MB RAM
Mats Erik Andersson
mats.andersson at gisladisker.se
Thu Sep 11 15:53:30 CEST 2008
I copy your original text to the mailing list, in order that you get
proper credit for the solution I found, based on your comment.
> Hello Mats,
> Regarding the Coreboot issue, I was wondering whether you already had a
> look at the do_ram_command() function in
> Frankly, the comment there saying "TODO: Support for multiple DIMMs."
> raises an alarm here. A cursory look at the current implementation
> suggests to me that the command has to be sent to each separate DIMM
> module, probably even each "side" for double-sided DIMMs. At a guess, I
> think the read32() has to be done to all of the starting addresses for
> each side, i.e. the addresses corresponding to the values stored in the
> DRB registers 0x60-0x67.
> It is unlikely I can start testing this before saturday, so I'd like to
> know what you think of it and possibly save you some more of this goose
> Kind regards,
Yes, I have shared your irritation concerning that remark in do_ram_command(),
but I thought the read32-statement to be harmless without deeper sense.
However, I just found that it is instrumental. Starting from one of the
code structures that I mentioned in my previous posting, I made sure that
the end of do_ram_command() contains
/* Read from (DIMM start address + addr_offset). */
read32(0 + addr_offset); // FIXME
+ read32(0x04000000 + addr_offset);
The third and last line is the new addition, and it reflects the fact
that I wanted to perform a test with a double sided 128MB DIMM card.
Thus there is a read from both banks/rows after each ram-command.
The outcome is that Coreboot indeed is able to leave the elfboot stage,
enter Filo, and finally getting my Debian router going. For the sake of
testing I made sure the router ran its complete file system in RAM,
which means slightly over 70MB usage. It was a success!
As a next test run I used two double sided 128MB SDRAM cards. As expected
the RAM memory verified on 1M -- 128MB--, Coreboot reported 256MB available,
but elfboot got stuck before entering Filo. This fits very well with the
idea that somehow (seemingly magically) the northbridge does not acknowledge
memory banks 2 and 3 as alive, it only has access to banks 0 and 1.
It would thus be necessary to incorporate also
+ read32(0x08000000 + addr_offset);
+ read32(0x0c000000 + addr_offset);
at the end of do_ram_command(). Case closed!
I will now take time (a few days) to beautify my changes to the file
src/northbridge/intel/i440bx/raminit.c, in order that I may submit it
to Coreboot. The lesson to be learned here, is that Uwe Hammer did good work
in the original implementation, but that naked TODO/FIXME are not enough
to pinpoint the problems or shortcomings of temporary code chunks.
Any fellow developer is better off with some explicit remark that
helps to indicate some presumption behind a particular piece of code.
Many thanks for your help Tim! Best regards for now,
Mats E Andersson
More information about the coreboot