Patch Set 4:

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.

Yes, coreboot doesn't proper. But many other components can and do.

> > 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.

Your request makes sense.

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.

That's true. We're in the position of needing to manage a heterogeneous fleet of systems, and the tooling being consistent is helpful there. That's where our Chrome OS reliance on FMAP is helpful as opposed to querying registers at runtime, e.g.. I hope that provides more context (if that was the request aside from adding documentation).

View Change

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