[coreboot] Re: RFC: Deprecating VBOOT_VBNV_CMOS

[Yu-Ping Wu via coreboot]

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?

On Mon, Jul 18, 2022 at 5:13 PM Angel Pons  wrote:

> Hi,
>
> On Mon, Jul 18, 2022 at 8:34 AM Yu-Ping Wu via coreboot
>  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

[coreboot] Re: Reconsidering the Gerrit submission strategy

[Patrick Georgi via coreboot]

Hi everybody,


22. Juli 2022 16:56, "Patrick Georgi via coreboot"  
schrieb:

> On August 1, I'll change the coreboot repo to use that submission strategy 
> and then we'll have a
> month to see how it works for us. Late August we can make a decision whether 
> to stay with Rebase
> Always or to go back to Cherry-Pick.

This is now live, let's see how it goes.

(And if it's too horrible, it's trivial to change back at a moment's notice)


Regards,
Patrick
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org