aboutsummaryrefslogtreecommitdiff
path: root/env
AgeCommit message (Collapse)AuthorFilesLines
2021-11-16bootm: Tidy up use of autostart env varWIP/2021-11-16-env-reworkSimon Glass1-0/+5
This has different semantics in different places. Go with the bootm method and put it in a common function so that the behaviour is consistent in U-Boot. Update the docs. To be clear, this changes the way that 'bootelf' and standalone boot work. Before, if autostart was set to "fred" or "YES", for example, they would consider that a "yes". This may change behaviour for some boards, but the only in-tree boards which mention autostart use "no" to disable it, which will still work. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Wolfgang Denk <wd@denx.de>
2021-11-16env: Allow U-Boot scripts to be placed in a .env fileSimon Glass2-0/+19
At present U-Boot environment variables, and thus scripts, are defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text to this file and dealing with quoting and newlines is harder than it should be. It would be better if we could just type the script into a text file and have it included by U-Boot. Add a feature that brings in a .env file associated with the board config, if present. To use it, create a file in a board/<vendor> directory, typically called <board>.env and controlled by the CONFIG_ENV_SOURCE_FILE option. The environment variables should be of the form "var=value". Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. In many cases environment variables need access to the U-Boot CONFIG variables to select different options. Enable this so that the environment scripts can be as useful as the ones currently in the board config files. This uses the C preprocessor, means that comments can be included in the environment using /* ... */ Also support += to allow variables to be appended to. This is needed when using the preprocessor. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Tested-by: Marek Behún <marek.behun@nic.cz>
2021-11-13env: Simplify env_get_default()Marek Behún1-21/+24
Instead of pretending that we don't have environment to force searching default environment in env_get_default(), get the data from the default_environment[] buffer directly. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-13env: Fix env_get() when returning empty string using env_get_f()Marek Behún1-1/+1
The env_get_f() function returns -1 on failure. Returning 0 means that the variable exists, and is empty string. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-11-13env: Don't set ready flag if import failed in env_set_default()Marek Behún1-1/+3
Do not set GD_FLG_ENV_READY nor GD_FLG_ENV_DEFAULT if failed importing in env_set_default(). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: Use static_assert() to check if default_environment is too largeMarek Behún1-5/+0
Check sizeof(default_environment) against ENV_SIZE in a static_assert() instead of runtime. Only check if !USE_HOSTCC (for in fw_env tool ENV_SIZE expands to a variable, and cannot be checked statically) nad !DEFAULT_ENV_INSTANCE_EMBEDDED, for in that case the default_environment variable is not set. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: Always use char for default_environmentMarek Behún1-3/+3
Sometimes we use uchar and sometimes char for the default environment array. By always using char, we can get rid of some explicit casts. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: flash: Cosmetic fixMarek Behún1-1/+1
Change tab to space in env_flash_init(). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: flash: Let generic env_init() assign default environmentMarek Behún1-3/+0
env_flash_init() (both implementations) assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nowhere: Cosmetic fixMarek Behún1-2/+2
Use spaces instead of tabs in assignments, since there are no lines to align assignment values to. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nowhere: Let generic env_init() assign default environmentMarek Behún1-1/+0
env_nowhere_init() assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nvram: Cosmetic fix in env_nvram_init()Marek Behún1-2/+2
Use spaces consistently in assignments instead of tabs. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nvram: Let generic env_init() assign default environmentMarek Behún1-2/+1
env_nvram_init() assigns default environment if ENV_INVALID, but this is done in the generic env_init() function, which calls this initializer, so drop it from here. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: nand: Put ENV_INVALID into gd->env_valid if default environmentMarek Behún1-2/+1
env_nand_init() says the environment is valid even if it is assigning default environment due to not being able to access nand pre-reloaction (determined by macro values). Change this to ENV_INVALID and let the generic env_init() function, which calls this initializer, assign the default environment. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Put ENV_INVALID into gd->env_valid on CRC failureMarek Behún1-2/+1
env_sf_init_addr() says the environment is valid even if it is assigning default environment due to CRC failure. Change this to ENV_INVALID and let the generic env_init() function, which calls this initializer, assign the default environment. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Use ENV_VALID enum names instead of literalsMarek Behún1-2/+2
The function env_sf_init_addr() assigns number literals (1) instead of ENV_VALID to gd->env_valid. Fix this. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-31env: sf: Cosmetic fix in env_sf_init_addr()Marek Behún1-2/+2
In the if clause we use tabs and in the else clause spaces. Let's use spaces in the if clause too. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-26env: superfluous check before free()WIP/2021-10-26-add-nand-biterr-and-bugfixesHeinrich Schuchardt1-4/+2
Free() checks if its argument in NULL. There is no need for the caller to do the same. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-10-25env: mmc: Add support for redundant env in both eMMC boot partitionsMarek Vasut2-5/+47
Currently the MMC environment driver supports storing redundant environment only in one eMMC partition at different offsets. This is sub-optimal, since if this one boot partition is erased, both copies of environment are lost. Since the eMMC has two boot partitions, add support for storing one copy of environment in each of the two boot partitions. To enable this functionality, select CONFIG_SYS_REDUNDAND_ENVIRONMENT to indicate redundant environment should be used. Set CONFIG_SYS_MMC_ENV_PART to 1 to indicate environment should be stored in eMMC boot partition. Set CONFIG_ENV_OFFSET equal to CONFIG_ENV_OFFSET_REDUND, and both to the offset from start of eMMC boot partition where the environment should be located. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
2021-10-25env: mmc: Add missing eMMC bootpart restoration to env eraseMarek Vasut1-4/+10
If the environment is stored in eMMC hardware boot partition, the environment driver first stores the currently selected eMMC boot partition, then does the requested operation, and then restores the original boot partition settings. In case the environment operation fails, the boot partition settings are also restored. The 'env erase' implementation in the MMC environment driver lacks the path which restores the boot partition. This could lead to various failure modes, like the system boots the wrong copy of bootloader etc. Fix this by filling in the missing restoration path. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
2021-10-23Merge https://source.denx.de/u-boot/custodians/u-boot-spiWIP/23Oct2021Tom Rini1-3/+1
- Fix mtd erase with mtdpart (Marek Behún) - NXP fspi driver fixes (Kuldeep Singh)
2021-10-23mtd: Remove mtd_erase_callback() entirelyMarek Behún1-3/+1
The original purpose of mtd_erase_callback() in Linux at the time it was imported to U-Boot, was to inform the caller that erasing is done (since it was an asynchronous operation). All supplied callback methods in U-Boot do nothing, but the mtd_erase_callback() function was (until previous patch) grossly abused in U-Boot's mtdpart implementation for completely different purpose. Since we got rid of the abusement, remove the mtd_erase_callback() function and the .callback member from struct erase_info entirely, in order to avoid such problems in the future. Signed-off-by: Marek Behún <marek.behun@nic.cz>
2021-10-21env: Move non-cli env functions to env/common.cMarek Behún1-0/+180
Move the following functions from cmd/nvedit.c to env/common.c: env_set_ulong() env_set_hex() env_get_hex() eth_env_get_enetaddr() eth_env_set_enetaddr() env_get() from_env() env_get_f() env_get_ulong() since these functions are not specific for U-Boot's CLI. We leave env_set() in cmd/nvedit.c, since it calls _do_env_set(), which is a static function in that file. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-21env: Inline env_get_char() into its only userMarek Behún2-11/+2
This function is a relic from the past when environment was read from underlying device one character at a time. It is used only in the case when getting an environemnt variable prior relocation, and the function is simple enough to be inlined there. Since env_get_char() is being changed to simple access to an array, we can drop the failing cases and simplify the code (this could have been done before, since env_get_char() did not fail even before). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-10-21env: Drop env_get_char_spec() and old, unused .get_char() implementationsMarek Behún3-38/+1
Commit b2cdef4861be ("env: restore old env_get_char() behaviour") dropped the .get_char() method from struct env_driver, but left the two existing implementations (eeprom and nvram) in case someone would use them by overwriting weak function env_get_char_spec(). Since this was never done in the 3.5 years, let's drop these methods and simplify the code. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org>
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>
generated by cgit v1.1 at 2024-07-13 01:55:32 +0000