public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@amd.com>
To: "Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Vincent Stehlé" <vincent.stehle@arm.com>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>
Cc: Shantur Rathore <i@shantur.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jonathan Humphreys <j-humphreys@ti.com>,
	Simon Glass <sjg@chromium.org>,
	Sughosh Ganu <sughosh.ganu@arm.com>,
	Tom Rini <trini@konsulko.com>,
	"Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org>,
	git@amd.com, u-boot@lists.denx.de
Subject: Re: [PATCH v8 4/4] efi_vars: Implement SPI Flash store
Date: Mon, 16 Feb 2026 08:24:19 +0100	[thread overview]
Message-ID: <e5c63fcb-c88b-4550-bf5c-de46a66db0a2@amd.com> (raw)
In-Reply-To: <1508c7be-0700-43ec-adfa-29ea16081b2f@gmx.de>



On 2/15/26 09:48, Heinrich Schuchardt wrote:
> On 2/11/26 16:56, Michal Simek wrote:
>> From: Shantur Rathore <i@shantur.com>
>>
>> Currently U-Boot uses ESP as storage for EFI variables.
>> Devices with SPI Flash are used for storing environment with this
>> commit we allow EFI variables to be stored on SPI Flash.
>>
>> https://github.com/rhboot/efivar
>> is not updated to support this location that's why you can mimic it by
>> running:
>> dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c \
>>     of=/tmp/vars skip=4 bs=1
>> flashcp /tmp/vars /dev/mtdX
>>
>> where mtdX should match location defined by
>> CONFIG_EFI_VARIABLE_SF_OFFSET/CONFIG_EFI_VAR_BUF_SIZE.
>>
>> Signed-off-by: Shantur Rathore <i@shantur.com>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905D3-CC
>> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>>
>> ---
>>
>> Changes in v8:
>> - Add missing EFI_VARIABLE_SF_STORE dependency to EFI_VARIABLE_SF_DEVICE_INDEX
>>
>> Changes in v7:
>> - sed -i 's/efi_var_from/efi_var_from_storage/g'
>>
>> Changes in v6:
>> - sed -i 's/efi_var_read/efi_var_from/g'
>> - sed -i 's/efi_var_write/efi_var_to_storage/g'
>>
>> Changes in v4:
>> - Extend Kconfig description
>> - Extend commit message and describe efivar missing part
>> - use unify methods for reading/writing variable
>>
>> Changes in v3:
>> - Fixed compiler warnings.
>>
>> Changes in v2:
>> - Refactored efi_var_file to move common parts out as requested
>> - Changed ifdefs to use CONFIG_IS_DEFINED
>> - Fixed typos
>>
>>   lib/efi_loader/Kconfig      | 35 +++++++++++++-
>>   lib/efi_loader/Makefile     |  1 +
>>   lib/efi_loader/efi_var_sf.c | 92 +++++++++++++++++++++++++++++++++++++
>>   3 files changed, 127 insertions(+), 1 deletion(-)
>>   create mode 100644 lib/efi_loader/efi_var_sf.c
>>
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index 579eed658801..0f6f927ddaf1 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -124,6 +124,24 @@ config EFI_VARIABLE_FILE_STORE
>>         Select this option if you want non-volatile UEFI variables to be
>>         stored as file /ubootefi.var on the EFI system partition.
>> +config EFI_VARIABLE_SF_STORE
>> +    bool "Store non-volatile UEFI variables in SPI Flash"
>> +    depends on SPI_FLASH
>> +    help
>> +      Select this option if you want non-volatile UEFI variables to be
>> +      stored in SPI Flash.
>> +
>> +      Define CONFIG_EFI_VARIABLE_SF_OFFSET as offset in SPI Flash to use as
>> +      the storage for variables. CONFIG_EFI_VAR_BUF_SIZE defines the space
>> +      needed.
>> +
>> +      Note that SPI Flash devices have a limited number of program/erase
>> +      cycles. Frequent updates to UEFI variables may cause excessive wear
>> +      and can permanently damage the flash device, particularly on SPI NAND
>> +      or low-end SPI NOR parts without wear leveling. This option should be
>> +      used with care on such systems, and is not recommended for platforms
>> +      where UEFI variables are updated frequently.
>> +
>>   config EFI_MM_COMM_TEE
>>       bool "UEFI variables storage service via the trusted world"
>>       depends on OPTEE
>> @@ -153,7 +171,7 @@ endchoice
>>   config EFI_RT_VOLATILE_STORE
>>       bool "Allow variable runtime services in volatile storage (e.g RAM)"
>> -    depends on EFI_VARIABLE_FILE_STORE
>> +    depends on EFI_VARIABLE_FILE_STORE || EFI_VARIABLE_SF_STORE
> 
> Hello Michal,
> 
> If the backend store is SPI flash, we should not publish the variable 
> "RTStorageVolatile" at runtime as currently defined.
> 
> For the background see this commit for the efivar library:
> 
> https://github.com/rhboot/efivar/commit/68daa04654acbe1bbaa17ebfc23c371b39e69c6b
> 
> The first three patches look correct to me and I will add them to a merge 
> request for efi-next.

Do I read it that when I don't allow to select EFI_RT_VOLATILE_STORE you will be 
fine with the patch itself?


> The usage of efi_var_mem_ins() and efi_var_mem_del() when SetVariable() does not 
> change anything is not flash-friendly. Michal, do you want to have a look at 
> this area?

That's known limitation describe in EFI_VARIABLE_SF_STORE Kconfig Note.

Thanks,
Michal


  parent reply	other threads:[~2026-02-16  7:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11 15:56 [PATCH v8 0/4] efi_vars: Implement SPI Flash storage for EFI Michal Simek
2026-02-11 15:56 ` [PATCH v8 1/4] efi_var_file: refactor to move buffer functions Michal Simek
2026-02-12  6:14   ` Ilias Apalodimas
2026-02-11 15:56 ` [PATCH v8 2/4] efi_var: Unify read/write access helper function Michal Simek
2026-02-11 15:56 ` [PATCH v8 3/4] efi_loader: Setup default location for UEFI Variables storing Michal Simek
2026-02-11 20:40   ` Ilias Apalodimas
2026-02-11 15:56 ` [PATCH v8 4/4] efi_vars: Implement SPI Flash store Michal Simek
2026-02-15  8:48   ` Heinrich Schuchardt
2026-02-15 21:55     ` Heinrich Schuchardt
2026-02-16  7:24     ` Michal Simek [this message]
2026-02-16 11:39       ` Heinrich Schuchardt
2026-02-16 11:43         ` Ilias Apalodimas
2026-02-16 12:08         ` Ilias Apalodimas
2026-02-16 13:18           ` Michal Simek
2026-02-16  7:24     ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5c63fcb-c88b-4550-bf5c-de46a66db0a2@amd.com \
    --to=michal.simek@amd.com \
    --cc=git@amd.com \
    --cc=i@shantur.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=j-humphreys@ti.com \
    --cc=neil.armstrong@linaro.org \
    --cc=paul.liu@linaro.org \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@arm.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vincent.stehle@arm.com \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox