I've nothing against multiboot tables, they were certainly convenient when we added them to Plan 9. I suspect were you to submit a CL you'd find few objections, assuming you made them gated by a config option.
I'm not sure I understand the "bloated FDT" argument. The Go code to read the fdt is 130 lines. It does not seem that bloated to me.
On Wed, Nov 16, 2022 at 10:58 AM bzt bztemail@gmail.com wrote:
Hi,
All true, and I totally agree with points 1 and 2. However
It doesn't seem reasonable to me atm. to expect others to implement such
things.
The keyword here is "at the moment". If the tag is defined as "rom partitions" for example (something more broad and more common, that also fits FMAP), then people at least have the chance to use it in the future. If it's a coreboot-only specific tag, then nobody else will need it for sure, not even theoretically, so it is much more likely that Multiboot2 owners will refuse add such tag to their standard.
I think there's nothing wrong with "Boot log" tag, that's already quite board to be used by others as well. I see no reason why would Multiboot2 owners reject that, sounds pretty reasonable to me.
Anyway, my original intention was to provide an alternative standard to
help with the Universal Payload effort.
And I think this is a great idea, IMHO makes lot more sense than the bloated FDT, but frankly I have absolutely no issues with the current coreboot tables, I like their simplicity.
Cheers, bzt
On 16/11/2022, Nico Huber nico.h@gmx.de wrote:
Hi,
thanks for your replies :)
On 12.11.22 19:43, bzt wrote:
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.
Currently, I see potentially three types of tags/entries:
Those common to all use-cases, i.e. useful for OS and simpler payload loading. Basically what is in Multiboot2 already.
Probably some that are common to payloads / firmware frameworks. These would have to be standardized.
Some that are implementation specific. Looking at cbtables, there are entries for coreboot specific things like FMAP, vboot, ... It doesn't seem reasonable to me atm. to expect others to implement such things.
IMO, if something is missing in the current spec, it's 2. that we have to worry about. I can think of two options right now: 1. Try to get things standardized directly in Multiboot2; 2. standardize it somewhere else (e.g. osfw.foundation), presuming that we could get a tag (or maybe a range?) into Multiboot2 specifically reserved for this.
Anyway, my original intention was to provide an alternative standard to help with the Universal Payload effort. We'll have to see if people want to talk about it, and if they'd miss anything in Multiboot2.
Nico
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org