Hello, I'm currently taking a look at modifying the bayou payload in order to make it work on a modern coreboot system. The conversion seems pretty straightforward except for a few points that I'm unsure about since I don't know what the situation was during the coreboot-v3/LAR era or what was the payload's design process like.
1) Bayou is currently designed this way:
* Take user-written xml configuration * Use pbuilder utility to parse the config * pbuilder then generates a single blob containing every payload specified (it also performs elf->self conversions, adds the payloads to the blob, etc.) * Bayou (when executed) takes a compressed blob * Reads the configuration from it * Parses through the blob looking for each payload specified * Follows the rest of the configuration
This design choice seems a bit inappropriate given that we are nowadays used to store multiple secondary payloads directly inside the cbfs (with the re-introduction of bayou "secondary payloads" could also be expanded to contain all the payloads).
I'm instead thinking of doing the following changes:
* Doing away with the blob * Storing the configuration inside the cbfs as a cbfs_file * Parse the configuration directly from the cbfs * Use cbfstool to handle all addition/removal of payloads to the cbfs * Eliminate pbuilder
This seems to be a much cleaner solution than the current one. I currently don't see any downsides to it but I would like to hear other opinions on the matter.
That approach sounds correct to me and should be a fun little project.
And for historical reference: http://bayoubobs.com/contact/
Marc
On Mon, Jul 25, 2016 at 3:39 AM Antonello Dettori dev@dettori.io wrote:
Hello, I'm currently taking a look at modifying the bayou payload in order to make it work on a modern coreboot system. The conversion seems pretty straightforward except for a few points that I'm unsure about since I don't know what the situation was during the coreboot-v3/LAR era or what was the payload's design process like.
Bayou is currently designed this way:
- Take user-written xml configuration
- Use pbuilder utility to parse the config
- pbuilder then generates a single blob containing every payload
specified (it also performs elf->self conversions, adds the payloads to the blob, etc.)
- Bayou (when executed) takes a compressed blob
- Reads the configuration from it
- Parses through the blob looking for each payload specified
- Follows the rest of the configuration
This design choice seems a bit inappropriate given that we are nowadays used to store multiple secondary payloads directly inside the cbfs (with the re-introduction of bayou "secondary payloads" could also be expanded to contain all the payloads).
I'm instead thinking of doing the following changes:
- Doing away with the blob
- Storing the configuration inside the cbfs as a cbfs_file
- Parse the configuration directly from the cbfs
- Use cbfstool to handle all addition/removal of payloads to the cbfs
- Eliminate pbuilder
This seems to be a much cleaner solution than the current one. I currently don't see any downsides to it but I would like to hear other opinions on the matter. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot