[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_HEX32(reg32);
			PRINT_DEBUG(" to 0x");
			PRINT_DEBUG_HEX32((dimm_start * 32 * 1024 * 1024) + addr_offset);
			PRINT_DEBUG("\r\n");
			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
this?
Of course you would have to make some minor adjustments.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org





More information about the coreboot mailing list