In order to build the spi flash environment driver, but with
CONFIG_ENV_REDUNDANT disabled we must make use of IF_ENABLED_INT to
check for a value in CONFIG_ENV_OFFSET_REDUND otherwise we will fail to
build.

Signed-off-by: Tom Rini <trini@konsulko.com>

In order to have ENV_IS_IN_NAND be valid we must have MTD_RAW_NAND
enabled as a minimum, express this dependency in Kconfig.

Signed-off-by: Tom Rini <trini@konsulko.com>

When both environment copies have valid CRCs but the flag bytes do not
match any recognized pair, env_flash_init() falls through without
setting gd->env_addr or gd->env_valid. This is a problem because:

1. env_init() then sets gd->env_addr = &default_environment (in RAM).

2. In env_flash_load(), the pointer comparison
   gd->env_addr != &flash_addr->data evaluates true (RAM != flash),
   triggering the pointer swap that selects the secondary copy.

3. The repair logic writes OBSOLETE (0x00) to the non-active flag but
   cannot promote the other flag from 0x00 to ACTIVE (0x01) because
   NOR flash requires a sector erase to set bits. Both copies end up
   with flag=0x00.

4. On every subsequent boot, flag1 == flag2 triggers the ENV_REDUND
   path, printing a spurious "recovered successfully" warning until
   an explicit saveenv erases and rewrites the sectors.

The recognized flag values are ACTIVE (0x01), OBSOLETE (0x00), and
erased (0xFF). Of the 256 possible flag values, the existing chain of
if/else-if handles only three: 253 of 256 values fall through without
setting gd->env_addr. Combined with 0x00 (already stuck on NOR),
254 of 256 values eventually reach the persistent-warning state.

Other env backends (SPI flash, NAND, MMC) handle this through
env_check_redund() in env/common.c, which uses a numeric comparison
of the flags as a serial counter and always reaches a decision. The
CFI flash backend is the only one that uses its own flag-matching
logic.

Add a catch-all else clause that defaults to the primary copy with
ENV_REDUND status, matching the existing behavior for the flag1==flag2
case. This ensures gd->env_addr is always set, preventing the
unintended pointer swap. The condition is recoverable via saveenv.

Signed-off-by: Neil Berkman <neil@xuku.com>

Reproducer: https://gist.github.com/neilberkman/4155612a7942d3f510f204eb85e61943

The SPI flash backend (env/sf.c) has a related but distinct issue:
it retained legacy boolean save semantics but its load path now uses
the common serial-number logic in env_check_redund(), creating an
inconsistency under interrupted updates. That has wider implications
for fw_env.c and would need separate discussion.

TARGET namespace is for machines / boards / what-have-you that
building U-Boot for. Simply replace from TARGET to ARCH
make things more clear and proper for ALL SoCFPGA.

Signed-off-by: Brian Sune <briansune@gmail.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

# Conflicts:
#	drivers/ddr/altera/Makefile

Add support for converting single-copy environment to redundant environment.
In case CRC checks on both redundant environment copies fail, try one more
CRC check on the primary environment copy and treat it as single environment.
If that check does pass, rewrite the single-copy environment into redundant
environment format, indicate the environment is valid, and import that as
usual primary copy of redundant environment. Follow up 'env save' will then
store two environment copies and the system will continue to operate as
regular redundant environment system.

Add test which validates this upgrade path. The test starts with spi.bin
which is pre-populated as single-copy environment and then upgrades that
environment to dual-copy environment.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

As resolved and explained in detail in commit e589d5822cac ("env: spi:
Fix gd->env_valid for the first write") and archived discussion there is
a corner case where we don't do the right thing with redundant
environments. This same exact check was present in the mmc code and
resolved with commit 813a0df27a8a ("env: Invert gd->env_valid for
env_mmc_save") and in the discussion of that patch, I noted that both
fat and ubi (and at the time, sf) were doing the same thing. Take the
time now to correct fat and ubi environment.

Signed-off-by: Tom Rini <trini@konsulko.com>

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 <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
[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.

Falcon mode uses falcon_image_file from the env during mmc fs boot, but
external env can be compromised. Therefore disable access to external
env by setting SPL_ENV_IS_NOWHERE when SPL_OS_BOOT_SECURE is set.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Merge the outstanding changes from the 'next' branch to master.

%s/environemt/environment

Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>