Accidentally responded off the mailing list initally. :-/
Oct 20, 2021, 08:07 by matt.devillier@gmail.com:
On Wed, Oct 20, 2021 at 8:53 AM Andy Pont andy.pont@sdcsystems.com wrote:
Nico wrote...
How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows:
...
We already have a list of things required to go in with binaries checked into the blobs repo. I personally don't have any objection with updating the document if more things are needed.
https://review.coreboot.org/plugins/gitiles/blobs/+/refs/heads/master/README...
We could also add a jenkins build that helps to verify that these are met - at least check that any commit of a binary updates the release notes. Maybe use a machine-parsable template similar to board_info in the coreboot mainboards directory. This could contain all of the information required.
Taking EC firmware as an example, in many situations the short answer is “it resides in the same binary image as coreboot and is a blob because that is all there is”. Based on your list of questions I’m not convinced that would be sufficient to get it merged.
Why would we be adding EC blobs to the coreboot repo?
I'm assuming we're talking about the coreboot blobs repo, not the actual coreboot repo.
The EC firmware sometimes runs out of the boot rom, so the final firmware must also contain the EC image. I realize that it's a point of contention in the coreboot community whether the coreboot build process should produce a complete binary. Some feel that it's more appropriate for users to add any external bits outside of the coreboot build. If we're going to allow binaries into the coreboot build process though, I don't see a reason to exclude EC binaries.
If any EC images were added, they'd need to be licensed as being redistributable before they could be added. They can't just be pulled out of someone else's image and hosted in the coreboot blobs repo.