[LinuxBIOS] [PATCH] Add Intel i810, i82801aa (ICH) and Asus MEW-VM support

[Uwe Hermann]

On Sun, May 27, 2007 at 04:48:51AM -0400, Corey Osgood wrote:
> >   #define I82801AA 1
> 
> Agreed, as long as no further fixup is necessary. Perhaps I'll just hold
> onto this patch until I can fully test out the southbridge function, or
> else we could commit as-is and I'll do some cleanup later. 

I think we can commit with the #ifdefs even if you didn't test the
southbridge code on real hardware. The changes should not break any
existing targets, only add support for the i82801aa so that's fine.

 
> I should probably stress here that I haven't yet gotten serial output
> from a booting linux kernel although I do get to "loading kernel" and
> "loading initrd", see log attached. For some reason the stock ubuntu
> kernel either ignores that option, or else can't do it with the super io
> not going through its usual post-ram init. Or else the kernel just isn't
> booting at all. I'll work on testing all those possibilities soon.

Did you configure FILO with 'USE_GRUB = 1' and tell GRUB to pass the
'console=tty0 console=ttyS0,115200' to the kernel?


> I'll also look into the i82801er, and see what/where the big changes
> are. Perhaps all 3 can be merged into one big i82801xx mess.

Yeah, I think that would be the best option (if possible). We would use
the southbridge with the most features and make the other ones only use
the subset of the code they need...

And another i82371xx for that series etc...


> > Poll: do we want i810 or rather i82810? For the southbridges we use the
> > full names (e.g. i82801aa), why don't we do the same with the
> > northbridges?
> > 
> > (yes, that would also change i440bx to i82443bx)
> 
> Probably we should, the i440bx seems to be the only device known by its
> marketing name rather than part name, and some of the naming conventions
> marketing departments use are just plain stupid (*cough* Via *cough
> cough*). I'll fix the i810 as well.

Yep, ok. Will post 440BX rename patch soonish...


> > Did you test the delays? It's likely that smaller values will suffice
> > (not too important, though, RAM init is pretty fast anyway).
> > 
> 
> Yep, everything pre-ram has been tested on several 128mb single-sided
> dimms, guess I should have attached a boot log the first time. This was
> based on my copy of i440bx's raminit.c, and those delays work on there
> as well. They might be able to be tightened further, but I seriously
> doubt anyone's going to notice even a 50% speedup to a 200 microsecond
> delay.

Maybe not much, but I think someone recently said that the delays can be
tightened a _lot_. I think we should do it, even if the speedup is
barely measurable...


> Anyways, just realized that the same superio is used by the
> xe7501devkit, and I doubt that would have been committed if it wasn't
> working.

Don't make too many such assumptions. We _do_ have some broken code in
the repository ;)


> There isn't that I can find, just about every mainboard has its own
> debug.c, and all are nearly identical. I'll do some more grepping, and
> see if I can find the functions in a file with a different name. Any
> suggestions where to put a generic one, if it comes to that? I'm
> thinking src/include/debug/mainboard_debug.c (and northbridge_debug.c,
> since it's the same way). Or else combine all the functions into one big
> debug.c and put it in the same place.

Yep, one big debug.c, I think.

See also http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/66, btw.


> > > Index: src/mainboard/asus/mew-vm/auto.c
> > 
> > Oh, I'm not sure this will work or is a good idea.
> > 
> > I'd rather use "mew_vm" (instead of "mew-vm"). Pathnames may appear as
> > variable names (for instance) in C code, that's also why all directory names
> > start with a letter (i440bx, not 440bx).
> > 
> > Same for dashes, "mew-vm" is not a valid C variable name.
> 
> Somehow, somewhere in the build process, the dashes in the folder
> name(s) get converted to an underscore, so all the variables are named
> *mew_vm*, and this builds/runs just fine. If it still needs to be
> changed, just let me know.

Hm, I think I was wrong. The i82371eb name issue is indeed important, the
"i82371eb" is used in variable names, so it must start with a letter.

The directory names (e.g. mew-vm) seem to work, though. We already have
epia-m, for instance. Sorry, my bad.

Not sure whether something converts that to "mew_vm" or whether we just
don't use "mew-vm" in variable names... Using it in includes, e.g. as

  #include "asus/mew-vm/foo.h"

should work flawlessly.

Is this correct? Please someone let me know if I'm making stupid
assumptions...


> Booting 'hda1:/boot/vmlinuz-2.6.17-11-generic root=/dev/hda1 ro single console=
> tty0 console=ttyS0,115200 initrd=/boot/initrd.img-2.6.17-11-generic'

Hm, is the newline between "console=" and "tty0" really there in the
config file?

Otherwise it looks good, maybe your kernel has indeed no support for
serial console compiled in?

What does 'grep SERIAL config-2.6.21-1-686' say (or whatever kernel you
use)? Don't know what the exact name of kernel config option is...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070527/e1167c3a/attachment.sig>