[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:
RAM_DEBUG_MESSAGE(" SDRAMC = ");
print_debug_hex16(pci_read_config16(ctrl->d0, SDRAMC));
RAM_DEBUG_MESSAGE("\r\n");
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);
read32(0x04000000);
EXTRA_DELAY
}
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.
-Corey
More information about the coreboot
mailing list