[LinuxBIOS] Intel 440bx

[Corey Osgood]

Uwe Hermann wrote:
> On Wed, Feb 28, 2007 at 02:51:35AM -0500, Corey Osgood wrote:
>> 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.
> 
> Please let me know if you remember, it might help a lot :)
> 

Heh, that was 2 nights ago, I can barely remember what I was doing 2
hours ago :D But if I run across it again, I'll make a note of it. It's
one that I changed in my raminit.c, just don't remember which one.

> 
>> 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:
> 
> Hm, I'm not sure I understand. I'll have to take a closer look at the
> datasheet and code. I'll report back as soon as I know more.
> 
> Can you post your own code, too, please?
> 

I've attached my (latest) raminit.c, along with the minicom cap file it
produced. My raminit.c is a mess, with tons of commented code, but it
does compile correctly. I've made comments on ANY registers that I've
changed, usually with just the value that you had and/or the chipset
default. I've also added some extra delays in places, just to see if
that might help, they can probably be safely commented/removed. I also
had to comment out spd_enable_refresh, as I could understand what it
wanted for a value for MAX_DIMM_SOCKETS_PER_CHANNEL.

I've also uploaded my target (which I based on asus p2b, since it was
closer) and my full northbridge folder, to here:
http://fc.umit.maine.edu/~corey_osgood/LinuxBIOSv2.tar.gz

That isn't the full LBv2 tree, just my changes, you can extract it to
your tree it won't overwrite anything, I even renamed i440bx to i440zx
just in case. And before anyone says anything, I'm well aware you can
see everything else I have stored on that server...if my old windows xp
desktop and screenies are worth looking at, be my guest. There's also a
raminit-bx.c in the i440zx folder which has a few changes for debugging
output but without changing any register changes.

>  
>> /* 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 )  ) {
> 
> You probably mean 0x0110 here? (hex vs. decimal!)
> 

I've changed that loop into a while loop, and added a failsafe exit.
Still doesn't get ram working, but it looks and works better, and
doesn't make minicom.cap files in the megabytes range. When outputting
to the serial, SDRAMC reads as 0110 (or at least should), not 0x0110.
I'm assuming it should be the same when dealing with it internally, but
I can't be sure. No matter what though, it should get set, then exit
(through the failsafe) and go along its way now, but doesn't.

> 
>> 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.
> 
> I can't think of a reason why a for loop shouldn't work...
> 

Good, because after adding all that debugging output and a memtest
payload, I ran out of space! I've changed it, but the old code is still
there commented.

-Corey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raminit.c
Type: text/x-csrc
Size: 11831 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070228/53f2fc27/attachment.c>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: latest.cap
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070228/53f2fc27/attachment.ksh>