As someone who implemented a payload, I think there's nothing wrong with coreboot tables. They work pretty great, and they are simple to use.
But if you insist to change that for whatever reason, my vote goes to Multiboot2 too instead of that nightmarish and bloated FDT. Placing handover data in a different structure requires minimal effort, and it won't add complexity to coreboot. It's a pretty straightforward thing (no additional code or ABI, just a little change to represent existing data in a different, more structured format).
However,
From OS point of view, multiboot2 has currently all tables what an OS needs...
I agree, I see no reason for new tags, but if you decide to do so...
ask multiboot2 spec owners to create a special "bootloader specific tag"
Please don't, never ever do that! That kills all the benefits of a standard. Instead decide on a bootloader independent, common tag, and ask he Multiboot2 spec owners to add THAT.
Just for the sake of the argument, let's assume Multiboot2 is missing memory region list (it's not, this is just an example). Then asking for a bootloader specific coreboot_specific_stuff tag and squash the memory table into that binary blob is a VERY BAD idea, goes against everything a standard is created for.
It's much better to ask for a common, loader-independent memory table tag, which coreboot can use for sure, but hopefully can be useful to other Multiboot2 compliant loaders in the future as well. (Again, just an example for the sake of the argument, there's a memory table in Multiboot2.)
Considering we all agree that Multiboot2 already has every tag needed for an OS to boot, I don't think there could be many tags to ask for in the first place. Frankly right now there's nothing I can think of that coreboot provides and payloads need, but can't be described with the existing Multiboot2 tags.
Cheers, bzt
On 12/11/2022, Rudolf Marek r.marek@assembler.cz wrote:
Hi,
On 11. 11. 22 16:19, Nico Huber wrote:
Thoughts are tumbling in my head right now: The whole Multiboot spec thing seems too complex to put into ramstage. But so does the Universal Payload thing! If we'd end up with a shim after ramstage anyway, we could as well use the existing standard.
Well it is not so complex. It has two sets of tags, one set is defined by the program to be loaded (defined in its image), and second which defines stuff similar to what coreboot tables are doing (defined in the memory and passed by certain registers at point of handover).
Multiboot2 has a *big* advantage that it also defines the machine state at the point of handover! Note that multiboot2 tags are forced to begin 8 byte aligned which seems like a plus for ABI.
I think there are some limitations of multiboot2 that some fields are only 32-bits. See the EFI notes in there for further hints. From OS point of view, multiboot2 has currently all tables what an OS needs... The previous multiboot1 lacks ACPI pointer which is a nightmare for an OS to find RSDP... (if it is no longer in legacy places...)
Anyway, what you could probably do, is simply to add a way to directly boot multiboot2 payloads from coreboot. You can leave coreboot tables as is for now and create multiboot2 tables out of coreboot tables. That would be a great step forward I think and you would instantly have a way to boot anything multiboot2 capable!
On the other hand If you want to experiment with extending the multiboot2 here are exercises to a kind reader:
Check the multiboot2 spec and coreboot_tables.h and see what tags are coreboot unique and which needs to be "added".
- Think how to incorporate them or piggyback to the multiboot2
a) ask multiboot2 spec owners to create a special "bootloader specific tag"
+--------------------+u32 | type = 42 | u32 | size | u8[n] | bootloader specific| +--------------------+
You could embedded them in u8[n] either one by one or having it many loader specific tags.
b) for PoC you could probably misuse the bootloader name tag and do following:
3.6.9 Boot loader name
+-------------------+u32 | type = 2 | u32 | size | u8[8] | COREBOOT | u32 | mustbezero | u32 | reserved | u32 | lb_size | u32 | lb_tag | .... +-------------------+
size = ROUNDUP(8 + 8 + 4 + 4 + lb_size, 8)
And you could have multiple boot loader tags, each for extended coreboot tag...
And there you have it...
Thanks, Rudolf
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org