Supporting extension ROMs and beyond...
pyro at linuxlabs.com
Thu Aug 14 12:53:00 CEST 2003
One other call for modular binary support is end users. It's one thing to
get them to use a provided tool to flash in one of several mix and match
modules, it's quite a different matter to get them to actually compile
something correctly and then flash it.
An idea I have for baremetal is to have it set up a callback table at the
top of RAM for all of the useful (and possibly hardware
dependant) functions. It's not too much of a leap to make a compile time
decision to either:
1. End up by calling elfload and running baremetal which has it's own
2. link the baremetal setup in static and just call it.
With a bit of designing any payload should potentially be linkable
againmst either LinuxBIOS to be called directly, or an ELF stub to be
The stub would likely have something like:
int printk(char *format, ...)
return call_table("printk", format ...);
Otherwise, the payload will just link against LinuxBIOS.
The rest would be similar to the way mon can be standalone or linked in to
init for beoboot.
I think some of the different opinions here really come not so much from
philosophical differences as just different goals.
On Mon, 11 Aug 2003, ron minnich wrote:
> 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
> > 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
> 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.
> Linuxbios mailing list
> Linuxbios at clustermatic.org
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 2701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
More information about the coreboot