[coreboot] FSP 2.0 headers in coreboot

[Julius Werner]

> >>      Providers of blobs should sign them and take responsibility
> >>      that the signed blobs were unaltered after compilation (e.g.
> >>      do not contain malware). It is *recommended* that the public
> >>      key needed to verify the signature is obtainable through a
> >>      specific channel (e.g. single responsible contact person)
> >>      _independently_ from the blob's distribution path.

I'm not quite sure what the point of this would be for blobs that are
already checked into 3rdparty/blobs, and I could imagine that it would be a
surprisingly big obstacle for a lot of vendors. Please don't only think of
Intel when trying to make these rules... not every vendor has the resources
to set up their own blob distribution site with regular versioned releases
on GitHub. On Arm systems the blob may often be designed specifically for
coreboot, and the vendor loses interest as soon as the project they were
paid to support (e.g. a Chromebook) is finished. I think this should still
be fine as long as they uploaded it with a proper redistribution license to
blobs.git, and implemented the coreboot interface with enough documentation
to make it usable afterwards. For vendors like Intel that insist on hosting
their blobs externally, I think it's fair to impose more rules to avoid the
problems you've described, but we should still leave open an easier option
for vendors that are willing to redistribute their blobs through
coreboot.org (which I think is the much nicer option for us, so we should
incentivize it).

> >>      For each platform that relies on a blob, the coreboot tree
> >>      *should* point (e.g. git submodule) to a commit containing
> >>      both the header files and the matching binary.

It seems like you want to move headers from the coreboot into the blobs
directory? I don't really see the point in that either. Headers are source,
they need to be covered under the GPL... it's easier to make that clear
when they are in coreboot. I agree with your point that headers and blobs
should always be updated together, but we can still enforce that across two
repositories.

> >>      Unless a pointer as described above exists for a given plat-
> >>      form that relies on a blob, all changes* to that platform
> >>      *shall* be refused.

I think this is counter-productive, as is removing any old boards that
don't comply. I am okay with creating new rules for future platforms, but
there is no reason to throw perfectly good and working boards out just
because they weren't written to comply with something we only just made up.
You wouldn't really be punishing anyone with that (vendors don't care about
outdated chips anyway), you'd just be taking choice away from our users.

We should continue removing old boards when they become too much of a
maintenance burden, which may happen due to an unmaintainable blob mess,
but we shouldn't categorically remove anything with blobs.

> OTOH, what's the benefit of maintaining them in the master branch if
> nobody else can do a port with the platform code?

I think allowing users to build their own custom firmware for an already
supported board is definitely reason enough to keep it in the master
branch. coreboot is not just a project for allowing companies large and
small to build new mainboards... it's also for private enthusiasts that
want to tinker with firmware for a supported board they bought somewhere.
Of course it would be nice if every chipset was implemented well enough
that you can bring up a new mainboard without any help from the vendor, but
that's not always that simple, and I don't think it should be a requirement
for inclusion.