[PROPOSAL] extended payload handling
stepan at openbios.org
Fri Jun 11 05:44:01 CEST 2004
* Hendricks David W. <dwh at lanl.gov> [040608 21:48]:
> On Tue, 8 Jun 2004, Stefan Reinauer wrote:
> > LinuxBIOS can currently execute one payload. For greater flexibility and
> > isolated development cycles of the firmware related code parts/projects
> > LinuxBIOS should allow payload chains, ie. executing multiple payloads
> > one after the other.
> Sounds good. How would you suggest bringing up payloads in a certain
> order? Say you wanted a payload to boot a SCSI controller and then another
> payload to boot off a SCSI disk? You'd need a certain order, and you'd
> have to make certain one payload didn't wipe out another.
The order could be coded in the config file. Scenarios with getting this
from cmos could exist, but I think the order is pretty constant
> There are also instances where one might wish to keep the payload in tact
> even after the operating system has booted, such as using OpenBIOS as a
> LinuxBIOS payload.
In such a case, the payload should take care of staying resident itself.
Everything else would probably require callbacks.
> > Feature plugins like "testbios" should not be merged into LinuxBIOS'
> > core code. Instead they should be implemented as a payload. Since we
> What about VGA, which requires testbios? If it were to be run
> strictly as a payload, we would have practically no useful BIOS
> information display on the screen before the bootloader or Linux comes up.
Currently, with the ati rage xl graphics card, you won't get any output
before pci resource allocation is done and the init drivers get executed
If PCI resource allocation would be a seperate payload, then testbios
could also run directly after that.
More information about the coreboot