Re: [edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 2 Dec 2021 at 18:55, Jeremy Linton <jeremy.linton@arm.com> wrote:
>
> Hi,
>
>
> On 12/2/21 11:09, Ard Biesheuvel wrote:
> > On Thu, 2 Dec 2021 at 18:03, Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Thu, 2 Dec 2021 at 17:52, Jeremy Linton <jeremy.linton@arm.com> wrote:
> >>>
> >>> The RPi4 has a SPI flash with unused capacity. This set detects if
> >>> that capacity is sufficient for a UEFI variable store and utilizes
> >>> it as such. This fixes a long list of problems, and along the way likely
> >>> also fixes a random boot failure caused by the FaultTolerantWriteDxe
> >>> garbage collecting, and erasing the flash volume header which is being
> >>> used to return information about the underlying variable storage capacity.
> >>>
> >>> This set was dependent on an earlier, mostly ignored set of changes to
> >>> move the GPIO/etc devices into their own SSDT and disable them. Because
> >>> of that, the two sets have been merged.
> >>>
> >>> Why is that? Because the SPI flash is mux'ed with the PWM used to play
> >>> audio out the 3.5mm audio jack on this device. This causes a long list
> >>> of problems we must try and avoid, starting with the fact that the pins
> >>> need to be controlled by the uefi runtime service. The other problem is
> >>> obviously that any time a variable is updated, if the user is utilizing
> >>> the 3.5mm audio they will hear clicks and pops. Turns out that behavior
> >>> isn't unique to this patch set because the low level boot/etc exhibits this
> >>> when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
> >>> fixes the majority of this, and the remaining runtime problems caused
> >>> by this patch actually are very slight and generally not noticeable unless
> >>> one goes looking for them. OTOH, we revert to the earlier non persisted
> >>> variable store if the firmware is running in a DT only mode, or the
> >>> user enables the ACPI GPIO block.
> >>>
> >>>
> >>> Jeremy Linton (9):
> >>>    Platform/RaspberryPi: Cleanup menu visibility
> >>>    Platform/RaspberryPi: Give the user control over the XHCI mailbox
> >>>    Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
> >>>    Platform/RaspberryPi: Add menu item to enable/disable GPIO
> >>>    Platform/RaspberryPi: Add constants for controlling SPI
> >>>    Platform/RaspberryPi: Add mailbox cmd to control audio amp
> >>>    Platform/RaspberryPi: Add SPI/GPIO to memory map
> >>>    Platform/RaspberryPi: Allow pin function selection at runtime
> >>>    Platform/RaspberryPi: Add SPI flash variable store.
> >>>
> >>
> >> Very nice!
> >>
> >> I am having trouble applying these patches, though. Could you please
> >> resend without the random whitespace changes?
> >
> > It appears only 2/9 is affected, the remaining ones apply cleanly,
> > with the exception of 9/9, which seems to be missing entirely. Could
> > you please resend that one as well?
> >
>
> Hi,
>
> So, 2/2 was probably me too, I resent it as well with the same subject
> but of course the email thread id isn't right.

Thanks

I gave this a spin, and Boot#### variables created by the Debian
installer persisted as expected, so

Tested-by: Ard Biesheuvel <ardb@kernel.org>

Before I merge this, though, could you elaborate on how playing with
the SPI flash like this is not going to brick my RPi4? Also, others,
please chime in as well.

-- 
Ard.