From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web09.87.1638466177297089210 for ; Thu, 02 Dec 2021 09:29:37 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: jeremy.linton@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E0740142F; Thu, 2 Dec 2021 09:29:36 -0800 (PST) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 845D73F73B; Thu, 2 Dec 2021 09:29:36 -0800 (PST) Message-ID: <8e7ef588-f396-7555-45b1-d41a1af93f73@arm.com> Date: Thu, 2 Dec 2021 11:29:28 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables To: Ard Biesheuvel , edk2-devel-groups-io Cc: Peter Batard , Ard Biesheuvel , Leif Lindholm , Andrei Warkentin , Sunny Wang , Samer El-Haj-Mahmoud , =?UTF-8?B?TWFyaW8gQsSDbMSDbmljxIM=?= References: <20211202165206.79615-1-jeremy.linton@arm.com> From: "Jeremy Linton" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/2/21 11:09, Ard Biesheuvel wrote: > On Thu, 2 Dec 2021 at 18:03, Ard Biesheuvel wrote: >> >> On Thu, 2 Dec 2021 at 17:52, Jeremy Linton 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? > Yah, so it looks like 2/9 picked up a couple tab/trailing whitespace cleanups when I ran it through the edk2 checkpatch right before sending it. I can kill those, although, that doesn't really explain why it doesn't apply. Both the copies I got look ok, although the groups.io version changed the content-type from text/plain/7bit to text/plain/quoted-printable, which is disturbing if it decided to quote parts of the patch. 9/9 though seems to be my side, because it got rejected due to UTF-8 whitespace on the last line of the patch not being 7-bit. My mail process on this ML seems to continue to be a pain, and i'm not entirely sure why its special (I post patches elseswhere with a lot less trouble).