Supporting extension ROMs and beyond...

ron minnich rminnich at lanl.gov
Mon Aug 11 10:20:01 CEST 2003


On 10 Aug 2003, Eric W. Biederman wrote:

> I haven't seen the numbers on the dreaded size overhead.  So
> that argument does not yet convince me.  If I can fit a whole IP/UDP
> stack a network driver, and printk in 16K I have trouble seeing
> the problem.

multiply that by, let's just say 4, for 4 elf payloads for 4 functions. 
At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At 
present I can barely fit one linuxbios + 1 stripped kernel.

I am right on the edge of being able to fit right now. Either I statically 
link in the VGABIOS code or I can't fit it. That's the issue for me.

Yes, I am well aware that we hope to have more compact ROMCC code, but 
that is not there right now.

> Most of the things proposed so far are things I am primarily opposed
> to, at least except way out on the periphery.  Callbacks are bad.

Callbacks are required if we hope to support VGA. There is no way around 
this.

> Binary only code is bad.  

Binary code support is required for future chipsets that, e.g., build
wireless into the chipset. There will be many future software radios that
are in chipsets, and you will not be able to get that in open source --
the FCC has a few things to say about that. Binary code support is
inevitable. We won't be able to compile this code in, or build it as an
ELF module.  That's not going to be an option. 

For linuxbios to succeed in future, we'll need support for these two 
things. I think this is a lamentable state of affairs. But that's how it 
is.

I think long-term the best way to fix it for all architectures is via
emulation, but for the immediate-term we can make callback/binary support 
for the common(-est) case: the x86. 

> And the biggest reason I don't want to go there is because simple
> things tend to be reliable.  And complex things tend to broken.  And
> the extension extension looks to allow a lot of needless complexity
> into LinuxBIOS.

But the limits of poor PC design limit our ability to be simple. The 
original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found 
we need a bit more than that to be workable. 

The single most common request I hear for LinuxBIOS is early VGA support 
-- early enough to see linuxbios messages. You have no idea how often 
this comes up -- or maybe you do :-)

I think we're going to need to do this in a reasonable way, or somebody
will do it for us in an unreasonable way.

> The biggest piece of code everyone has been arguing for including, the
> code to run a vgabios option rom, simply doesn't work in a lot of
> cases, and unless I have overlooked something the reason it doesn't
> work in a lot of cases is a design flaw, it doesn't aim for complete
> pcbios compliance.

That's a factor of time people have had to work on it. The code itself, I 
am told, has proven to be pretty solid for those operations it supports. 

It's possible, the more I think of it, that what we really need is a
payload for solid x86 emulation. That would buy us
architecture-independence which we need. No callbacks either -- just 
emulate the trap and do the code for the callback. Much more reliable than 
callbacks. Very portable.

Still thinking .... more discussion welcome.

ron




More information about the coreboot mailing list