On Wed, 14 Jan 2026 at 18:35, E Shattow <[email protected]> wrote:
>
> Hi Michal I have some user-facing questions about this concept.
>
> On 1/14/26 07:15, Michal Simek wrote:
> >
> > This is updated series based on v3 version sent here
> > https://lore.kernel.org/all/[email protected]/
> >
> > that's why I am continuing on v4 instead of starting from scratch.
> >
> > Tested on kv260 with saving variables to location where User MTD partition
> > is.
> > CONFIG_EFI_VARIABLE_SF_STORE=y
> > CONFIG_EFI_RT_VOLATILE_STORE=y
> > CONFIG_EFI_VARIABLE_SF_OFFSET=0x22a0000
> >
> > Thanks,
> > Michal
> >
> > Changes in v4:
> > - New patch based on review comments from v3
> > - 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
> >
> > Michal Simek (1):
> > efi_var: Unify read/write access helper function
> >
> > Shantur Rathore (2):
> > efi_var_file: refactor to move buffer functions
> > efi_vars: Implement SPI Flash store
> >
> > include/efi_variable.h | 18 +++----
> > lib/efi_loader/Kconfig | 26 +++++++++-
> > lib/efi_loader/Makefile | 3 +-
> > lib/efi_loader/efi_var_common.c | 44 ++++++++++++++++
> > lib/efi_loader/efi_var_file.c | 65 ++---------------------
> > lib/efi_loader/efi_var_sf.c | 91 +++++++++++++++++++++++++++++++++
> > lib/efi_loader/efi_variable.c | 16 ++++--
> > 7 files changed, 187 insertions(+), 76 deletions(-)
> > create mode 100644 lib/efi_loader/efi_var_sf.c
> >
>
> So far as I'm aware support for EFI variable storage is always integral
> to a filesystem as the EFI System Partition, even in the case of the
> specially-handled MMC boot partition facility. With presence of many
> possible ESP is there then only one active ESP, or do all ESP become
> part of a pool of available locations? I'm not understanding this
> clearly what is the purpose of selecting an ESP if the variable storage
> is not integral to the ESP.
EFI variables have nothing to do with ESP filesystems. Most
implementations of EFI variables don't use ESP partitions to write
variables, U-Boot did that basically as a work around. If you look at
the average UEFI implementation on a Intel device the EFI vars are
written to the flash storage where they can be signed and validated to
ensure they're not changed without the firmware knowing.
> Does having EFI variable storage in SPI Flash always take priority over
> other ESP presence that might have additional variable storage as a file?
That would presumably depend on the U-Boot build options.
> Can (or should?) there be a runtime configurable setting to decide two
> preferences; does one depend on the other or are these independent?:
No. It would be a device decision.
> 1. Preferred ESP
> 2. Preferred EFI variable storage strategy
>
> Consider not wanting to have a perceived ABI breakage as the SPI Flash
> layout is previously codified by user expectations of what the vendor
> initially shipped with the product and having been codified in upstream
> Linux kernel devicetree definition. For the example where this would be
> useful for boards where there is a well-known SPI Flash layout, I am
> thinking of StarFive VisionFive 2 where there is {U-Boot SPL, U-Boot env
> storage, U-Boot Main at 1MiB offset}; does your implementation of EFI
> variable storage in SPI Flash have a suggested co-existence with the
> "gap" in the area that is currently U-Boot env storage?
The board maintainer would decide that, or the vendor, or if the user
wants to building their own.
> The use situations I am thinking of:
>
> A. Installing a new OS or booting purpose-built image, where it is
> intended that having (for example) a USB mass storage class or SD Card
> of the all-in-one image depends on U-Boot in SPI Flash deciding both
> that the EFI System Partition on the removable media is a priority over
> other similar media (other different USB boot devices that may be
> present, existing eMMC storage module possibly with ESP in addition to
> the inserted removable SD Card).
Well by storing the EFI vars on the SPI flash the user can erase one
of the storage options without necessarily impacting the EFI vars
without knowing.
The storage of EFI vars on the flash of the firmware is what you get
on x86 devices.
> B. Preventing the ambiguous selection of any additional removable
> storage containing an EFI System Partition from breaking the desired
> boot strategy. In many situations a user wants assurance that the board
> will boot exactly the same every time regardless of what additional
> removable media containing EFI System Partition might be connected.
>
> C. Corrupt or unusable selected EFI System Partition prevents any
> recovery and there is no runtime mechanism to attempt an alternative
No it doesn't there's EFI fall back options or you could erase the
vars from the u-boot cmd line etc.
> Is there a possible mechanism for adding a runtime check (GPIO state,
> key press, network event) to make the decision between some immutable
> boot preference, or a user-configured boot preference?
>
> Overall I want to get an understanding of how it might be recommended to
> make use of this for StarFive VisionFive 2 board target(s). Many hours
> of troubleshooting headache have been the result of EFI System Partition
> confusion on board that have a wide variety of storage subsystems (MMC,
> USB, NVMe, ...) which result in some really strange outcomes with
> installers of GNU/Linux OS distros; particularly as the devicetree dtb
> search path currently points to storage subsystems that are typically
> removable media, or the failure mode where an OS installer is using the
> selected EFI System Partition that "leads on a path to nowhere" and is
> not the intended installation target.
>
> -E
