usually I'm asked to write documentation, but now I'm
the one that actually misses some information. I know
it is common for chromium firmware to have rendundant
FMAP entries for the descriptor regions. But, AFAICS,
this is nowhere documented. Especially the reason for
these entries would be nice to know, as coreboot it-
self doesn't care about them. Oh, and what does the
SI prefix stand for?

Nico, what are you requesting exactly?

A definition of what this validation actually means.
Preferably something in Documentation/ that the help
text of ifdtool can refer to?

I'm not entirely sure, but it sounds like you are assuming coreboot shouldn't care about other regions covered by the descriptor. As system builders we definitely care about managing all regions/assets that comprise the spi flash. That may not be true for all users of coreboot, but it's definitely true for Chrome OS.

Sure. I meant coreboot doesn't care (at runtime). The
build infrastructure does, ofc.

Without such documentation, a validation option can
be confusing. For instance, if I were told to imple-
ment such an option in ifdtool, I would rather check
that all FMAP regions are within the IFD BIOS region,
because I wouldn't expect redundancy.

That's assuming one only cares about the BIOS region. And the check is that things are hierarchical within those regions w/o overlaps. If you care about covering every region then those same checks would apply to other regions covered in the descriptor.

Just wanted to give an example, what people might expect
if they read "validate that the firmware descriptor layout
matches the fmap layout". As the whole thing is not impli-
citly defined by coreboot's semantics, I think it's worth
some documentation.

IMO, it doesn't assume that one only cares about the BIOS
region, btw. There are other ways to discover descriptor
regions beside copying them into fmap.

View Change

To view, visit change 34802. To unsubscribe, or for help writing mail filters, visit settings.