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 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.
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
--
Best regards,
Angel