u-boot.git/tools/env/fw_env.c, branch master

fw_env: drop unneeded variables from flash_write_buf()

2026-03-06T16:32:41+00:00

Recent cleanups made some variables redundant. Both: "blocklen" and
"erase_len" ended up being used as temporary variables used locally in
some short code paths.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Tom Rini

fw_env: move "erasesize" calculation up in a code

2026-03-06T16:32:41+00:00

Calculate "erasesize" in the same place where other offsets and lengths
/ sizes are calculated. It makes code more consistent and will allow
further cleanups.

Signed-off-by: Rafał Miłecki

fw_env: unify calculation of "blockstart" in flash_write_buf()

2026-03-06T16:32:41+00:00

In both code paths "blockstart" is calculated the same way. Unify it.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Tom Rini

fw_env: add ROUND_UP() helper

2026-03-06T16:32:41+00:00

We already have DIV_ROUND_UP() to simplify code so add ROUND_UP() as
well. This makes code in flash_write_buf() easier to follow.

Signed-off-by: Rafał Miłecki

fw_env: allocate buffer of proper size in flash_write_buf()

2026-03-06T16:32:41+00:00

When dealing with env data not aligned to flash blocks flash_write_buf()
has to use an extra buffer. It reads existing flash content to it,
modifies required part and writes it back.

While reading and writing a size stored in "write_total" is used. It's
what should be used when allocating the buffer too.

In some cases allocating memory of "erase_len" size could result in
allocating too big buffer. That wouldn't break anything but it was
making code less intuitive.

Signed-off-by: Rafał Miłecki

fw_env: use "erasesize" variable in writing loop

2026-03-06T16:32:41+00:00

Use "erasesize" instead of "blocklen" in flash_write_buf()'s loop. This
change touches code executed for bad NAND blocks so it doesn't affect
any behaviour (for NAND flashes "blocklen" and "erasesize" are equal).

This just makes code a bit more consistent as "erasesize" is what is
used all around inside the writing loop.

Signed-off-by: Rafał Miłecki

envtools: make them build again

2024-10-22T02:51:23+00:00

In v2024.10, "make envtools" is broken for at least these defconfigs:

   am335x_evm_defconfig
   rpi_3_defconfig
   rpi_4_defconfig
   mx7dsabresd_defconfig
   wandboard_defconfig
   imx8mp_evk_defconfig

The only defconfig we use for which it is not broken is
stm32mp13_defconfig. They all work just fine in v2024.07.

The symptoms are slightly different, but all related to the fact that
some transitively included header uses IS_ENABLED or CONFIG_IS_ENABLED
without linux/kconfig.h having already been included.

A simple git bisect doesn't produce anything sensible, it ends up at
3a9f642ca94 (crypto: nuvoton: npcm_sha: Support SHA 384/512) which
clearly has nothing to do with this. But digging deeper, one
eventually finds 0f92fa45603 ("env: Remove  and add needed
includes").

So at first I tried adding "#include " in
include/env_default.h and include/env_flags.h. That fixes it for some,
but not all, of the above. For example rpi_3_defconfig still fails,
then in log.h complaining about BIT() and u8 not being defined. At
least BIT() is should have gotten from bitops.h, except that that's
behind ifdef __KERNEL__, so not set for the envtools build.

It turns out that the envtools source code in fw_env_private.h already
has some hackery to deal with all this, in the form of the __ASSEMBLY__
games it plays before including config.h. It seems that if we just
make sure to do that include early enough, so that config.h is indeed
parsed with that __ASSEMBLY__ hackery in place, everything builds
fine.

Fixes: 0f92fa45603 ("env: Remove  and add needed includes")
Signed-off-by: Rasmus Villemoes 
Reviewed-by: Tom Rini 
Reviewed-by: Fabio Estevam

fw_env: autodetect NAND erase size and env sectors

2024-01-05T20:41:47+00:00

As already done for NOR chips, if device ESIZE and ENVSECTORS static
configurations are both zero, then autodetect them at runtime.

Cc: Joe Hershberger 
cc: Stefan Agner 
cc: Rasmus Villemoes 
Signed-off-by: Anthony Loiseau

fw_env: keep calling read() until whole flash block is read

2024-01-05T20:41:47+00:00

It's totally valid for read() to provide less bytes than requested
maximum. It may happen if there is no more data available yet or source
pushes data in small chunks.

This actually happens when trying to read env data from NVMEM device.
Kernel may provide NVMEM content in page size parts (like 4096 B).

This fixes warnings like:
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 16384 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 12288 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 8192 bytes but got 4096

Since the main loop in flash_read_buf() is used to read blocks this
patch adds a new nested one.

Signed-off-by: Rafał Miłecki

fw_env: rename variables holding env data content

2024-01-05T20:41:47+00:00

Rename "addr0" and "addr1" to "buf0" and "buf1" accordingly. Name "addr"
suggests that variable contains a numeric value being some kind of
address. Name "buf" is de facto a standard name for pointer to allocated
memory for reading data to.

While at it drop redundant checks for NULL before calling free().

Signed-off-by: Rafał Miłecki