The latest SeaBIOS git can now handle lzma compressed payloads in CBFS. To use, simply place a coreboot payload in the "img/" directory of the cbfs flash. For example:
./cbfstool ./coreboot.rom add-payload coreinfo.elf img/CoreInfo l
One can then boot the image by selecting it from the "F12" boot menu.
SeaBIOS does not yet support compressed option roms. The cbfstool doesn't seem to support this yet - support will be added to SeaBIOS as it becomes available.
To provide the above, an lzma decoder is compiled into SeaBIOS. This adds about 3400 bytes of code to SeaBIOS (~1600 bytes to an lzma compressed SeaBIOS image).
-Kevin
On Sun, Apr 26, 2009 at 11:40:38PM -0400, Kevin O'Connor wrote:
SeaBIOS does not yet support compressed option roms. The cbfstool doesn't seem to support this yet - support will be added to SeaBIOS as it becomes available.
I have a proposal for adding compressed option roms. Right now, option roms are stored as "pciVVVV,DDDD.rom". Instead, regular uncompressed option roms could be stored as "rom/pciVVVV,DDDD" and lzma compressed roms could be stored as "rom/pciVVVV,DDDD.lzma".
This solution is simple and wouldn't require any special cbfstool support.
Comments? -Kevin
Am 27.04.2009 08:07, schrieb Kevin O'Connor:
I have a proposal for adding compressed option roms. Right now, option roms are stored as "pciVVVV,DDDD.rom". Instead, regular uncompressed option roms could be stored as "rom/pciVVVV,DDDD" and lzma compressed roms could be stored as "rom/pciVVVV,DDDD.lzma".
This solution is simple and wouldn't require any special cbfstool support.
Comments?
We already have a cbfs_optionrom header in cbfs.h, which contains a compression field. It's just not hooked up yet. For consistency, I'd rather use that.
Patrick
On Mon, Apr 27, 2009 at 08:11:22AM +0200, Patrick Georgi wrote:
Am 27.04.2009 08:07, schrieb Kevin O'Connor:
I have a proposal for adding compressed option roms. Right now, option roms are stored as "pciVVVV,DDDD.rom". Instead, regular uncompressed option roms could be stored as "rom/pciVVVV,DDDD" and lzma compressed roms could be stored as "rom/pciVVVV,DDDD.lzma".
We already have a cbfs_optionrom header in cbfs.h, which contains a compression field. It's just not hooked up yet. For consistency, I'd rather use that.
Hi Patrick,
I'm not convinced that cbfs_optionrom is the right path. I envision storing splash screens, config files, and disk images in addition to option roms. I don't want to add cbfs support for each new file.
In any case, a simple filename test is only a few lines of code, so I added it to SeaBIOS. It can be changed if it needs to.
Latest SeaBIOS git will take either an uncompressed rom (eg, "pci1013,00b8.rom") or an lzma compressed rom (eg, "pci1013,00b8.rom.lzma").
-Kevin
Am 28.04.2009 04:00, schrieb Kevin O'Connor:
I'm not convinced that cbfs_optionrom is the right path. I envision storing splash screens, config files, and disk images in addition to option roms. I don't want to add cbfs support for each new file.
Quite simple: There will be a generic header for everything that doesn't require special handling. And that header comes with a compression field, too.
As for special handling: Payloads are stored in SELF format, and thus "special" Stages are internal to coreboot. Whatever helps coreboot is fine here. Option ROMs contain the vid/did as fields for faster retrieval.
We might want to define a couple of file types (those IDs you use with "cbfstool" as the last argument) for various purposes (eg. the one you mentioned above), but they all would use the same "default" file header.
Once we go the "use filenames to select" route, we're awfully close to the PRECOMPRESSED_PAYLOAD mess in coreboot-v2 configuration. I'd like to avoid that by keeping all matter related to compression within cbfs.
Patrick
Hi Patrick,
On Tue, Apr 28, 2009 at 01:25:42PM +0200, Patrick Georgi wrote:
Quite simple: There will be a generic header for everything that doesn't require special handling. And that header comes with a compression field, too.
I look at CBFS as a tool for storing named files in flash. I don't see a requirement to handle any files special, and as such I see the concept of special vs normal files as unnecessary complexity. It looks like we view things differently.
As for special handling: Payloads are stored in SELF format, and thus "special" Stages are internal to coreboot. Whatever helps coreboot is fine here. Option ROMs contain the vid/did as fields for faster retrieval.
I view all of the above as files to be stored in flash. Clearly, SELF is a better storage format than elf for coreboot purposes. However, I view a SELF file as just another file to be stored in CBFS. Same thing for Stages and Option ROMs.
Once we go the "use filenames to select" route, we're awfully close to the PRECOMPRESSED_PAYLOAD mess in coreboot-v2 configuration. I'd like to avoid that by keeping all matter related to compression within cbfs.
I can see an advantage of moving compression into CBFS. The cost is having CBFS know when to compress/not compress a given file. I guess I'm not sold on that cost.
-Kevin
-
Kevin O'Connor -
Patrick Georgi