[LinuxBIOS] Intel 440bx

Corey Osgood corey_osgood at verizon.net
Wed Feb 28 08:51:35 CET 2007

Uwe Hermann wrote:
> On Mon, Feb 26, 2007 at 04:24:04PM -0500, Corey Osgood wrote:
>> I'm currently playing with the raminit.c that I've attached, it's from
>> one of his old posts. Uwe, have you done anything more since this? And
>> do you have a new northbridge.c also? Mine's a hack from what was there
>> (fixing regs, etc), I have no idea if it works right or not.
> I'll post a full patch which should work out of the box (the
> infrastructure for building the target at least).

Okay, thanks. I'm not sure if my target's set up right or not, but it
seems to be working for now. Even if mine is correct, yours will
probably be cleaner by far ;)

> I did try some more things to get the code to work properly, but with no
> success so far. I'm pretty sure it's some small quirk I got wrong, but
> I haven't found out what it is, yet. Maybe a timing issue...
> The code will probably not work for you as is, you must adjust it to the
> extact RAM you're using (and location of the RAM, i.e. in which RAM slot
> it is located).
>> Just out of curiousity, in sdram_set_registers, are those values
>> you decided to send, or ones from a running system?
> Yes, mostly. I got them from a running Linux on exactly the same system
> (you should not change jumpers, RAM parts, CPU, whatever, or else those
> values will probably also change).
> You can get the northbridge values via: lspci -xxx -v -s 00:00.0

I've already gotten the DRB registers set up for my configuration, along
with changing a half a dozen registers or so to fit my lspci -xxx and
the 440zx docs (for instance, your NBXCFG sets ECC, which the 440zx
doesn't support). It hasn't made any huge difference though. There was
one register that I meant to point out to you as having an odd value,
but I can't remember now which one it was.

I don't know if you've noticed this or not, but with your raminit.c,
your do_ram_command seems to be doubling the value it should be setting.
I added this to the end of it:

	print_debug_hex16(pci_read_config16(ctrl->d0, SDRAMC));

And got this:

Ram Enable 1: Power up
Ram Enable 2: Start clocks
Ram Enable 3: Apply NOP
    SDRAMC = 0120
Ram Enable 4: Precharge all
    SDRAMC = 0140
Ram Enable 8: CBR
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
    SDRAMC = 0180
Ram Enable 9: Mode register set
    SDRAMC = 0160
Ram Enable 11: Normal operation
    SDRAMC = 0100
Finally enabling refresh

If you can't see the problem, I can't really explain it...NOP should be
0110, Precharge should be 0120, and so on, they're all double in the 3rd
value. So, I commented all the do_ram_commands out (since I can't see
the problem with it) and did ram init using pci_write_config16, setting
what I know the values should be, and then NOP would not report as being
set (and ram still failed). So, I set up a for loop to set NOP until the
northbridge reported that it was set...I got an infinite loop. My loop
might be wrong (it's a bit hackish), can someone tell me if it should
work? Or does NOP simply not set?

/* 3. Apply NOP. */
RAM_DEBUG_MESSAGE("Ram Enable 3: Apply NOP\r\n");
int s;
for( s = 0; s != 0110; s = pci_read_config16( ctrl->d0, SDRAMC )  ) {
	RAM_DEBUG_MESSAGE("Do NOPs til it cooperates!\r\n");
	pci_write_config8(ctrl->d0, SDRAMC, 0x0110);

If that's all set, I suspect there's some register that has to be
changed before it will set NOP, perhaps one not in the docs.

Finally, is there any reason not to use a for loop during CBR? I've
noticed that noone seems to, but it would make the code so much cleaner.


More information about the coreboot mailing list