Embed blobs downloading into board configurations (based on t440p work) #1335
Description
t440p board inclusion brought interesting new way of downloading needed blobs prior of building final coreboot step of a board makefile per global Makefile config.
Thanks to @rbreslow, the t440p introduced an old dream of having boards being able to self download its needed blobs directly from board configuration prior of building final coreboot stage which requires those blobs to be in place. Change was introduced because t440p requires an additional coreboot util to be built to be able to extract haswell mrc blob, therefore needing coreboot to be extracted, patched and then that util build for host for the host to be able to use that tool to extract the archive downloaded and extract the needed blob prior of building coreboot to use it.
As of now, xx20 and xx30 blobs are downloaded and extracted in CircleCI prep step, making the blobs cached once to be used by all boards being built after.
This will need a bit more thought prior of refactoring CircleCI config and boards configs to include same concept.
This is good for UX: no more need to do anything, a board will download a place blobs in place.
In CI: this means the blobs will be redownloaded musltiple times if not part of a workspace cache passed along, meaning that:
- x230-hotp-maximized would need to be built first (as of now) to have coreboot buildstack, linux kernel and all modules built once and passed along to xx30 but then
- xx20-hotp-maximized boards should probably be built after x230-hotp-maximized and create a workspace cache to be passed along other xx20
- but doing so would decrease parallelism of CI builds to reduce the number of times Lenovo/mirror (to be defined, archive.org?) will be hit for each board being built.
- xx20-hotp-maximized boards should probably be built after x230-hotp-maximized and create a workspace cache to be passed along other xx20