> > These platforms should also support early writes, but it would be nice to > test them. I'd suggest making one change for each platform, so that it's > easier to keep track of the test status for each. I'll try to add reviewers > to the changes who may be able to test them.
That would be great. Thanks. +chromeos-coreboot <chromeos-coreb...@google.com> to be aware of the plan. On Sun, Aug 14, 2022 at 6:06 PM Angel Pons <th3fan...@gmail.com> wrote: > Hi, > > On Mon, Aug 1, 2022 at 2:59 AM Yu-Ping Wu <yupin...@google.com> wrote: > >> 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? >> > > These platforms should also support early writes, but it would be nice to > test them. I'd suggest making one change for each platform, so that it's > easier to keep track of the test status for each. I'll try to add reviewers > to the changes who may be able to test them. > > >> 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 <+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
