First set of u-boot-at91 fixes for the 2026.07 cycle:

- Cleanup some useless code

All of these platforms enable CONFIG_BOARD_EARLY_INIT_F and then have a
do-nothing board_early_init_f function. Change to not enabling the
option and so not needing an empty function.

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

Replace old bouncing emails with ehristev@kernel.org

Signed-off-by: Eugen Hristev <ehristev@kernel.org>

This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.

Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.

As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.

Note that this is not tested as I do not own this device.

Cc: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Alexander Dahl <ada@thorsis.com>

Add initial mmc defconfig to boot from SDMMC1.

Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com>
Signed-off-by: Romain Sioen <Romain.Sioen@microchip.com>

Add board specific functions for sama7d65_curiosity.

Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com>

Add default configuration for sd-card to boot the linux kernel.

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>

Add board specific functions for sam9x75 curiosity

Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>

Instead of using defines for the RAM size and base address, retrieve these
information from the devicetree.

This aligns with the sama5d27_som1_ek board in commit 73c1589f025d9
("board: sama5d27_som1_ek: Get dram size and base from device tree").

While at it, remove a spurious '/* SPL */' comment.

Signed-off-by: Fabio Estevam <festevam@denx.de>

Simon Glass <sjg@chromium.org> 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.