Hi,
There's an ongoing effort to expand vboot nvdata (nvstorage) from 16 to 64 bytes [issue https://issuetracker.google.com/issues/172342278]. 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).
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 https://issuetracker.google.com/issues/235293589].
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 https://review.coreboot.org/c/coreboot/+/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.
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.
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
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 th3fanbus@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 | yupingso@google.com | +886 937 057 080
<+886%20937%20057%20080>
Best regards, Angel
Hi,
On Mon, Aug 1, 2022 at 2:59 AM Yu-Ping Wu yupingso@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 th3fanbus@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 | yupingso@google.com | +886 937 057 080
<+886%20937%20057%20080>
Best regards, Angel
--
Yu-Ping Wu | Software Engineer | yupingso@google.com | +886 937 057 080
Best regards, Angel
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-coreboot@google.com to be aware of the plan.
On Sun, Aug 14, 2022 at 6:06 PM Angel Pons th3fanbus@gmail.com wrote:
Hi,
On Mon, Aug 1, 2022 at 2:59 AM Yu-Ping Wu yupingso@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 th3fanbus@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 | yupingso@google.com | +886 937 057
080 <+886%20937%20057%20080>
Best regards, Angel
--
Yu-Ping Wu | Software Engineer | yupingso@google.com | +886 937 057 080 <+886%20937%20057%20080>
Best regards, Angel
-
Angel Pons -
Yu-Ping Wu