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