aboutsummaryrefslogtreecommitdiff
path: root/env
AgeCommit message (Collapse)AuthorFilesLines
2021-09-25treewide: fdt: Move fdt_get_config_... to ofnode_conf_read...Simon Glass1-2/+3
The current API is outdated as it requires a devicetree pointer. Move these functions to use the ofnode API and update this globally. Add some tests while we are here. Correct the call in exynos_dsim_config_parse_dt() which is obviously wrong. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-24Revert "env: Make _init() expect _INVALID when _IS_NOWHERE"Tom Rini1-1/+1
Upon further discussion, this is not required now. This reverts commit f6bc5d17afa9fe12418edaf1fc9f82beeda06132. Link: https://lore.kernel.org/r/ebd92337-669a-9a0a-0af3-d06b957f3b40@denx.de/ Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-23env: Make _init() expect _INVALID when _IS_NOWHEREPierre-Clément Tosi1-1/+1
Avoid applying the "fix" introduced by commit 5557eec01cbf ("env: Fix invalid env handling in env_init()") to the environment "nowhere". This is necessary as that commit, by setting the return value of env_init() to -ENOENT if gd->env_valid is ENV_INVALID, forces that function to reset gd->env_valid to ENV_VALID. By doing so, it breaks the assumption (required by ENV_IS_NOWHERE) that gd->env_valid must be ENV_INVALID. This, in turn, results in env_relocate() calling env_load() (it should not), which itself, calls U_BOOT_ENV_LOCATION(nowhere).load() i.e. env_nowhere_load(). That function, being implemented under the assumption mentioned above, calls env_set_default(), which in turn, seeing that gd->env_valid is ENV_VALID (it should not), tries to dereference whatever lies in gd->env_addr (most likely garbage), leading to a faulty memory access. Note that other env_locations might be concerned by this bug but that this commit only intends to fix it for when ENV_IS_NOWHERE. Fixes: 5557eec01cbf ("env: Fix invalid env handling in env_init()") Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
2021-08-31Kconfig: Remove all default n/no optionsMichal Simek1-3/+0
default n/no doesn't need to be specified. It is default option anyway. Signed-off-by: Michal Simek <michal.simek@xilinx.com> [trini: Rework FSP_USE_UPD portion] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-30Convert CONFIG_SYS_I2C_EEPROM_ADDR et al to KconfigTom Rini1-9/+9
- Rename usages of CONFIG_SYS_DEF_EEPROM_ADDR to CONFIG_SYS_I2C_EEPROM_ADDR based on current usage. - Convert CONFIG_SYS_I2C_EEPROM_ADDR, CONFIG_SYS_I2C_EEPROM_ADDR_LEN, CONFIG_SYS_I2C_EEPROM_BUS, CONFIG_CONFIG_SYS_EEPROM_SIZE CONFIG_SYS_EEPROM_PAGE_WRITE_BITS and CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS to Kconfig. We move these symbols around a bit and add appropriate dependencies to them. In some cases, we now add a correct default value as well. Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-30eeprom: Drop CONFIG_ENV_EEPROM_IS_ON_I2C usageTom Rini1-4/+0
At this point in time, there's no systems with "U-Boot environment exists on an EEPROM which is accessed over the I2C bus" that sets this option. Drop it. Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-18env: Kconfig: Add default option for PHY_CORTINAKuldeep Singh1-1/+1
Add PHY_CORTINA as default option in SYS_MMC_ENV_DEV Kconfig entry as PHY_CORTINA require SYS_MMC_ENV_DEV value similar to FMAN_ENET or QE. This helps in resolving compilation failure. Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-08-01sunxi: Select environment MMC based on boot deviceSamuel Holland1-2/+1
Currently, the environment is always stored in eMMC if eMMC is enabled in the config. This means images written to SD and eMMC will cross- contaminate their environments unless the configuration is changed. By dropping the device number from the environment location string and implementing mmc_get_env_dev, we will always use the environment from the boot device when booting from SD/eMMC. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-07-07ppc: Remove sbc8641d boardTom Rini1-1/+1
This board has not been converted to CONFIG_DM_PCI by the deadline and is also missing conversion to CONFIG_DM. Remove it. This is also the last of the ARCH_MPC8641/MPC8610 platforms, so remove that support as well. Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Priyanka Jain <priyanka.jain@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-07-07ppc: Remove xpedite boardsTom Rini1-1/+1
These boards have not been converted to CONFIG_DM_PCI by the deadline and is also missing conversion to CONFIG_DM. Remove them. As this includes the last ARCH_MPC8572 platform, remove that as well. Cc: Peter Tyser <ptyser@xes-inc.com> Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Peter Tyser <ptyser@xes-inc.com>
2021-07-07m68k: Remove M5475x boardsTom Rini1-1/+1
These board has not been converted to CONFIG_DM_PCI by the deadline. Remove them. As this is the last of the mcf547x_8x family of boards, remove that support as well. Cc: TsiChung Liew <Tsi-Chung.Liew@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-05-04env: allow environment to be amended from control dtbRasmus Villemoes2-0/+48
It can be useful to use the same U-Boot binary for multiple purposes, say the normal one, one for developers that allow breaking into the U-Boot shell, and one for use during bootstrapping which runs a special-purpose bootcmd. Or one can have several board variants that can share almost all boot logic, but just needs a few tweaks in the variables used by the boot script. To that end, allow the control dtb to contain a /config/enviroment node (or whatever one puts in fdt_env_path variable), whose property/value pairs are used to update the run-time environment after it has been loaded from its persistent location. The indirection via fdt_env_path is for maximum flexibility - for example, should the user wish (or board logic dictate) that the values in the DTB should no longer be applied, one simply needs to delete the fdt_env_path variable; that can even be done automatically by including a fdt_env_path = ""; property in the DTB node. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2021-04-23xilinx: versal: Add support for saving env based on bootmodeAshok Reddy Soma1-1/+1
Enable saving variables to MMC(FAT) and SPI based on primary bootmode. If bootmode is JTAG, dont save env anywhere(NOWHERE). Enable ENV_FAT_DEVICE_AND_PART="0:auto" for Versal platforms as well. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-04-23env: Setup default value for ENV_OFFSET_REDUNDMichal Simek1-0/+1
This variable is used for pointing to location where redundant variables are located. There is no default value. And it doesn't need to be specified which is showing as warning when savedefconfig is called. make xilinx_zynqmp_virt_defconfig # # configuration written to .config # make savedefconfig scripts/kconfig/conf --savedefconfig=defconfig Kconfig .config:199:warning: symbol value '' invalid for ENV_OFFSET_REDUND Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-04-16env: sf: remove the static env_flash variablePatrick Delaunay1-23/+18
As the the SPI flash is probed and is released in each ENV sf function the env_flash no more need to be static. This patch move this device handle as local variable of each function and simplify the associated code (env_flash is never == NULL when setup_flash_device is called). Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-16env: sf: add missing spi_flash_freePatrick Delaunay1-0/+9
Free the SPI resources by calling spi_flash_free() in each env sf function to avoid issue for other SPI users. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-16env: sf: add support of command env erasePatrick Delaunay1-0/+34
Add support of opts erase for env in SPI flash; this opts is used by command 'env erase'. This command only fills the env offset by 0x0 (bit flip to 0) and the saved environment becomes invalid (with bad CRC). It doesn't erase the sector here to avoid issue when the sector is larger than the env (i.e. embedded when CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE). The needed sector erase will be managed in the next "env save" command, using the opt ".save", before to update the environment in SPI flash. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-16env: sf: update the use of macro ENV_SAVE_PTRPatrick Delaunay1-1/+1
Remove CONFIG_IS_ENABLED(SAVEENV) as it is already tested in the ENV_SAVE_PTR macro. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-16env: add ENV_ERASE_PTR macroPatrick Delaunay2-7/+2
Add ENV_ERASE_PTR macro to handle erase opts and remove the associated ifdef. This patch is a extension of previous commit 82b2f4135719 ("env_internal.h: add alternative ENV_SAVE_PTR macro"). Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-04-16env: Fix invalid env handling in env_init()Marek Vasut1-0/+3
This fixes the case where there are multiple environment drivers, one of them is the default environment one, and it is followed by an environment driver which does not implement .init() callback. The default environment driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init() callback implementation, which is valid behavior for default environment. Since the subsequent environment driver does not implement .init(), it also does not modify the $ret variable in the loop. Therefore, the loop is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the code further down in env_init() will not reset the environment to the default one, which is incorrect. This patch sets the $ret variable back to -ENOENT in case the env_valid is set to ENV_INVALID by an environment driver, so that the environment would be correctly reset back to default one, unless a subsequent driver loads a valid environment. Signed-off-by: Marek Vasut <marex@denx.de> Tested-By: Tim Harvey <tharvey@gateworks.com>
2021-04-16env/fat.c: support redund environmentBrandon Maier2-8/+40
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com> CC: Joe Hershberger <joe.hershberger@ni.com> CC: Wolfgang Denk <wd@denx.de>
2021-04-16env: Fix warning when forcing environment without ENV_ACCESS_IGNORE_FORCEMartin Fuzzey1-2/+3
Since commit 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") a warning message is displayed when setenv -f is used WITHOUT CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting in lots of log pollution. env_flags_validate() returns 0 if the access is accepted, or non zero if it is refused. So the original code #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE if (flag & H_FORCE) return 0; #endif was correct, it returns 0 (accepts the modification) if forced UNLESS IGNORE_FORCE is set (in which case access checks in the following code are applied). The broken patch just added a printf to the force accepted case. To obtain the intent of the patch we need this: if (flag & H_FORCE) { #ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE printf("## Error: Can't force access to \"%s\"\n", name); #else return 0; #endif } Fixes: 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
2021-04-16env: increment redund flag on read failBrandon Maier2-20/+9
If one of the reads fails when importing redundant environments (a single read failure), the env_flags wouldn't get initialized in env_import_redund(). If a user then calls saveenv, the new environment will have the wrong flags value. So on the next load the new environment will be ignored. While debugging this, I also noticed that env/sf.c was not correctly handling a single read failure, as it would not check the crc before assigning it to gd->env_addr. Having a special error path for when there is a single read failure seems unnecessary and may lead to future bugs. Instead collapse the 'single read failure' error to be the same as a 'single crc failure'. That way env_check_redund() either passes or fails, and if it passes we are guaranteed to have checked the CRC. Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com> CC: Joe Hershberger <joe.hershberger@ni.com> CC: Wolfgang Denk <wd@denx.de> CC: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2021-04-16env: add CONFIG_ENV_SECT_SIZE_AUTORasmus Villemoes2-2/+22
This is roughly the U-Boot side equivalent to commit e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The motivation is the case where one has a board with several revisions, where the SPI flashes have different erase sizes. In our case, we have an 8K environment, and the flashes have erase sizes of 4K (newer boards) and 64K (older boards). Currently, we must set CONFIG_ENV_SECT_SIZE to 64K to make the code work on the older boards, but for the newer ones, that ends up wasting quite a bit of time reading/erasing/restoring the last 56K. At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean "use the erase size the chip reports", but that config option is used in a number of preprocessor conditionals, and shared between ENV_IS_IN_FLASH and ENV_IS_IN_SPI_FLASH. So instead, introduce a new boolean config option, which for now can only be used with ENV_IS_IN_SPI_FLASH. If left off, there's no change in behaviour. The only slightly annoying detail is that, when selected, the compiler is apparently not smart enough to see that the the saved_size and saved_offset variables are only used under the same "if (sect_size > CONFIG_ENV_SIZE)" condition as where they are computed, so we need to initialize them to 0 to avoid "may be used uninitialized" warnings. On our newer boards with the 4K erase size, saving the environment now takes 0.080 seconds instead of 0.53 seconds, which directly translates to that much faster boot time since our logic always causes the environment to be written during boot. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-04-16env/sf.c: use a variable to hold the sector sizeRasmus Villemoes1-10/+12
As preparation for the next patch, use a local variable to represent the sector size. No functional change. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
2021-02-02common: Drop asm/global_data.h from common headerSimon Glass14-0/+14
Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-01-29env: sf: cosmetic: remove unnecessary spacePatrick Delaunay1-2/+2
Remove the unnecessary space before the 2 "done:" labels in env_sf_save(). Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2021-01-20env: Remove all dependencies for SYS_REDUNDAND_ENVIRONMENTMichal Simek1-2/+3
CONFIG_SYS_REDUNDAND_ENVIRONMENT is changing in env_internal.h how u-boot works with variables. struct environment_s has one byte flags property which also affects ENV_SIZE macro. I have reached the case where CONFIG_ENV_IS_NOWHERE is default setup but custom scripts can be designed in a way that u-boot is asked to import/export variables from/to file which can be in certain format. That's why also for this configuration make sense to enable CONFIG_SYS_REDUNDAND_ENVIRONMENT because it depends on environment file format. The patch is removing dependency on this configuration to support selecting environment file format without any specific dependency where variables are stored. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-11-19env: typo enougthHeinrich Schuchardt1-1/+1
%s/enougth/enough/ Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2020-11-18env: mmc: Correct partition comparison in mmc_offset_try_partitionHoyeonjiki Kim1-1/+1
The function mmc_offset_try_partition searches the MMC partition for locating environment data, by comparing the partition names with config "u-boot,mmc-env-parition". However, it only compares the first word-size bytes (size of 'const char *'), which may make the function to find unintended partition. Correct the function not to partially compare the partition name with config "u-boot,mmc-env-partition". Fixes: c9e87ba66540 ("env: Save environment at the end of an MMC partition") Signed-off-by: Hoyeonjiki Kim <jigi.kim@gmail.com> Reviewed-by: Wolfgang Denk <wd@denx.de>
2020-11-03env: sf: fix init function behaviourHeiko Schocher2-3/+7
Michael wrote: commit 92765f45bb95 ("env: Access Environment in SPI flashes before relocation") at least breaks the Kontron sl28 board. I guess it also breaks others which use a (late) SPI environment. reason is, that env_init() sets the init bit, if there is no init function defined in an environment driver, and use default return value -ENOENT in this case later for setting the default environment. Change: Environment driver can now implement an init function and return, if this function does nothing, simply -ENOENT. env_init() now handles -ENOENT correct by setting the inited bit for the environment driver. And if there is no other environment driver whose init function returns 0, load than the default environment. This prevents that each environment driver needs to set the default environment. Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation") Reported-by: Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> [For the SF environment] Signed-off-by: Heiko Schocher <hs@denx.de>
2020-10-30env: Access Environment in SPI flashes before relocationHeiko Schocher2-3/+105
Enable the new Kconfig option ENV_SPI_EARLY if you want to use Environment in SPI flash before relocation. Call env_init() and than you can use env_get_f() for accessing Environment variables. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-30env: split env_import_redund() into 2 functionsHeiko Schocher1-10/+32
split from env_import_redund() the part which checks which Environment is valid into a separate function called env_check_redund() and call it from env_import_redund(). So env_check_redund() can be used from places which also need to do this checks. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-14env/ext4.c: allow loading from an EXT4 partition on the MMC boot deviceDavid Woodhouse2-0/+18
This parallels what I added for FAT in commit 6731bef6966, allowing the environment to be found in a specific partition on the device that the board's mmc_get_env_dev() returns. On the Banana Pi R2 that means the device that U-Boot was loaded from; either the internal eMMC or an SD card. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2020-10-14mmc: remove duplicate mmc_get_env_dev() implementationsDavid Woodhouse2-14/+0
Since it's so trivial I could just about tolerate this when there were only two copies of it. But now there are about to be three. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2020-10-09Kconfig: Move VERSION_VARIABLE under environmentSimon Glass1-0/+9
This relates to the environment so should not be at the top level. Move it. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-23env: kconfig: Add default option for ARCH_ZYNQMichal Simek1-1/+1
Zynq is similar to ZynqMP u-boot feature wise that's why also enable default option for ENV_FAT_DEVICE_AND_PART Kconfig entry. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-08-27env: Kconfig: Add missing dependency for ENV_IS_IN_EXT4Michal Simek1-0/+1
ENV_IS_IN_EXT4 also need to enable FS_EXT4 which is not covered in Kconfig. Kconfig reports this as: WARNING: unmet direct dependencies detected for EXT4_WRITE Depends on [n]: FS_EXT4 [=n] Selected by [y]: - ENV_IS_IN_EXT4 [=y] && !CHAIN_OF_TRUST [=n] Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-08-08Convert CONFIG_SYS_MMC_ENV_DEV et al to KconfigTom Rini2-4/+19
This converts the following to Kconfig: CONFIG_SYS_MMC_ENV_DEV CONFIG_SYS_MMC_ENV_PART Note that with this conversion we now have consistent behavior with respect to ensuring that we have always selected the correct MMC device and hardware partition. Signed-off-by: Tom Rini <trini@konsulko.com>
2020-07-31env: Add support for explicit write access listMarek Vasut2-11/+59
This option marks any U-Boot variable which does not have explicit 'w' writeable flag set as read-only. This way the environment can be locked down and only variables explicitly configured to be writeable can ever be changed by either 'env import', 'env set' or loading user environment from environment storage. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-31env: Add option to only ever append environmentMarek Vasut2-0/+11
Add configuration option which prevents the environment hash table to be ever cleared and reloaded with different content. This is useful in case the first environment loaded into the hash table contains e.g. sensitive content which must not be dropped or reloaded. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-31env: Discern environment coming from external storageMarek Vasut13-22/+23
Add another custom environment flag which discerns environment coming from external storage from environment set by U-Boot itself. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-31env: Add H_DEFAULT flagMarek Vasut1-1/+2
Add another internal environment flag which indicates that the operation is resetting the environment to the default one. This allows the env code to discern between import of external environment and reset to default. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-31env: Warn on force access if ENV_ACCESS_IGNORE_FORCE setMarek Vasut1-1/+3
If the ENV_ACCESS_IGNORE_FORCE is set, inform user that the variable cannot be force-set if such attempt happens. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-07-31env: ext4: add support of command env erasePatrick Delaunay1-0/+19
Add support of opts erase for env in ext4, this opts is used by command 'env erase'. This command only fill the env file (CONFIG_ENV_EXT4_FILE) with 0, the CRC and the saved environment becomes invalid. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-31env: ext4: introduce new function env_ext4_save_bufferPatrick Delaunay1-8/+20
Split the function env_ext4_save to prepare the erase support. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-31cmd: env: add env select commandPatrick Delaunay1-0/+42
Add the new command 'env select' to force the persistent storage of environment, saved in gd->env_load_prio. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-31cmd: env: add env load commandPatrick Delaunay1-0/+28
Add the new command env load to load the environment from the current location gd->env_load_prio. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-31env: the ops driver load becomes mandatory in struct env_driverPatrick Delaunay1-3/+0
The ops driver load becomes mandatory in struct env_drive, change the comment for this ops and remove unnecessary test. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-31env: nowhere: add .load opsPatrick Delaunay1-0/+17
Add the ops .load for nowhere ENV backend to load the default environment. This ops is needed for the command 'env load' Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
generated by cgit v1.1 at 2024-11-25 21:24:30 +0000