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.
Does having EFI variable storage in SPI Flash always take priority over
other ESP presence that might have additional variable storage as a file?
Can (or should?) there be a runtime configurable setting to decide two
preferences; does one depend on the other or are these independent?:
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 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).
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
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
