| Age | Commit message (Collapse) | Author |
|---|
|
Kernel dts import now provides bootph-all and bootph-pre-ram properties
for the properties we have been overriding so far. Drop the same.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
k3-am62* SoC dtsi files now provide the following:
bootph-all: dmss secure_proxy_main dmsc k3_pds k3_clks k3_reset
main_pmx0 main_timer0 mcu_pmx0 wkup_conf chipid
bootph-pre-ram: secure_proxy_sa3 main_esm mcu_esm
Drop these from board r5 and u-boot.dtsi files as these are duplicate in
them now.
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Sync with kernel v6.7-rc1 and sync up the u-boot dts files accordingly.
Tested-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
BCDMA can be used at SPL for OSPI boot and mem-to-mem DMA
so add "bootph-all" to BCDMA node.
Suggested-by: Nishanth Menon <nm@ti.com>
Fixes: 9a3f2b6798b0 ("arm: dts: k3-am625-verdin-wifi-dev-u-boot.dtsi: Fix DMA/Ethernet")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
Sync u-boot device tree with Linux kernel 6.7-rc1
Signed-off-by: Reid Tonking <reidt@ti.com>
|
|
Change spl_enable_dcache so it also enable icache on SPL
initialization for the main domain part of the boot flow. This
improves bootloader booting time.
Link: https://lore.kernel.org/all/20231109140958.1093235-1-joao.goncalves@toradex.com/
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Tested-by: Nishanth Menon <nm@ti.com>
|
|
Add generic boot-flow diagrams, and SoC-specific info around build
steps.
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Switch over to stdboot
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Set the default boot_targets to map up SD card as priority followed by
emmc and so on.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Use the default findfdt instead of local logic.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Enable networking
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
In preparation for enabling ethernet for the am62ax family of SoCs,
introduce the initial DMA channel settings for the am62ax
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
[bb@ti.com: expanded on commit message]
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Sync with kernel v6.7-rc1 and sync up the u-boot dts files accordingly.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
main_timer0 is used by u-boot as the tick-timer. Add it to the soc
devices list so it an be enabled via the k3 power controller.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Sync the U-Boot DTS files with those of Kernel v6.7-rc1.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Move esm-k3.txt to ti,j721e-esm.yaml in line with the devicetree
documentation in kernel.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add base documentation for BeagleBone AI-64.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add basic support for mmc/emmc and networking support for BeagleBone
AI-64.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Add base support for BeagleBone AI-64 board support.
Further information at https://beagleboard.org/ai-64
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
BeagleBoard.org BeagleBone AI-64 is an open source hardware single
board computer based on the Texas Instruments TDA4VM SoC featuring
dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
2x 6-core Programmable Real-Time Unit and Industrial Communication
SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
BeagleBone expansion headers.
This board family can be indentified by the BBONEAI-64-B0 in the
at24 eeprom:
[aa 55 33 ee 01 37 00 10 2e 00 42 42 4f 4e 45 41 |.U3..7....BBONEA|]
[49 2d 36 34 2d 42 30 2d 00 00 42 30 30 30 37 38 |I-64-B0-..B00078|]
Baseline of the devicetree is from v6.6-rc1
https://beagleboard.org/ai-64
https://git.beagleboard.org/beagleboard/beaglebone-ai-64
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Move the omap3 beagle to the beagle vendor folder representing
BeagleBoard.org platforms.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Move BeaglePlay documentation to beagle as a board vendor and update
references accordingly.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Add am62x_beagleplay_* defconfig customized for the configuration of
BeaglePlay and drop the config fragments.
This is in preparation for dropping the dependency on ti vendor folder
entirely.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
With the upcoming folder separation, there is no further need to depend
on am625-binman.dtsi. Duplicate the existing definitions to u-boot.dtsi
and r5.dts as appropriate.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When using include directives within a section that is included by non
TI board rst file, k3.rst and other include paths need to be relative to
doc/board/ base.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Kernel commit 1b77265626a4 ("arm64: dts: ti: k3-j7200-mcu-wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.
This is similar to the approach in commit 5b2671594b80 ("configs:
j721e: Remove HBMC_AM654 config"), introduced to j7200 evm platform.
[1] https://lore.kernel.org/all/20230424184810.29453-1-afd@ti.com/
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Commit 5019170970ad ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b368b ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Refactor J721E J7200 definition to make this independent of board
macros.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Enable SOC_K3_J721E_J7200 when board is J7200 EVM - this allows us to
differentiate J7200 platform cleanly in board independent codebase.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Add explicit boot_targets to indicate the specific boot sequence to
follow.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Switch to using IS_ENABLED() for inline function usage.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
Drop headers that are no longer necessary for build
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Manorit Chawdhry <m-chawdhry@ti.com>
|
|
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Andrew Davis <afd@ti.com>
|
|
SYSFW is only ever loaded by the R5 core, move the code into that
directory. While here also move the related Kconfig symbols.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
The kconfig option SPL means this build supports SPL but not that
this build is SPL, nor that this build is the SPL running on R5.
For options that are for R5 SPL use CPU_V7R.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
This makes it clear these are only to be used by the R5 builds of SPL.
And this will be used to later more cleanly split the two builds.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis <afd@ti.com>
|
|
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm into next
tpm_tis_send-cleanup
|
