[LinuxBIOS] i810 support on its way!

[Corey Osgood]

Intel i810/i82801aa/b support should be on its way soon, I hope the
folks that were asking about it are still subscribed. i815 will follow
soon after. minicom.cap attached, I've still got a few quirks to work
out (like finishing the south bridge and a quick fix to ram size
setting), but ram init seems to be working. Expect more in a couple
days. Asus MEW-VM is the current target board, for anyone curious. BTW,
SMSC LPC47B272 is listed as unknown on the wiki, I can confirm that at
least the pre-ram code works.

Also, if anyone has any info relating to the setting of the buffer
strength, neither datasheet is clear on it, just that it depend on if
the ram is x8, x16, or x32. I have x8 and x16 ram sticks that I can test
how the factory bios sets up, but I think the only x32 stick I have is
512mb, which is more than the i810 supports.

-Corey

Quoting Corey Osgood :
> Intel i810/i82801aa/b support should be on its way soon, I hope the
> folks that were asking about it are still subscribed. i815 will follow
> soon after. minicom.cap attached, I've still got a few quirks to work
> out (like finishing the south bridge and a quick fix to ram size
> setting), but ram init seems to be working. Expect more in a couple
> days. Asus MEW-VM is the current target board, for anyone curious. BTW,
> SMSC LPC47B272 is listed as unknown on the wiki, I can confirm that at
> least the pre-ram code works.
>
> Also, if anyone has any info relating to the setting of the buffer
> strength, neither datasheet is clear on it, just that it depend on if
> the ram is x8, x16, or x32. I have x8 and x16 ram sticks that I can test
> how the factory bios sets up, but I think the only x32 stick I have is
> 512mb, which is more than the i810 supports.
>
> -Corey

Great Job Corey!! Guess you beat me too it. That's ok, I am just glad  
too see it going! :-)

Thanks - Joe

[LinuxBIOS] ALi M1621 support and general support for other NBs

[popkonserve]

i'm currently implementing raminit functions for the ALi M1621 
(Aladdin-Pro II) chipset. They should be working without any SPD data at 
least for the detection of the RAM type and size(s). In general i think 
that size and type detection is the same on most chipsets (if not all) 
especially if it comes to EDO/FPM detection.
SPD data should be used for timing parameters only..and even if there's 
no SPD data at all generic speed detection methods could be applied (set 
aggressive timings, write data, read back and compare, adjust timings if 
necessary).

still a question remains: should we add overclocking options somewhere? 
maybe in the config file?

as this would be my first contribution: is anybody willing to take a 
look into the sources? i guess they could be adapted for many older 
socket7 chipsets easily.
regards,
Holger

[LinuxBIOS] ALi M1621 support and general support for other NBs

[Stefan Reinauer]

* popkonserve  [070517 12:52]:
> i'm currently implementing raminit functions for the ALi M1621 
> (Aladdin-Pro II) chipset.

great!
> They should be working without any SPD data at least for the detection
> of the RAM type and size(s). In general i think that size and type
> detection is the same on most chipsets (if not all) especially if it
> comes to EDO/FPM detection.

Can't SPD data just be used to do that?

Size and type detection definitely wont work without SPD-ROMs for SDRAM
and all kinds of DDR.
> SPD data should be used for timing parameters only..and even if there's 
> no SPD data at all generic speed detection methods could be applied (set 
> aggressive timings, write data, read back and compare, adjust timings if 
> necessary).

On DDR we use SPD for everything. Why do you say it should not be used
for sizes ?
> still a question remains: should we add overclocking options somewhere? 
> maybe in the config file?

First thought: No.

Second thought: If it does not waste the algorithms and keeps them
readable. Why not..
> as this would be my first contribution: is anybody willing to take a 
> look into the sources? i guess they could be adapted for many older 
> socket7 chipsets easily.

Sure. When you have something working, send it to the mailing list. No
code gets into the repository without being reviewed first, so there is
plenty of opportunity for discussion

[LinuxBIOS] ALi M1621 support and general support for other NBs

[popkonserve]

> > detection is the same on most chipsets (if not all) especially if it
> > comes to EDO/FPM detection.
>
> Can't SPD data just be used to do that?

there is no SPD for EDO/FPM rams so testing would be the only way to 
determine size and type (and chipsets have special functions to do 
that). even if there is SDRAM we still could have problems reading it if 
we don't know on which GPIOs clk/data is connected.
> Size and type detection definitely wont work without SPD-ROMs for SDRAM
> and all kinds of DDR.

we still could run into problems on sdrams with wrong SPD data. some 
very cheap modules came with incorrect data programmed into the SPD 
chips. but the main reason is that there are mainboards that might not 
provide SPD data since we don't know where the clk/data lines are connected.
> On DDR we use SPD for everything. Why do you say it should not be used
> for sizes ?

it should only be used for fallback if we can't (yet) obtain any SPD data.
> > still a question remains: should we add overclocking options somewhere? 
> > maybe in the config file?
>
> First thought: No.
>
> Second thought: If it does not waste the algorithms and keeps them
> readable. Why not..

the timing information would just be inserted into the data read by the 
dram detection algorithm. though i still don't know if i would implement 
timing detection into the dram detection algorithm.
as i already wrote: no SPD on EDO/FPM, so speed detection would be 
writing, reading back and comparing.

btw. a generic dram detection mechanism for EDO, FPM and SDR would look 
kinda like this:

1. set dram type to EDO
2. set dram size to max. chipset supports
3. set dram addressing scheme to std.
4. write D1=0x5555555555555555 to A0=0x0
5. write D2=0xaaaaaaaaaaaaaaaa to A8=0x8
6. enable EDO detection (chipset feature)
7. read back data at A0
8. compare result to D1. if unequal goto 12
9. read back data at A8
10. compare result to D2. if unequal goto 12
11. dram type is EDO :)
12. dram type is FPM or SDR

now there are some more checks that determine the real size of the EDO 
ram (remember: we assumed that it is max. chipset supports) and the 
correct addressing scheme.

[LinuxBIOS] ALi M1621 support and general support for other NBs

[Uwe Hermann]

Hi Holger!

On Thu, May 17, 2007 at 12:52:26PM +0200, popkonserve wrote:
> i'm currently implementing raminit functions for the ALi M1621 
> (Aladdin-Pro II) chipset. They should be working without any SPD data at 
> least for the detection of the RAM type and size(s). In general i think 
> that size and type detection is the same on most chipsets (if not all) 
> especially if it comes to EDO/FPM detection.
> SPD data should be used for timing parameters only..

I'm not sure I agree. If we _do_ have SPD data we should use it, almost
all boards currently have an SPD-driven RAM init.

Only if SPD data is not available we should use other means, IMHO.
> still a question remains: should we add overclocking options somewhere? 
> maybe in the config file?

Well, yes if you can do it, that would be great. I'd not care much about
this at the moment, though. The first step is to make it work at all,
then you can start worrying about some of the more 'esoteric' features...
> as this would be my first contribution: is anybody willing to take a 
> look into the sources?

Sure, please send patches (even non-finished, preliminary patches) for
review...

Also, make sure to read through
http://linuxbios.org/Development_Guidelines, especially the sign-off
procedure and the license header sections...

Cheers, Uwe.

Quoting Corey Osgood :
> Intel i810/i82801aa/b support should be on its way soon, I hope the
> folks that were asking about it are still subscribed. i815 will follow
> soon after. minicom.cap attached, I've still got a few quirks to work
> out (like finishing the south bridge and a quick fix to ram size
> setting), but ram init seems to be working. Expect more in a couple
> days. Asus MEW-VM is the current target board, for anyone curious. BTW,
> SMSC LPC47B272 is listed as unknown on the wiki, I can confirm that at
> least the pre-ram code works.
>
> Also, if anyone has any info relating to the setting of the buffer
> strength, neither datasheet is clear on it, just that it depend on if
> the ram is x8, x16, or x32. I have x8 and x16 ram sticks that I can test
> how the factory bios sets up, but I think the only x32 stick I have is
> 512mb, which is more than the i810 supports.
>
> -Corey

How's it going with this Corey?

Thanks - Joe

[Corey Osgood]

[e-mail] wrote:
> Quoting Corey Osgood :
> > Intel i810/i82801aa/b support should be on its way soon, I hope the
> > folks that were asking about it are still subscribed. i815 will follow
> > soon after. minicom.cap attached, I've still got a few quirks to work
> > out (like finishing the south bridge and a quick fix to ram size
> > setting), but ram init seems to be working. Expect more in a couple
> > days. Asus MEW-VM is the current target board, for anyone curious. BTW,
> > SMSC LPC47B272 is listed as unknown on the wiki, I can confirm that at
> > least the pre-ram code works.
> >
> > Also, if anyone has any info relating to the setting of the buffer
> > strength, neither datasheet is clear on it, just that it depend on if
> > the ram is x8, x16, or x32. I have x8 and x16 ram sticks that I can test
> > how the factory bios sets up, but I think the only x32 stick I have is
> > 512mb, which is more than the i810 supports.
> >
> > -Corey
>
> How's it going with this Corey?
>
> Thanks - Joe

See the attached minicom.cap and attached patch (not ready for commit).
The current problems:

*Detecting dual-sided dimms even on single sided dimms with correct spd
values? Possibly getting the wrong SPD byte, could be smbus-related or
northbridge's translation of them, most likely the latter.
*Hanging at the end of minicom.cap - could be related to the previous,
haven't dived into it too far yet. It also could be a bug in the smsc
lpc47b272 or the southbridge.
*Lots of "PCI: devfn 0xX, bad id 0xffffffff", need to figure out where
these are coming from and why.

I have not yet tried with hardcoded ram size values, since I have been
too busy with work (you caught me on my lunch break). Also, GPL headers
are very much messed up, and the i82801aa (aka ICH) is a quick and dirty
copy and paste from 82801ca with the device IDs changed, so there could
be some problems there. I've been going over the i82801aa datasheet, and
its 414 pages of mass confusion. You can also see some stuff in i810.h
where I started to work towards i815 support as well, but that isn't
going to work out due to device ID issues. This will work (in the end)
on the i810 and i810-DC100 though. Anyways, feel free to
modify/test/play with it as you please. I can't get back to it until monday.

-Corey