Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

board: siemens: Remove <common.h> and add needed includes

Remove <common.h> from this board vendor directory and when needed
add missing include files directly.

Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

board: siemens: iot2050: Fix M.2 detection

The "simpler" the logic, the higher the probability to not test and get
things wrong, again: The absence of a "-PG2" suffix is not sufficient to
derive that we are on PG1. There is also "IOT2050-ADVANCED-M2".

Finally fix that by exactly matching against the two PG1 device names.

While changing this, we can also drop the not really needed check for
!board_is_sr1 in board_is_m2 and call the boards by their names
("board_is_pg1").

Reported-and-tested-by: Bao Cheng Su <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: Fix logical bug in PG1/PG2 detection

This caused the wrong fdtfile to be set and was failing to apply M.2
settings.

Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.

Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: Remove <common.h> and add needed includes

Remove <common.h> from this board vendor directory and when needed
add missing include files directly.

Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

board: siemens: iot2050: Fix M.2 detection

The "simpler" the logic, the higher the probability to not test and get
things wrong, again: The absence of a "-PG2" suffix is not sufficient to
derive that we are on PG1. There is also "IOT2050-ADVANCED-M2".

Finally fix that by exactly matching against the two PG1 device names.

While changing this, we can also drop the not really needed check for
!board_is_sr1 in board_is_m2 and call the boards by their names
("board_is_pg1").

Reported-and-tested-by: Bao Cheng Su <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: Fix logical bug in PG1/PG2 detection

This caused the wrong fdtfile to be set and was failing to apply M.2
settings.

Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.

Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: Fix M.2 detection

The "simpler" the logic, the higher the probability to not test and get
things wrong, again: The absence of a "-PG2" suffix is not sufficient to
derive that we are on PG1. There is also "IOT2050-ADVANCED-M2".

Finally fix that by exactly matching against the two PG1 device names.

While changing this, we can also drop the not really needed check for
!board_is_sr1 in board_is_m2 and call the boards by their names
("board_is_pg1").

Reported-and-tested-by: Bao Cheng Su <baocheng.su@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: Fix logical bug in PG1/PG2 detection

This caused the wrong fdtfile to be set and was failing to apply M.2
settings.

Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.

Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: Fix logical bug in PG1/PG2 detection

This caused the wrong fdtfile to be set and was failing to apply M.2
settings.

Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.

Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.

Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

arm: mach-k3: Remove empty sys_proto.h include

This header file is now empty, remove it.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

arm: mach-k3: Move MSMC fixup to SoC level

The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.

We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

iot2050: Add support for configuring M.2 connector

The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.

The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.

Based on original patch by Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: iot2050: use the named gpio to control the user-button

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm: dts: iot2050: Use the auto generator nodes for fdt

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: iot2050: Split the build for PG1 and PG2

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

boards: siemens: iot2050: Ignore network errors during bootstage tracking

We need to filter out NET_ETH_START errors because we have to enable
networking in order to propagate the MAC addresses to the DT while there
is no network driver for the prueth in U-Boot yet.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

bootstage: Add SPL support

Allow usage of the bootstage facilities in SPL.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

board: siemens: Add support for SIMATIC IOT2050 devices

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>