[coreboot] v2: The elfboot process with 128MB RAM

Joseph Smith joe at settoplinux.org
Thu Sep 11 16:13:04 CEST 2008

On Thu, 11 Sep 2008 15:53:30 +0200, Mats Erik Andersson
<mats.andersson at gisladisker.se> wrote:
> Hello Tim,
> 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
>> src/northbridge/intel/i440bx/raminit.c?
>> 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
>> chase.
>> Kind regards,
>>    Tim.
> 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!
That's what I thought. That read32() is what initializes each side/bank/row
of memory. I was having a simular problem with the i830 and this is what I
came up with:

	/* Send the ram command to each row of memory.
	 * (DIMM_SOCKETS * 2) is the maximum number of rows possible.
	 * Note: Each DRB defines the upper boundary address of 
	 * each SDRAM row in 32-MB granularity.
	dimm_start = 0;

	for (i = 0; i < (DIMM_SOCKETS * 2); i++) {
		dimm_end = pci_read_config8(ctrl->d0, DRB + i);
		if (dimm_end > dimm_start) {
			PRINT_DEBUG("    Sending RAM command 0x");
			PRINT_DEBUG(" to 0x");
			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
			read32((dimm_start * 32 * 1024 * 1024) + addr_offset);
		/* Set the start of the next DIMM. */
		dimm_start = dimm_end;

And it works beautifully, maybe you would want to impliment something like
Of course you would have to make some minor adjustments.

Joseph Smith

More information about the coreboot mailing list