Thanks for the feedback. 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. >
Thanks. I've made a revert <https://review.coreboot.org/c/coreboot/+/66300> for the broadwell patch. In addition to haswell, BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is also enabled for: - CPU_INTEL_MODEL_206AX - CPU_INTEL_MODEL_2065X - NORTHBRIDGE_INTEL_X4X - SOC_INTEL_BAYTRAIL - SOC_INTEL_BRASWELL Do you know offhand whether these platforms support early flash writes or not? If not, who might know the answer? On Mon, Jul 18, 2022 at 5:13 PM Angel Pons <th3fan...@gmail.com> wrote: > 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 | yupin...@google.com | +886 937 057 080 > <+886%20937%20057%20080> > > Best regards, > Angel > -- Yu-Ping Wu | Software Engineer | yupin...@google.com | +886 937 057 080
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
