Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/42029 )
Change subject: drivers/vpd: Add a function that reads BIOS version from a VPD variable ......................................................................
Patch Set 6:
Resolve some comments, if it's better to move the function and Kconfig to x86/smbios.c will do.
Yes, sorry if that wasn't clear, but I think our consensus is that CB:32905 is the better approach.
IMHO a more correct implementation is:
If you use FMAP, define a version section explicitly, and fill the section in your build procedure where you can still access CONFIG_LOCAL_VERSION.
If FMAP is not an option, create a file like 'coreboot_version' and put that into CBFS may be easier, so you can still extract and read using cbfstool.
After reading your explanation on VPD, I strongly agree with your proposal #2: CBFS sounds like the right place where this information should go. Another reason to use VPD was that these variables are easily accessible via Linux's /sys/firmware/vpd , so no vpd tool is necessary. I was wondering if we should have a similar driver for Linux to access CBFS read-only, or if this is a bad idea.
Well, no, I think if you *do* want to update the version number after the firmware image is finalized, putting it in VPD is probably the right thing after all. I guess this is a bit up to personal interpretation but I would consider the CBFS as the actual firmware (because all the stage binaries with the actual code are in there, and they're all mixed in together with other CBFS files) and the VPD as auxiliary data that can be modified independently. On Chrome OS, we use a hash of the whole CBFS to verify that our firmware code was unmodified, while the VPD can be written afterwards to adjust values that need to be different for each individual unit (e.g. serial number).
I still think it would be easier to just set the version number at build time instead. If you want to test different release candidates, why don't you just compile all your release candidates with the version number that your next official release is supposed to have, test them until you find one you're happy with, and then release that while throwing the others away? (While you're testing them you can still tell them apart by the other values in the 'revision' file in CBFS, e.g. Git SHA or build time.)
The /sys/firmware/vpd interface works by copying the whole VPD into memory and passing that to the kernel. Since CBFS is a lot bigger (and contains mostly stuff not interesting to the OS, like stage binaries), I don't think a similar interface makes sense for it. I think flashrom+cbfstool are the appropriate way to access it.