The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
Bayou is the working name for a coreboot payload that can chose, load and run other payloads from a LAR archive on the ROM.
We need a little bit of originality in the names of our payloads, as Peter discusses here. In the grand tradition of El Torito, we decided to name the project after the restaurant where we ate lunch and debated the payload chooser during the coreboot summit in Denver: Bayou Bob's. The word bayou is French in origin, but it famously describes slow or stagnant streams and swamps in the southern United States (see also Bayou at wikipedia. The name in no way describes the project itself, which should neither be slow nor swampy.
The following are the two usage models for the payload:
This usage model presents a menu to the user containing the descriptive names of all the payloads in the LAR. The user selects an item from the list, and bayou loads and runs the payload. If the payload is responsible enough to be able to exit cleanly (as all libpayload payloads should be able to do) and return control to bayou, then the user can select a different payload.
Chaining is a non-interactive usage model wherein Bayou will load and execute a series of payloads in order. The payloads must be able to return control to bayou cleanly (except the "final" payload which isn't expected to return). This will loosely imitate a traditional BIOS in that one could define a "BIOS setup screen" payload that ran before FILO or other kernel bootloader.
The architecture of bayou is rather simple. It is a libpayload based application with code for reading and loading payloads from a LAR and an front end user interface. The bayou code itself lives below 640k so that it can stay resident when loading payloads that would typically locate themselves at 1Mb or higher. Payloads that want to work cleanly with bayou should not write to memory below 640k unless it is a "final" payload (i.e. something that will not return to bayou, such as the Linux kernel). Bayou will read, load and execute payloads encoded in the Simple Executable Loader Format, decompressing them if needed (with lzma).
There are several parameters that the payload can set to control the behavior of bayou. These are passed in through the PARAMS section in the SELF:
|name||This is the short name of the payload, which is displayed in the log and in the chooser menu if 'listname' is not defined|
|listname||This is the name shown in the chooser menu|
|desc||This is a verbose description of the application that will be displayed in the "help" section in the chooser menu|
The following is an example of macros a typical payload would use to set the above values:
PAYLOAD_PARAM(name,"coreinfo"); PAYLOAD_PARAM(listname,"System Information"); PAYLOAD_PARAM(desc,"Display information about the system");
Changes to coreboot
In order to support bayou, some drastic changes need to be made to coreboot and associated projects. The following is a short synopsis of these changes.
- Coreboot needs to be modified to understand and load the SELF format
- The LAR design needs to be modified so that coreboot can identify and boot the "default" payload. Captain Obvious says: call it payload/default (or normal, or whatever). No evil bit in LAR required to find it.
- The LAR utility must be modified to build LAR images with SELF payloads
- The LAR utility needs to be modified to allow the user to specify a long descriptive name to be included in the NAME segment
- A rewrite of the frontend of the LAR utility may be needed to fully support all the features
Instead of modifying LAR and putting even more features into it, how about creating an elf2self (and back) tool, and just add those files into lar? Sure, it's another build step, but it's "one tool for one job", allows for interesting development, adoption of self beyond coreboot, ... - and we really already have enough build steps that this additional one won't hurt either.
- Buildrom must be adapted to build multiple payloads during the same run
- Add generic LAR walking code Done
- Ensure that libpayload based payloads can cleanly return control to the master payload
- Modify the build system to allow the configuration system to modify the payload entry point