| Age | Commit message (Collapse) | Author |
|---|
|
I had missed that this series was no longer ready to merge as there are
other issues to resolve.
This reverts commit a5ef1849394de475ee3bb9ebfc7629b4dd3b746a, reversing
changes made to 4e7a9bb0885e75853687956002e69875e0ef64e6.
Signed-off-by: Tom Rini <[email protected]>
|
|
Paresh Bhagat <[email protected]> says:
This series adds support for DM firmware reserved memory fixup in device
tree for K3 SoCs that use separate DM firmware (K3_DM_FW enabled).
The series includes:
1. Fix for phandle corruption in FDT reserved memory fixup
2. Enable OF_SYSTEM_SETUP for AM62D2 to allow device tree fixups
3. Add Kconfig options for DM firmware reserved memory for other K3 SoCs
4. Add DM reserved memory fixup implementation
The main issue being addressed is that the current reserved DDR carveout
for DM firmware in device tree is insufficient to accommodate the DM
firmware binary on AM62A7, and potentially other K3 SoCs in the future.
Currently, the size is only modified for AM62A7 SoC. For rest of SocS
existing values from device tree is taken.
For vendor boards, please verify boot and check for errors if any.
This series depends on dts update for effected devices. If "dm" node is
not found then the existing mechanism creates a new node with same
address, which cause memory overlap issue.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for fixing up DM firmware reserved memory in the kernel
device tree for K3 SoCs that use separate DM firmware.
The fixup uses the CONFIG_K3_DM_FW_RESERVED_ADDR and
CONFIG_K3_DM_FW_RESERVED_SIZE Kconfig options to update the
reserved-memory node with the correct DM firmware carveout.
Note that the fixup needs DM reserved memory node is to be renamed in
dts. Example memory@9c900000 → dm@9c900000
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
Add Kconfig options for DM firmware reserved memory for K3 SOCs that
support DM firmware (K3_DM_FW enabled)
- K3_DM_FW_RESERVED_ADDR: DM firmware address
- K3_DM_FW_RESERVED_SIZE: DM firmware reserved size
These configs will be used to fixup the kernel device tree's reserved
memory node for DM. Currently the fixup is only done for AM62A7 SoC, as
K3_DM_FW_RESERVED_SIZE is being used to update DM reserved memory from
0xf0000 to 0x1f0000 as the current reserved carveout is insufficient to
accommodate the binary.
For other platforms, the addresses and sizes are based on the existing
device tree reserved memory. If needed for other SoCs, address and size
could be modified in Kconfig.
Signed-off-by: Paresh Bhagat <[email protected]>
|
|
Enable OF_SYSTEM_SETUP for AM62D2 to ensure FDT fixups are applied to
the dtb before passing to kernel.
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
Fix phandle corruption in fdt_fixup_reserved_memory()
The original implementation used a delete/recreate approach:
- Find existing reserved memory node (e.g. tfa@80000000)
- Delete the entire node with fdt_del_node()
- Create new node with fdtdec_add_reserved_memory()
This worked fine for ATF and OPTEE nodes because no other device tree
nodes reference them via phandles but other nodes example DM are
referenced by R5 nodes.
If these nodes are deleted and recreated, it will not have any phandle
property but the nodes referencing it will still contain the old
phandle, causing initialization to fail.
Update nodes in-place instead of delete/recreate to update only the
"reg" property using fdt_setprop().
Fixes: 8b0fc29de0e3 ("arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT")
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
Acked-by: Andrew Davis <[email protected]>
|
|
With all AM62x family boards (TI EVMs, phytec phycore, toradex
verdin) now using per-security-state FIT configurations and selecting
the right one via board_fit_config_name_match(), the runtime filter
in board_fit_image_post_process() that zero'd out *p_size for the
wrong tifsstub variant is no longer reached. Only one tifsstub
variant is present in the selected FIT configuration, and it is
always the correct one for the current silicon.
Drop the filter so board_fit_image_post_process() simply debug-logs
the variant name and returns.
Acked-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
TI K3 AM62x/AM62Ax/AM62Px boards carry two or three mutually-exclusive
tifsstub variants in their tispl.bin FIT images, all at the same load
address. The existing approach loads every variant and then discards
the wrong ones at runtime via a *p_size = 0 hack in
board_fit_image_post_process(). Switch to selecting the appropriate
FIT configuration up front via board_fit_config_name_match() so only
the correct tifsstub is loaded in the first place.
board_fit_config_name_match() is invoked by the R5 SPL during FIT
config selection. get_device_type() is a simple register read that is
available at that point, so the security state can be determined
early. The matching logic is factored into
k3_fit_config_match_security_state() in arch/arm/mach-k3/common.c so
it can be shared by any K3 board that wants this scheme. It matches
configurations by a suffix appended to the description string:
-hs-se -> HS-SE (K3_DEVICE_TYPE_HS_SE)
-hs-fs -> HS-FS (K3_DEVICE_TYPE_HS_FS)
-gp -> GP (K3_DEVICE_TYPE_GP)
Configurations without a security-state suffix (e.g. u-boot.img) do
not match and fall through to the DTS-specified default config
naturally.
Each TI EVM board defines its board_fit_config_name_match() as a thin
wrapper around the shared helper:
- board/ti/am62x/evm.c (AM625 SK: hs-se, hs-fs, gp)
- board/ti/am62ax/evm.c (AM62A SK: hs-se, hs-fs, gp)
- board/ti/am62px/evm.c (AM62P SK: hs-se, hs-fs, gp)
FIT configurations are split per security state in:
- arch/arm/dts/k3-am625-sk-binman.dtsi
(ti-falcon, ti-spl, ti-spl_unsigned: conf-hs-se/conf-hs-fs/conf-gp)
- arch/arm/dts/k3-am62a-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62A)
- arch/arm/dts/k3-am62p-sk-binman.dtsi
(ti-falcon, ti-spl: conf-hs-se/conf-hs-fs; no GP variant on AM62P)
The runtime filter in board_fit_image_post_process() is intentionally
left in place. It becomes redundant once every board using the AM62x
family dtsi files migrates to per-state configurations. The dtsi for
phytec phycore and toradex verdin boards is updated by separate
patches in this series, and the now-redundant runtime filter is
removed by the final patch in the series.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
In warm reset, the value of CTRLMMR_MCU_RST_SRC was not being reset.
This leads to a reset-loop boot failure when a warm reset is triggered
from the MAIN domain (by writing 0x2006 to MCU_RST_CTRL).
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Vishal Mahaveer <[email protected]> says:
Collecting SYSFW traces from DMSC firmware is broken on the current
codebase. These changes enables MAIN_UART1 for collecting SYSFW traces
when the trace option is enabled in the boardcfg.
Link: https://lore.kernel.org/r/[email protected]
|
|
The upstream device tree changed the serial alias for MAIN UART1 from
serial3 to serial1. Update the board initialization code to match this
change by modifying the UCLASS_SERIAL sequence number lookup.
This ensures proper pin control configuration for the UART used by
system firmware (SYSFW).
Signed-off-by: Vishal Mahaveer <[email protected]>
Fixes: d2edabfa8de5 ("arm: mach-k3: am642: Load SYSFW binary and config from boot media")
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Currently the sequence to enable caches for the A53/A72 core on K3
devices looks as follows:
1. Map entire DDR banks
2. Setup page tables (done by mmu_setup)
3. Enable MMU
4. Unmap reserved-memory regions
5. Enable caches
However there is a brief period of execution between #3 and #4 where the
core can issue speculative accesses to the entire DDR space (including
the reserved-memory regions) despite the caches being disabled.
A firewall exception is triggered whenever such speculative access is
made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
by re-ordering the sequence as follows:
1. Map entire DDR banks
2. Setup page tables
3. Unmap reserved-memory regions
4. Enable MMU
5. Enable caches
Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
Reported-by: Suhaas Joshi <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Currently mmu_setup for ARMv8 performs two functions, first it sets up
the page tables based the memory map provided by the board and then it
enables the MMU.
However for some platforms runtime fixes to the generated page tables
are required before the MMU can be enabled, such as K3 family of SoCs.
Therefore this patch moves the enablement of the MMU out of mmu_setup
and to a standalone mmu_enable function to give more granular control to
the platforms.
Note that no functional changes are intended from this patch.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Udit Kumar <[email protected]> says:
Add a necessary hardware errata workaround for J721S2 and J784S4.
Bootlogs
https://gist.github.com/uditkumarti/da2a489a78d3241ecd2791c9df1c1317
Link: https://lore.kernel.org/r/[email protected]
|
|
Add the workaround proposed for J784S4 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
Link: https://www.ti.com/lit/pdf/sprz536
Signed-off-by: Neha Malcom Francis <[email protected]>
Signed-off-by: Udit Kumar <[email protected]>
|
|
Add the workaround proposed for J721S2 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
Link: https://www.ti.com/lit/pdf/sprz530
Signed-off-by: Neha Malcom Francis <[email protected]>
Signed-off-by: Udit Kumar <[email protected]>
|
|
verification
Add a helper macro to write and verify a 32-bit value to a memory-mapped
register. This is essential for hardware errata workarounds that require
confirmation that register writes have taken effect before proceeding with
initialization.
Signed-off-by: Udit Kumar <[email protected]>
|
|
Enable CONFIG_OF_UPSTREAM to receive automatic
device tree updates for the Aquila AM69.
Remove the now-obsolete device tree files:
- arch/arm/dts/k3-am69-aquila-dev.dts
- arch/arm/dts/k3-am69-aquila.dtsi
Signed-off-by: Ernest Van Hoecke <[email protected]>
Acked-by: Francesco Dolcini <[email protected]>
|
|
k3_falcon_fdt_fixup is used to perform fdt fixups at runtime in falcon
mode such as adding bootargs. Currently the function is only accessible
to the R5 SPL but could be useful for A53 SPL based falcon mode setups
as well.
Therefore this patch moves the function from r5/common.c to common.c.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The reserved memory sizes for ATF and OPTEE were hard-coded for K3
devices, this patch replaces them with a Kconfig option allowing for
easier modifications.
Acked-by: Andrew Davis <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
Reviewed-by: Manorit Chawdhry <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Siddharth Vadapalli <[email protected]> says:
This series adds PCIe endpoint boot support for the TI J784S4 SoC.
Series is based on commit f9ffeec4bdc ("board: toradex: Make A53 get RAM
size from DT in K3 boards") of the master branch of U-Boot.
PCIe Boot Logs (J784S4-EVM running Linux as Root-Complex transfers
bootloaders to another J784S4-EVM configured for PCIe Boot):
https://gist.github.com/Siddharth-Vadapalli-at-TI/2d157003818441fe79a139d0dec1058a
Link: https://lore.kernel.org/r/[email protected]
|
|
To enable PCIe boot on J784S4 SoC SERDES0 and PCIE1 should be enabled
and configured at the R5 stage. Add the required clk-data and dev-data
for SERDES0 and PCIE1.
Signed-off-by: Hrushikesh Salunke <[email protected]>
Signed-off-by: Siddharth Vadapalli <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
|
|
The PCIe Controllers in the K3 SoCs have 4 GB Address Windows in the
64-bit address space to map System (CPU) Addresses to PCIe Bus Addresses.
The physical addresses for these Address Windows across PCIe instances
across SoCs is as follows:
+--------+----------------+----------------+----------------+----------------+
| SoC | PCIe0 | PCIe1 | PCIe2 | PCIe3 |
+--------+----------------+----------------+----------------+----------------+
| AM64 | 0x6_0000_0000 | NA | NA | NA |
| J722S | 0x6_0000_0000 | NA | NA | NA |
| AM68 | NA | 0x41_0000_0000 | NA | NA |
| J7200 | NA | 0x41_0000_0000 | NA | NA |
| J721S2 | NA | 0x41_0000_0000 | NA | NA |
| J742S2 | 0x40_0000_0000 | 0x41_0000_0000 | NA | NA |
| AM69 | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
| J721E | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
| J784S4 | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
+--------+----------------+----------------+----------------+----------------+
Two regions for a 1:1 mapping from virtual addresses to physical addresses
catering to all of the above will be required, which are:
1. For AM64 and J722S SoCs
=> Start: 0x6_0000_0000 Size: 0x1_0000_0000
2. For AM68, AM69, J7200, J721E, J721S2, J742S2 and J784S4 SoCs
=> Start: 0x40_0000_0000 Size: 0x4_0000_0000
Since the 'Flash Peripherals' region from 0x5_0000_0000 to 0x8_7FFF_FFFF
includes the mapping for AM64 and J722S SoCs, only the second region
mentioned above needs to be added.
Hence, add the region to support 64-bit address space for PCIe.
Signed-off-by: Siddharth Vadapalli <[email protected]>
Fixes: 79f3e77133bd ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
|
|
spl_enable_cache()
commit ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from
end of the RAM") switched spl_enable_cache() to use gd->ram_top directly
but omitted the board_get_usable_ram_top() call that limits RAM
configuration and provides updated RAM end address per memory map
used by board and impacts subsequent allocations and reservations.
For e.g. here it impacts how high the TLB may be placed.
On Verdin AM62 (512 MiB), the raw end of RAM (0xA0000000) is inside
OP-TEE's region. board_get_usable_ram_top() in verdin-am62.c returns
0x9C000000 to keep relocations below it, but spl_enable_cache() never
called it. commit 42b3ee7fa524 ("arm: mach-k3: am62x: Enable memory
firewall support") then enforced the OP-TEE firewall, turning the silent
corruption into a hard hang.
Fix by calling board_get_usable_ram_top() after computing raw ram_top,
consistent with setup_dest_addr() in board_f.c. A weak default is
provided for boards that do not need to restrict the RAM top.
Fixes: ba20b2443c29 ("arm: mach-k3: common: Reserve video memory from end of the RAM")
Reported-by: Francesco Dolcini <[email protected]>
Link: https://lore.kernel.org/all/20260224102121.GB340942@francesco-nb/
Signed-off-by: Devarsh Thakkar <[email protected]>
Tested-by: Francesco Dolcini <[email protected]> # Verdin AM62 512MB
|
|
Update dev-data and clk-data to include wake-up I2C device for J722s.
Signed-off-by: Chintan Vankar <[email protected]>
Tested-by: Richard Genoud <[email protected]>
|
|
Moving forward, DM firmware will no longer mess with the MAIN_PLL3.
This means MAIN_PLL3 will need to be manually set to 2GHz in order for
the CPSW9G HSDIV to have the correct 250MHz output for RGMII.
Signed-off-by: Bryan Brattlof <[email protected]>
Signed-off-by: Siddharth Vadapalli <[email protected]>
|
|
device for non SPLs"
This series from Dominik Haller <[email protected]> provides a way for
TI K3 platforms to determine their boot device outside of SPL and then
adds support for the PHYTEC phyCORE-AM68x/TDA4x SoM.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for the PHYTEC phyCORE-AM68x/TDA4x (J721S2 family) SoM.
Supported features:
- 4GB LPDDR4 RAM
- eMMC
- SD-Card
- Ethernet
- OSPI
- AVS
- debug UART
Signed-off-by: Dominik Haller <[email protected]>
Reviewed-by: Wadim Egorov <[email protected]>
|
|
Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it
is booting from.
Signed-off-by: Dominik Haller <[email protected]>
|
|
With the support for common speed grade configuration added in commit
65a6b83a9b7f ("mach-k3: refactor A53 speed grade clock-rate fixup"),
this patch extends the support to AM64x SoCs.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Add initial support for the Toradex Aquila AM69 module.
The Aquila AM69 SoM is based on the TI AM69 SoC from the Jacinto 7
family and is designed for high-end embedded computing, featuring up to
32GB of LPDDR4 and 256GB eMMC storage, extensive multimedia support (3x
Quad CSI, 2x Quad DSI, DisplayPort, 5x Audio I2S/TDM), six Ethernet
interfaces (1x 1G, 4x 2.5G SGMII, 1x 10G), USB 3.2 Host/DRD support, and
a Wi-Fi 7/BT 5.3 module, alongside an RX8130 RTC, I2C EEPROM and
Temperature Sensor, and optional TPM 2.0 module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: Emanuele Ghidoli <[email protected]>
Co-developed-by: Parth Pancholi <[email protected]>
Signed-off-by: Parth Pancholi <[email protected]>
Co-developed-by: Franz Schnyder <[email protected]>
Signed-off-by: Franz Schnyder <[email protected]>
Signed-off-by: Francesco Dolcini <[email protected]>
|
|
The usage of fdt_fixup_reserved is repeated for ATF and OP-TEE for
multiple platforms, this patch creates a single fdt API for fixing up
the reserved-memory node with added error handling.
All k3 platforms already share a common tispl template which ensures
binaries are loaded as per the respective CONFIG_*_LOAD_ADDR. And the
provided new_size for the fixup is overridden by the size from fdt node
anyways. This allows for safe abstraction of the reserved memory fixups
for all current platforms.
fdt_fixup_reserved now abstracts the ATF and OP-TEE fixups by calling
the renamed static fdt_fixup_reserved_memory function with the required
parameters.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Prepare v2026.01-rc4
|
|
While adding CPSW device support to enable Ethernet boot for J722S,
dev-data and clk-data for eMMC was removed by mistake, which leads to eMMC
boot failure. Update the dev-data and clk-data to fix that.
Fixes: a02009f3a816 ("arm: mach-k3: j722s: Update SoC autogenerated data to enable Ethernet boot")
Reported-by: Michael Walle <[email protected]>
Signed-off-by: Chintan Vankar <[email protected]>
Tested-by: Michael Walle <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
|
|
Philippe Schenker <[email protected]> says:
This series fixes compilation errors when building for R5 cores and
addresses a security issue where authenticated images were not being
used correctly.
Patch 1: Cosmetic removal of duplicate code
Patches 2-3: Fix build errors caused by type mismatches between
function signatures and the types used in R5 builds.
Patches 4-5: fix a bug where ti_secure_image_post_process() relocates
images during authentication, but callers were still using the original
unverified addresses.
Patch 6: Implements is_running operation to allow querying R5F core status.
Link: https://lore.kernel.org/r/[email protected]
|
|
The ti_secure_image_check() function may relocate the image during
authentication, updating image_addr to point to the verified location.
The caller was not updated with this new address, causing it to
reference the original unverified location.
Update p_image with the verified image address after authentication
to ensure subsequent operations use the correct location.
Signed-off-by: Philippe Schenker <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
TI offers SoCs in various speed grades, each speed grade specifies a
certain maximum operating frequency of the clocks for each core.
In K3's boot flow, the R5 SPL starts the A53 or A72 core and configures
the correct clocks and power using the K3 ARM64 rproc driver
(compatible: ti,am654-rproc). However, the driver expects the dt node
for the ARM64 core to be set with a correct "assigned-clock-rates"
value.
Currently the dt has a value of 1.2GHz for the A53 core on AM62a, this
is incorrect for lower speed grades. Therefore this patch set adds
support for fixing this value at runtime based on the detected speed
grade from the efuse MMR.
For the speed grade table, refer to Table 6-1 of the AM62a datasheet.
Link: https://www.ti.com/lit/ds/symlink/am62a7.pdf
Link: https://lore.kernel.org/r/[email protected]
|
|
Speed grades indicate the maximum operating frequency of any core on the
SoC. This patch adds support for the same to AM62a, this allows the A53
core to be started with the correct frequency by the R5 SPL.
Reference:
Device Speed Grades (Table 6-1) in AM62a7 Datasheet
https://www.ti.com/lit/ds/symlink/am62a7.pdf (Page#82)
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The K3 ARM64 rproc driver uses the "assigned-clock-rates" value in the
respective "/a53@0" node to properly configure the clocks for the A53
core.
Although the clock value in the DT node might need to be fixed based on
SoC's speed grade at runtime. Certain SoCs such as AM62p and AM62x
already had this implemented, this patch moves the common code to
common.c to avoid duplication and simplify speed grade handling.
The logic to detect the correct entry in the "assigned-clock-rates"
property has also changed. Where we earlier relied on per SoC specific
device and clock IDs for the A53 core, we now use the "clock-names"
property which is device agnostic.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Aniket Limaye <[email protected]>
|
|
fdt_fixup_cpu_freq_nodes_am62p is used to delete unsupported opp table
entries at runtime based on the SoC's speed grade.
However, the ti-cpufreq driver in kernel already has support for
rejecting unsupported entries. Therefore this fdt fixup is not necessary
and can be dropped.
Fixes: 8d05cbef73ae ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade")
Signed-off-by: Anshul Dalal <[email protected]>
|
|
detection"
Guillaume La Roque (TI.com) <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Guillaume La Roque (TI.com) <[email protected]>
|
|
The bootargs are passed to the kernel in the chosen node, this patch
adds support for populating bootargs in the dtb if missing.
The values for kernel boot params is taken from the env, with 'boot' and
'bootpart' specifying the rootfs for the kernel similar to the
non-falcon boot flow.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
This patch adds fdt fixups to the kernel device-tree in R5 falcon mode,
these fixups include fixing up the core-count, reserved-memory etc.
The users can opt out by disabling the respective CONFIG_OF_*_SETUP
config options.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
To simplify the boot process and prevent the R5 SPL size from growing,
this patch restricts the boot media to load the next stage payload
(tifalcon.bin and kernel FIT) to MMC only.
We select between eMMC/SD by checking "mmcdev" in env to conform with
how U-Boot proper handles loading binaries from MMC1 or MMC2.
Note that tiboot3.bin (the initial bootloader) can be loaded from any
boot mode supported by the ROM since the restriction only applies to
tifalcon.bin and fitImage.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
We use the spl_board_prepare_for_boot hook to call k3_r5_falcon_prep
which is ran after tispl is loaded but before jump_to_image.
In k3_r5_falcon_prep, we find the boot media and load the kernel FIT
just as standard secure falcon mode (since spl_start_uboot returns 0
now). Once the kernel and args are loaded.
Now when the flow goes to jump_to_image, we do the regular pre-jump
procedure and jump to TFA which jumps to the kernel directly since we
have already loaded the kernel and dtb at their respective addresses
(PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
Overall execution for the R5 SPL after this patch:
board_init_r
|-> boot_from_devices
| +-> load_image (we load tifalcon.bin here since spl_start_uboot
| returns 1)
|
+-> spl_prepare_for_boot
| +-> k3_falcon_prep
| +-> load_image (we load fitImage here since spl_start_uboot
| returns 0 now)
|
+-> jump_to_image
Signed-off-by: Anshul Dalal <[email protected]>
|
|
mem_map_from_dram_banks calls fdtdec_setup_memory_banksize to setup the
dram banks though that is expected to be done by dram_init_banksize as
part of board_r sequence.
This has the side effect of modifying gd->bd->bi_dram as well, therefore
this patch removes the call and updates spl_enable_cache for K3 to call
dram_init_banksize.
Signed-off-by: Anshul Dalal <[email protected]>
Reported-by: Francesco Dolcini <[email protected]>
Closes: https://lore.kernel.org/u-boot/20251027165225.GA71553@francesco-nb/
Fixes: fe2647f2a0d4 ("arm: armv8: mmu: add mem_map_from_dram_banks")
Tested-by: Emanuele Ghidoli <[email protected]>
|
|
With CONFIG_SPL_OS_BOOT enabled, U-Boot checks for the return value of
spl_start_uboot to select between falcon or the regular boot flow. Where
a return value of 0 means 'boot to linux'.
This patch overrides the weak definition form common/spl/spl.c to allow
K3 devices to use falcon mode with SPL_OS_BOOT_SECURE enabled for the
A-Core SPL.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
With the memory map configuration being done dynamically, reserve extra
space during U-Boot relocation to ensure we have enough for the fixups.
Reviewed-by: Dhruva Gole <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
