New subject: coreboot master and Lenovo T60 (was: Self-describing CBFS features)

1 Jun 2020


      Hello Coreboot,
I am looking at upgrading a Lenovo T60 that has a 4 year old Libreboot 
installed.  Looking to try git master today, I find myself tracking down 
some details of how the old version was built.  While the included 
.config is invaluable, I'm getting a few ideas for improvements.
-CBFS total size, visible in bootblock.  Some platforms do not have the 
entire flash chip address space decoded after power on reset.  While 
this could be inferred from knowledge of make and model, a reliable and 
generic test would use a marker in the bootblock (and possibly something 
at the start of the flash part can be probed to confirm the mapping), at 
least for platforms where the reset vector it at top of (flash) memory.  
I haven't thought out the details but probably something can be made for 
low address reset vector platforms.  Perhaps a flag in CBFS header to 
indicate which as a clue to cbfstool. Being size aware could also be 
used when swapping a flash chip to a different size.
-the .config is overwritten when added to coreboot.rom via CBFS at the 
end of the build (if you choose that option)... should this be a 
separate file for each of fallback and normal?  Since there can be two 
different versions and/or configurations, would fallback/config and 
normal/config make more sense?  Also the "revision" file might benefit 
from similar treatment.  Need to look into cmos* files also.
-similarly, platforms with a top-swap like Intel, could have 2 different 
bootblock versions, so perhaps a subset of .config relevant to 
bootblock, and a version marker, could go in the same swap-block as each 
bootblock?
-embed the top-swap feature presence, and block size.  I haven't checked 
the code, but the cbfstool -j topswap-size and --ibb features are 
related, if they don't implement this already.  CBFS files should 
optionally not span these block boundaries.
-embed flash chip relative offset, in bootblock (of each top-swap area), 
to be able to probe if top-swap is active at any given moment.
-flash erase block size could be indicated in CBFS header.  This can 
have 2 uses, a)  for alignment and padding when adding files, and b) 
when flashing for a different part, to detect when cbfs should be 
rebuilt with new padding and alignment.  These may not be of use yet, 
but I can envision an enhanced "flashrom -i <layoutfile>" that uses a 
libcbfs to flash individual files, which would benefit knowing the erase 
size the supplied CBFS was build for.
Perhaps each should be discussed in a separate thread, I'll leave that 
to others' discretion.
Regards,
Jeremy

Self-describing CBFS features

Patrick