Hi,
On Mon, Jul 18, 2022 at 8:34 AM Yu-Ping Wu via coreboot coreboot@coreboot.org wrote:
Hi,
There's an ongoing effort to expand vboot nvdata (nvstorage) from 16 to 64 bytes [issue]. To reduce unnecessary complexity of our firmware code accessing nvdata, we'd like to drop 16-byte nvdata support from the firmware codebase (crossystem still needs to support both though).
Sounds good.
One obstacle is the CMOS nvdata backend (VBOOT_VBNV_CMOS). We're not sure if there would be enough CMOS space for all boards using that. In addition, because CMOS loses state when the battery is removed, newer boards usually select VBOOT_VBNV_CMOS_BACKUP_TO_FLASH to backup nvdata to flash. Considering that, this seems like a good opportunity to migrate CMOS to flash nvdata [issue].
The new 64-byte nvdata would require 512 bits of CMOS. On most systems, CMOS has two banks, each of which holds 1024 bits. One could try using the upper bank to store nvdata, but it still has the problem of CMOS losing its contents when RTC battery power is lost. So I'd strongly recommend deprecating support for nvdata in CMOS as well.
One problem we faced is that many old platforms such as broadwell don't support writing to the flash in early stages (BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES). Therefore it looks like we'd need to drop vboot support on them (for example CB:65782). An alternative would be to keep the CMOS backend around as "deprecated" and not allow 64-byte nvdata for it, but that would at best be a transitory solution for a couple of years, not forever.
I'm pretty sure Broadwell supports early flash writes: flashconsole works and it writes to flash as early as bootblock. I'm not sure why CB:45740 selected BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES for platforms older than Skylake/Apollo Lake, but I guess it's because it couldn't be tested.
For Intel platforms with native raminit using MRC cache, I'd suggest selecting MRC_WRITE_NV_LATE when unselecting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES just to be safe. Should native raminit produce training results that are at the limit of instability and ramstage crashes because of it, saving the training results in romstage could potentially result in a boot loop until something is done to invalidate the MRC cache data. Granted, the chances of this ocurring are extremely low, but native raminit isn't perfect (I'm pretty sure MRC isn't perfect either, but we can't really fix the blobs).
If there's any concern, please let me know. We have firmware branches for ChromeOS devices, so modifying ToT code wouldn't affect old devices in any way. However, I'm not sure how non-ChromeOS boards (such as mainboard/lenovo/haswell) would be affected by this. Please cc more people if needed.
There are several Lenovo mainboards which use VBOOT_VBNV_CMOS, but I think it's possible to switch to SPI flash for nvdata on all of them. One thing to keep in mind is that vboot users will have to update everything as these changes won't be backwards-compatible.
--
Yu-Ping Wu | Software Engineer | yupingso@google.com | +886 937 057 080
Best regards, Angel