[coreboot] SeaBIOS debug output
kevin at koconnor.net
Tue Jul 22 03:14:25 CEST 2008
On Sun, Jul 20, 2008 at 01:57:45PM -0700, ron minnich wrote:
> On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor <kevin at koconnor.net> wrote:
> > Right. I'm a proponent of having coreboot be responsible for copying
> > the option roms to their locations in ram. Once coreboot loads the
> > option roms then seabios can easily locate and run them.
> you're assuming they would all fit at one time into 64k. Not
> necessarily the case. What has to happen is copy (or map) the rom, run
> it, remove it, and so on. At least that's how I remember it working.
There is 128KiB for option roms (the 0xc0000 and 0xd0000 segments).
Stefan also mentioned the idea of swapping option roms in and out. I
don't see how this would work. If an option rom wants to be part of
the boot up process it needs to register itself by "hooking" various
16bit handlers and registering pointers to its own code. If the
option rom is then swapped out those pointers would be left dangling.
I suppose one could swap out an option rom that wasn't part of the
boot up process, but it seems odd to me that manufacturers would have
option roms for cards that weren't part of the boot. After all, I'd
guess it is significantly cheaper to develop a cheap windows driver
that initializes the hardware than it is to write esoteric 16bit code,
and shipping a cdrom must be cheaper than putting eeproms on cards.
If we're really strapped for size, I suppose we could use the 0xe0000
and maybe even part of the 0xf0000 segments for option roms. However,
this isn't strictly in spec for option roms.
In any case, I don't see why we need to optimize this. Normal BIOSs
seem to get by fine without needing to do anything special.
> Whatever happens with this discussion, we still need to be able to run
> with things like linux as payload and seabios not there.
I agree. I never envisioned SeaBIOS being a mandatory part of
More information about the coreboot