starfive-tech/u-boot.git/env/sf.c, branch rtthread_AMP

env: sf: remove the static env_flash variable

2021-04-16T21:33:33+00:00

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

env: sf: add missing spi_flash_free

2021-04-16T21:33:09+00:00

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

env: sf: add support of command env erase

2021-04-16T21:32:52+00:00

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

env: sf: update the use of macro ENV_SAVE_PTR

2021-04-16T21:32:34+00:00

Remove CONFIG_IS_ENABLED(SAVEENV) as it is already tested in the ENV_SAVE_PTR macro. Signed-off-by: Patrick Delaunay

env: increment redund flag on read fail

2021-04-16T15:55:55+00:00

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 CC: Joe Hershberger CC: Wolfgang Denk CC: Heiko Schocher Reviewed-by: Tom Rini

env: add CONFIG_ENV_SECT_SIZE_AUTO

2021-04-16T15:55:55+00:00

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

env/sf.c: use a variable to hold the sector size

2021-04-16T15:55:55+00:00

As preparation for the next patch, use a local variable to represent the sector size. No functional change. Signed-off-by: Rasmus Villemoes

common: Drop asm/global_data.h from common header

2021-02-02T20:33:42+00:00

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 at all, so remove that include. Signed-off-by: Simon Glass Signed-off-by: Tom Rini

env: sf: cosmetic: remove unnecessary space

2021-01-29T15:36:49+00:00

Remove the unnecessary space before the 2 "done:" labels in env_sf_save(). Signed-off-by: Patrick Delaunay

env: sf: fix init function behaviour

2020-11-03T15:04:25+00:00

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 Tested-by: Michael Walle [For the SF environment] Signed-off-by: Heiko Schocher