Hello coreboot community,
On the recent coreboot leadership a discussion arose around the patches touching USE_BLOBS option: https://review.coreboot.org/c/coreboot/+/39884 https://review.coreboot.org/c/coreboot/+/37972
A lot of items have been pointed to be solved: 1. A global policy about building blobless images. Currently there is no unified policy how coreboot build system should behave when building with blobs or not. There are numerous mainbaords that require blobs in order to obtain bootable image: FSP, AGESA, MICROCODE, PSP FW. Some of them can be built without blobs with a warning at the end of build process that crucial silicon initialization blobs are missing (example: amd/gardenia), however this behavior is not consistent across whole coreboot tree. There is already very few boards that do not require any blobs in buld process to obtain bootable image. 2. People building coreboot may think that they are building fully open image, but for x86 architecture in particular, it is impossible currently, unless we make some steps to avoid it (which I will describe below). On the second hand, if a new-to-coreboot person build an image that is not bootable, he may be discouraged to use coreboot if his device will be bricked. So a conclusion from the leadrship meeting is to have USE_BLOBS enabled by default (however not selected) in order to keep the usability of the built images.
I encourage to refer to the meeting minutes from coreboot leadership meeting: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...
tl;dr; In the light of above matters I came up with an idea to build coreboot for AMD based boards without blobs by using flashmap. The main goal is to build a coreboot image purely from source code and update only parts of the firmware that contain BIOS code. A mechanism similar to Intel's flash descriptor and bios region, however not present on AMD firmware layout. My idea is intended to be a close equivalent to the Intel's flash descriptor. Example basic layout for AMD firmware could look like this:
FLASH $(CONFIG_ROM_SIZE) { PSPFW(PRESERVE) 0x100000 COREBOOT(CBFS) AGESA(PRESERVE)@$(AGESA_BINARY_PI_LOCATION) 0xa0000 UNUSED BOOTBLOCK 0x10000 }
- PSPFW should contain AMD PSP firmware which lies at fixed offsets of the SPI flash (typically is put at offset of 0x20000 of the beginning of the flash). In order to utilize the FMAP with PSP firmware one can use AMDFW_OUTSIDE_CBFS which will `dd` the whole PSP firmware to the coreboot image at offset 0x20000. The preceding 128KiB (offsets 0x0 - 0x20000) may be either sacrificed as unused or used for other purposes (CONSOLE, SMMSTORE, VPD etc.). According to my knowledge the whole PSP firmware is less than 1MB for family 16h and earlier, however with "dual" PSP directory it may consume more. For family 17h and later it also may be insufficient, but one can always adjust it for families that need it. - AGESA is typically a blob that must be placed at fixed offset defined at blob build time (except open-surce AGESA). AGESA does not have any rebase mechanism as FSP 2.0 and later have, thus a separate FMAP region is added for the blob. Assumed 640K but may be adjusted if needed. The interface to the binary will have to be adjusted to use FMAP to locate it (or a Kconfig option could be used to do switch between FMAP and CBFS). - bootblock is always placed at the bottom of SPI flash (excpet family 17h which can define the reset vector entry point to be elsewhere than 0xFFFFFFF0) so another region has been added for the entire bootblock. Default size for the x86 bootblock is 64K. - UNUSED is a gap between AGESA blob and the bootblock which may be used for other purposes (CONSOLE, SMMSTORE, VPD etc.) - the rest of the space will be occupied by coreboot CBFS
The main advantage is that if one flashes the full image with blobs once, each next update can be built without them. Flashrom with FMAP support would allow to flash only COREBOOT and BOOTBLOCK regions without touching blobs. Of course appropriate warnings should be printed at the end of build process that no blobs have been used and one must ensure these are already present on the SPI flash. This way coreboot can be built purely from source, since microcode is embedded into AGESA binary. Also the situation when blobs have been enabled an waring may be printed, that coreboot used blobs to build the image. These warnings should be consistent for all boards that use blobs (although there may be exceptions, for ARM I guess?).
I assume there will be many questions and I haven't covered everything with my idea, so any suggestions and feedback are welcome.
Regards,