u-boot.git/env/mmc.c, branch master

env: Invert gd->env_valid for env_mmc_save

2025-10-21T19:18:46+00:00

The A/B update strategy of the env's has a gap in the first 2 calls of saveenv.
The env's are stored twice on the first memory area if:
gd->env_valid == ENV_INVALID.

u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK  <-- !!!
u-boot=> saveenv
Saving Environment to MMC... Writing to redundant MMC(1)... OK
u-boot=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OK

This is the same issue as resolved in commit e589d5822cac ("env: spi:
Fix gd->env_valid for the first write")

Signed-off-by: Michael Glembotzki 
Signed-off-by: Jasper Orschulko 
Signed-off-by: Michael Heimpold 
[trini: Amend the commit message]
---
Changes in v2:
- Rebase to current master
- Amend the commit message to reference the SPI version of this fix,
  which had significant follow-up discussion.

env: mmc: fix offsets relative to the end of the partition

2025-07-02T04:39:21+00:00

According to the help text, you can set negative offsets to indicated
that the offset is relative to the end of the parition. But kconfig
doesn't let you specify negative hex values. I think this fell through
the cracks when converting the symbol from a '#define' to a kconfig
option.

Introduce a new boolean kconfig option to switch on the "relative to the
end" behavior.

Signed-off-by: Michael Walle 
Reviewed-by: Quentin Schulz 
Signed-off-by: Peng Fan

env: Rename ENV_MMC_PARTITION to ENV_MMC_SW_PARTITION

2025-06-20T18:15:08+00:00

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_SW_PARTITION to clarify this is the SD/MMC software
partition table entry selector. Update the help text accordingly.

Signed-off-by: Marek Vasut

env: Rename SYS_MMC_ENV_PART to ENV_MMC_EMMC_HW_PARTITION

2025-06-20T18:15:08+00:00

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.

Signed-off-by: Marek Vasut

env: Rename SYS_MMC_ENV_DEV to ENV_MMC_DEVICE_INDEX

2025-06-20T18:15:08+00:00

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.

Signed-off-by: Marek Vasut

env: Rename SYS_REDUNDAND_ENVIRONMENT to ENV_REDUNDANT

2025-06-20T18:15:08+00:00

Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.

Signed-off-by: Marek Vasut

env: mmc: Fix test for ENV_IS_EMBEDDED

2025-04-10T17:58:04+00:00

The symbol "ENV_IS_EMBEDDED" is an environment internal define and not a
real CONFIG symbol. The IS_ENABLED() macro is still valid to use here,
so update the check.

Signed-off-by: Tom Rini

env: mmc: Clean up env_mmc_load() ifdeffery

2025-02-28T14:35:52+00:00

Rename the variants of env_mmc_load() for redundant and non-redundant
environment to env_mmc_load_redundant() and env_mmc_load_singular()
respectively and convert the env_mmc_load() implementation to use of
if (IS_ENABLED(...)). As a result, drop __maybe_unused from
mmc_env_is_redundant_in_both_boot_hwparts().

Signed-off-by: Marek Vasut 
Reviewed-by: Quentin Schulz 
Reviewed-by: Mattijs Korpershoek

env: mmc: Make redundant env in both eMMC boot partitions consider DT properties

2025-02-28T14:35:52+00:00

Introduce a new function mmc_env_is_redundant_in_both_boot_hwparts()
which replaces IS_ENABLED(ENV_MMC_HWPART_REDUND) and internally does
almost the same check as the macro which assigned ENV_MMC_HWPART_REDUND
did, and call it in place of IS_ENABLED(ENV_MMC_HWPART_REDUND).

The difference compared to IS_ENABLED(ENV_MMC_HWPART_REDUND) is
in the last conditional, which does not do plain macro compare
(CONFIG_ENV_OFFSET == CONFIG_ENV_OFFSET_REDUND), but instead does
mmc_offset(mmc, 0) == mmc_offset(mmc, 1). If OF_CONTROL is not
in use, this gets optimized back to original macro compare, but
if OF_CONTROL is in use, this also takes into account the DT
properties u-boot,mmc-env-offset and u-boot,mmc-env-offset-redundant.

Signed-off-by: Marek Vasut 
Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Quentin Schulz

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25+00:00

Simon Glass  says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.