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:
>
>  1. Those common to all use-cases, i.e. useful for OS and simpler
>     payload loading. Basically what is in Multiboot2 already.
>
>  2. Probably some that are common to payloads / firmware frameworks.
>     These would have to be standardized.
>
>  3. 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