babae80169 removed bootm_size from ti_common.env to allow K3 boards
to process images larger than 256MB, but preserved it in
ti_armv7_keystone2.env for ARMv7 Keystone2 boards. AM57xx (also ARMv7)
was not covered by that preservation.
Without bootm_size, env_get_bootm_size() falls back to gd->ram_size,
causing initrd_high to be computed as the top of all RAM. On ARM32
boards with more RAM than the DMA zone (e.g. AM572x IDK with 2GiB),
this places the ramdisk above 0xafe00000 (HighMem), which is not
directly accessible by the kernel after MMU setup, causing a silent
crash.
With bootm_size=0x10000000, initrd_high is constrained to
0x80000000 + 0x10000000 = 0x90000000, keeping the ramdisk in the
DMA zone and allowing the kernel to access it correctly.
Fixes: babae80169 ("include: env: ti_common: remove bootm_size")
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
Quentin Schulz <foss+uboot@0leil.net> says:
This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.
The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?
No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.
This was tested based on 70fd0c3bb7 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.
#!/usr/bin/env bash
set -o pipefail
set -eux
ARGS="-BvelPEWM --reproducible-builds --step 0"
./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
./tools/buildman/buildman -o ${O} $ARGS -Ssd $*
O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt
I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.
The summary is the following:
aarch64: (for 537/537 boards) all +0.0 rodata +0.0
uniphier_v8 : all +1 rodata +1
u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
function old new delta
data_gz 10640 10641 +1
arm: (for 733/733 boards) all -0.0 rodata -0.0
uniphier_v7 : all -1 rodata -1
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
function old new delta
data_gz 11919 11918 -1
opos6uldev : all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 18778 18775 -3
uniphier_ld4_sld8: all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 11276 11273 -3
stemmy : all -20 rodata -20
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
function old new delta
data_gz 15783 15763 -20
As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.
Here is the diff for the 5 defconfigs listed above, generated with:
for f in build/*-m; do
diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done
(-m is the build directory for master, and without the suffix, it's the
top commit of this series)
"""
--- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200
+++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200
@@ -970,4 +969,0 @@
-
-#
-# Networking
-#
@@ -975,0 +972 @@
+CONFIG_NET_LEGACY=y
--- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200
+++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200
@@ -733,4 +732,0 @@
-
-#
-# Networking
-#
@@ -738,2 +733,0 @@
-# CONFIG_NET is not set
-# CONFIG_NET_LWIP is not set
--- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200
+++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200
@@ -997,4 +996,0 @@
-
-#
-# Networking
-#
@@ -1002,0 +999 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200
+++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200
@@ -1004,4 +1003,0 @@
-
-#
-# Networking
-#
@@ -1009,0 +1006 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200
+++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200
@@ -875,4 +874,0 @@
-
-#
-# Networking
-#
@@ -880,0 +877 @@
+CONFIG_NET_LEGACY=y
"""
This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
(old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
be part of .config,
GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849
It passes.
Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n,
when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so
let's simplify the various checks across the codebase.
SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so
the proper symbol is still defined in SPL whenever needed.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Highlight that NET really is the legacy networking stack by renaming the
option to NET_LEGACY.
This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise
CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL.
The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is
using the legacy networking app so this seems fine to do.
This also has the benefit of removing potential confusion on NET being a
specific networking stack instead of "any" network stack.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some extension boards have EEPROM part numbers that do not directly match
their devicetree overlay filenames. Introduce a static name_mapping table
and a set_cape_overlay() helper that translates the part number and version
strings read from the EEPROM into the correct overlay filename.
When no entry matches, fall back to the existing behavior of constructing
the overlay name as "<part_number>-<version>.dtbo" directly from the
EEPROM content.
Add an initial entry mapping BB-GREEN-HDMI revision 00A0 to
am335x-bone-hdmi-00a0.dtbo.
Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com>
AM62d currently shares resource management configuration files with
AM62a. However, AM62a resource management needs to be modified for DMA
resource sharing scheme for CPSW3G Ethernet functionality to support
multi-core traffic handling.
Add separate AM62d-specific resource management configuration files to
decouple from the AM62a changes and maintain proper resource allocation
for AM62d.
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
bootcmd_ti_mmc had cpsw0_qsgmii_phyinit related scripts even though this
was only relevant for the j721e/j7200 SoCs. This patch instead factors
out those scripts into a generic 'board_init' which is called as part of
bootcmd_ti_mmc.
This allows boards to more easily add custom behaviour to the ti_mmc
bootflow instead of having to modify the ti_common.env file.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Neha Malcom Francis <n-francis@ti.com> says:
Typically we do not enable these configs by default but would still like to
have the option to start building them in our default build flow for
testing. Also there is the added advantage of users being able to see what
is needed in case they choose to enable these features.
Link: https://lore.kernel.org/r/20260226122508.2269682-1-n-francis@ti.com
Sparsh Kumar <sparsh-kumar@ti.com> says:
This series updates the Resource Management (RM) configuration files
for AM62 family devices to align with the TIFS v11.02.09 firmware.
Background
----------
With the latest TIFS firmware (v11.02.09), an additional virtual
interrupt and event is reserved for MCU cores to DM usage on am62x,
am62ax, and am62px devices. This series brings the rm-cfg and
tifs-rm-cfg files in sync with these firmware changes across both
TI reference boards and vendor boards.
These changes are backward compatible with older TIFS firmware versions.
Additionally, the am62x platform was originally introduced without a
tifs-rm-cfg.yaml file, unlike other platforms in the AM62 family.
This series addresses that gap and enables tifs-rm-cfg in binman for
am625-sk and am62p-sk platforms.
Changes
-------
TI reference boards (patches 1-4):
- Update rm-cfg.yaml for am62x, am62ax, am62px
- Sync am62px tifs-rm-cfg.yaml with TIFS firmware template
- Add missing tifs-rm-cfg.yaml for am62x
- Enable tifs-rm-cfg in binman for am625-sk and am62p-sk
Vendor boards (patches 5-9):
- beagleplay (am62x-based)
- phytec phycore_am62x
- toradex verdin-am62
- phytec phycore_am62ax
- toradex verdin-am62p
with the required interrupt reservation. The tifs-rm-cfg.yaml files
cannot be updated without access to the corresponding SysConfig files,
as both rm-cfg.yaml and tifs-rm-cfg.yaml must remain in sync.
Link: https://lore.kernel.org/r/20260225132425.3096103-1-sparsh-kumar@ti.com
The am62x platform was originally introduced without a
tifs-rm-cfg.yaml file. Add the tifs-rm-cfg to bring am62x
in line with other am62 family of devices (am62px and am62a)
which all include this file.
This complements the rm-cfg update earlier in this series.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Synchronize tifs-rm-cfg file with the latest v11.02.09
TIFS firmware rm configuration:
- Update am62px tifs-rm-cfg with revised resource allocations
- Apply formatting updates to align with TIFS template
This brings tifs-rm-cfg in sync with the rm-cfg changes
earlier in this series.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
With the latest v11.02.09 TIFS firmware, an additional
virtual interrupt and event is reserved for MCU cores
to DM usage on am62x, am62ax and am62px devices.
Update the rm-cfg to reflect this new reservation.
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Enable firmware TPM (fTPM) support via OP-TEE for K3 platforms with
MMC hardware. This provides TPM 2.0 functionality through
Microsoft's fTPM Trusted Application running in OP-TEE secure world,
using eMMC RPMB as persistent storage.
fTPM support in U-Boot provides the foundation for measured boot
and disk encryption use cases.
The ARM64 condition ensures these apply only to A53/A72 cores and the
MMC condition ensures fTPM is enabled only on platforms with eMMC
hardware support.
Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Update am62ax and am62dx tifs-rm-cfg with allocation entries for C7x
core to match with their rm-cfg. Following updates are added for C7x:
- Share split BCDMA tx and rx channels between DM R5 and C7x.
- Share rings for split BCDMA tx and rx channels between DM R5 and C7x.
- Add global events and virtual interrupts for C7x.
Fixes: 01e0127753 ("am62a: yaml: Add board configs for AM62ax")
Signed-off-by: Sparsh Kumar <sparsh-kumar@ti.com>
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
We currently provide default board names for each board in their
respective evm.c file. However for custom boards, this behaviour
overwrites the default DT as set in the defconfig
(CONFIG_DEFAULT_FDT_FILE or CONFIG_DEFAULT_DEVICE_TREE).
This patch changes the default name to be NULL which prevents this
overwrite and allows ti_set_fdt_env to instead fallback to the correct
DT as set in Kconfig.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Since commit 27cc5951c8 ("include: env: ti: add default for
do_main_cpsw0_qsgmii_phyinit"), the value of the environment variable
do_main_cpsw0_qsgmii_phyinit happened to remain '0' and couldn't be
changed without user intervention. This behavior is due to the following
cyclic dependency:
A) ti_common.env sets do_main_cpsw0_qsgmii_phyinit to '0' and its value
can only be updated automatically by main_cpsw0_qsgmii_phyinit.
B) main_cpsw0_qsgmii_phyinit is defined in j721e.env and it can run only
if 'do_main_cpsw0_qsgmii_phyinit' is already '1' which isn't possible
unless the user manually assigns the value.
Fix the aforementioned cyclic dependency by using board_late_init() to
detect the QSGMII Daughtercard and set do_main_cpsw0_qsgmii_phyinit.
Additionally, to address the issue of do_main_cpsw0_qsgmii_phyinit being
'undefined' for other platforms, replace:
if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1;
with:
if env exists do_main_cpsw0_qsgmii_phyinit;
in ti_common.env.
Fixes: 27cc5951c8 ("include: env: ti: add default for do_main_cpsw0_qsgmii_phyinit")
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Enable 32k crystal on the board. If external 32k source is not
used, 32k rc-osc comes into play, which is accurate to +-20%.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Enable 32k crystal on the board. If external 32k source is not
used, 32k rc-osc comes into play, which is accurate to +-20%.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Enable 32k crystal on the board. If external 32k source is not
used, 32k rc-osc comes into play, which is accurate to +-20%.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Add a common helper function for doing the basic configuration
required for enabling the 32k crystal on some of the TI boards.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <cingel.marian@gmail.com>
This patch fixes a boot failure on the AM64x EVM that was introduced when the do_board_detect function was removed during a refactoring.
It restores the do_board_detect function for the AM64x, AM62x, and AM65x boards to ensure the common board detection logic is executed correctly.
Fixes: 804b80288a ("board: am65x: Use generic AM6x board detection function")
Fixes: ce56e553c3 ("board: am64x: Use generic AM6x board detection functions")
Fixes: ff1b83c095 ("board: am62x: Add support for reading eeprom data")
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Anshul Dalal <anshuld@ti.com> says:
This patch series adds support for AM6254atl SiP (or AM62x SiP for
short) to U-Boot.
The OPN (Orderable Part Number) 'AM6254atl' expands as follows[1]:
AM6254atl
||||
|||+-- Feature Lookup (L indicates 512MiB of integrated LPDDR4)
||+--- Device Speed Grade (T indicates 1.25GHz on A53 cores)
|+---- Silicon PG Revision (A indicates SR 1.0)
+----- Core configuration (4 indicates A53's in Quad core config)
AM62x SiP provides the existing AM62x SoC with 512MiB of DDR
integrated in a single packages. The first 4 patches in the series
are cherry-picked from the devicetree-rebasing repository at
'v6.18-rc2-dts'.
Link: https://lore.kernel.org/r/20251025-62sip_support-v3-0-b4c8314d0055@ti.com
Guillaume La Roque (TI.com) <glaroque@baylibre.com> says:
This series adds EEPROM board detection support for AM62x and refactors
the board detection code across AM6x family boards to eliminate code
duplication.
The series introduces two new generic functions for AM6x boards:
- do_board_detect_am6(): Reads the on-board EEPROM with fallback logic
to alternate I2C addresses
- setup_serial_am6(): Sets up the serial number environment variable
from EEPROM data
Link: https://lore.kernel.org/r/20251103-am62xeeprom-v3-0-e390779c0fc5@baylibre.com
TI's AM6254atl (or AM62x SiP for short) provides the existing AM62x SoC
with 512MiB of DDR integrated in a single package.
This patch adds the necessary U-Boot devie tree files, the required
defconfigs along with the documentation for the AM62x SiP EVM.
AM62x SiP differs from the already supported AM62x in following ways:
- OP-TEE for the AM62x resides from 0x9e800000 to 0xa0000000 which needs
to be moved to 0x80080000 to free up space at end of DDR in AM62x SiP
with 512MiB of memory. This is required to allow U-Boot to relocate to
end of DDR before booting to the kernel.
- Changes to the env:
1. splashimage address updated from 0x80200000 to 0x81a00000
2. DFU addresses updated to match updated TEXT_BASE for SPL and U-Boot
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Replace the board-specific implementation of do_board_detect()
with a call to the generic do_board_detect_am6() function to
avoid code duplication across AM6x family boards.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Replace the board-specific implementation of do_board_detect() and
setup_serial() with calls to the generic do_board_detect_am6() and
setup_serial_am6() functions.
The generic function provides the same functionality with
additional fallback logic to try alternate EEPROM addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot
Use the generic do_board_detect_am6() and setup_serial_am6()
functions to avoid code duplication across AM6x family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Add two new generic functions for AM6x family boards to simplify
board-specific implementations:
- do_board_detect_am6(): Generic board detection function that reads
the on-board EEPROM. It first attempts to read at the configured
address, and if that fails, tries the alternate address
(CONFIG_EEPROM_CHIP_ADDRESS + 1). This provides a common
implementation that can be used across different AM6x boards.
- setup_serial_am6(): Sets up the serial number environment variable
from the EEPROM data. The serial number is converted from
hexadecimal string format to a 16-character hexadecimal
representation and stored in the "serial#" environment variable.
Both functions are protected by CONFIG_IS_ENABLED(TI_I2C_BOARD_DETECT)
and are designed to be used by AM62x, AM64x, AM65x, and other AM6x
family boards.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Guillaume La Roque (TI.com) <glaroque@baylibre.com>
Kory Maincent (TI.com) <kory.maincent@bootlin.com> says:
This series converts the extension board framework to use UCLASS as
requested by Simon Glass, then adds extension support to pxe_utils
and bootmeth_efi (not tested) to enable extension boards devicetree load
in the standard boot process.
I can't test the imx8 extension scan enabled by the
imx8mm-cl-iot-gate_defconfig as I don't have this board.
I also can't test the efi bootmeth change as I don't have such board.
Link: https://lore.kernel.org/r/20251030-feature_sysboot_extension_board-v5-0-cfb77672fc68@bootlin.com
Remove the legacy extension board implementation now that all boards
have been converted to use the new UCLASS-based framework. This
eliminates lines of legacy code while preserving functionality
through the modern driver model approach.
Update the bootstd tests, due to the removal of extension hunter.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Migrate TI board cape detection from legacy extension support to the
new UCLASS-based extension board framework.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Clean up and reorganize cape detection code structure for improved
maintainability and readability.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
The CAPE_EEPROM_BUS_NUM configuration option was incorrectly depending
on CMD_EXTENSION, which represents the extension board command. However,
the cape scan functionality can be built and used independently of the
command interface through the SUPPORT_EXTENSION_SCAN option.
Change the dependency from CMD_EXTENSION to SUPPORT_EXTENSION_SCAN to
properly reflect that the I2C bus configuration is needed for the cape
scan function itself, not specifically for the command.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
Disable cape detection functionality in xPL images to reduce size and
complexity in the early boot stage.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
The current spl_board_fixups API allows for modification of spl_image
before the SPL jumps to it. This can be used to modify the DT for the
next boot stage, however the current API only allows either the machine
arch or the board to use it.
This limits the utility of the API as there might be certain fixups that
should be applied to all boards sharing the same machine architecture
with others being board specific.
For TI's K3 specifically, this prevents us from performing architecture
level fixups since a lot of TI boards are already making use of the
spl_board_fixups API.
Therefore this patch splits the API into two to allow both board and the
architecture specific fixups. The order is kept as arch then board to
give board specific fixups the precedence.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Add initial support for AM62D2-EVM, Kconfig entries for binman, SPL,
base DTS files for u-boot and SPL, HS-SE and HS-FS support and initial
configs with SD-MMC, UART, eMMC and OSPI boot providing a baseline for
further enablement.
Also add labels and targets to AM62A-SK binman to enable AM62D2-EVM
builds to reuse existing binman infrastructure.
Technical Reference Manual - https://www.ti.com/lit/pdf/sprujd4
Schematics Link - https://www.ti.com/lit/zip/sprcal5
Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
Commit 649f4a7d3c ("board: ti: am57xx: Set fdtfile from C code
instead of findfdt script") prepends "ti/omap/" to the actual name
of the fdtfile whereas fit image boot needs exact dtb name. So, remove
"ti/omap" from name_fit_config by substituting it with an empty string.
Fixes: 649f4a7d3c ("board: ti: am57xx: Set fdtfile from C code instead of findfdt script")
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Add CMD_MEMINFO and CMD_MEMINFO_MAP to list of configs implied by
TI_COMMON_CMD_OPTIONS. This allows users to easily view the memory
configuration and the memory maps at runtime.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Make the fdt_map parameter a pointer to const, since the function only
reads the mapping table. This improves API correctness and allows maps
to live in read-only data.
No functional change intended
Signed-off-by: Bhimeswararao Matsa <bhimeswararao.matsa@gmail.com>
