Supporting extension ROMs and beyond...

[Eric W. Biederman]

ron minnich <rminnich at lanl.gov> writes:

> I guess I have a hard time seeing the difference between linking functions 
> into LB via the static device tree, and calling ELFs, except that you get 
> no space savings with the ELF approach. You're going to create printk etc. 
> functions in every single ELF image, and in fact you'll have a whole "BIOS 
> library" in each and every ELF iamge. 

Possibly.  But that library can be made very small.  printk is a fairly
trivial function.  At least when you are talking the serial console.
 
> All things considered I'd rather link them in. I am very tight for space 
> no the K8 with 1 MB flash, so growing things larger is not an option. 

And this is a real issue that will drive a lot of this.
The standard flash on the K8's I have seen is 512K.
 
> Now if we want to have a way to choose seperate ELF payloads or direct 
> linking them in at build time, that makes lots of sense to me. We can try 
> to look at that. 

I am not certain about multiple payloads.  

But beyond that having etherboot separate has proved very valuable.

1) It totally separates the chipset initialization from booting.
2) It allows usage of a known good etherboot on a development platform.

And only by reusing binaries does this work so well.

As for space constraints once I get romcc fixed to not inline everything
Opteron LinuxBIOS should get as small as the rest of them.

Taking boot loaders to the next step is a very interesting question.  For
the normal case where traditional BIOS's work ADLO looks to be a very
satisfying solution.  For the HPC side this are much trickier.  

For things to think about.  The reason traditional BIOS's are 16bit
real mode beasts is because Windows runs parts of them in vm86 mode.
Which is why 32bit extensions are not common.

Eric