Unable to select a different ENV location due env_get_location on zynqmp

Ricardo Salveti ricardo at foundries.io
Mon Feb 14 21:10:14 CET 2022

Hi Michal,

This is a bit similar to the issue raised on iMX8-based targets a few
days ago, which is forcing the environment location based on the boot
mode and not allowing the user to use a different option via other
CONFIG options.

Should we really force the env location based on boot mode? Currently
there is no way to boot out of QSPI and save the environment on
emmc/fat/ext4, and removing CONFIG_ENV_IS_IN_SPI_FLASH causes the env
location to be set as ENVL_NOWHERE, which is not ideal, especially
when other env target locations are available at build time.

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f0be9c022a7..08afb49570a 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -969,6 +969,10 @@ enum env_location env_get_location(enum
env_operation op, int prio)
        case QSPI_MODE_32BIT:
                        return ENVL_SPI_FLASH;
+               if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
+                       return ENVL_FAT;
+               if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
+                       return ENVL_EXT4;
                return ENVL_NOWHERE;
        case JTAG_MODE:

A change like this one would allow other locations to be set, and just
use the boot mode to assign the priority instead.

Since I couldn't really find out what is the expected behavior on
functions defined at soc/board level (env.c sets based on priority,
depending on what is enabled at build time), I was wondering if we
shouldn't just drop this function entirely.

While I agree the board should have a set of defaults, not allowing
the user to change something like env location via CONFIGs seems wrong
to me.

Let me know what you think.

Ricardo Salveti

More information about the U-Boot mailing list