Merge patch series "arm: k3: replace tifsstub runtime filter with per-state FIT configurations"

Aristo Chen <[email protected]> says:

The AM62x family (TI EVMs, phytec phycore, toradex verdin) ships
two or three mutually-exclusive tifsstub variants per tispl.bin FIT
image (tifsstub-hs, tifsstub-fs, tifsstub-gp), all assigned the same
load address 0x9dc00000. The current platform code loads every
variant and discards the wrong ones at runtime by zeroing *p_size in
board_fit_image_post_process() (arch/arm/mach-k3/r5/common.c).

This runtime-filter approach has become a friction point. An earlier
attempt to add FIT-image load-address overlap detection to mkimage
flagged the shared 0x9dc00000 as an apparent conflict, and the
workaround in that series was to shift each tifsstub by 64KB
increments. Bryan Brattlof reviewed that change at the time [1] and
pointed out that the real semantics are "load one of three at
runtime", and that moving the binaries was not necessarily safe given
downstream IPC assumptions about the fixed load address. The series
was ultimately reverted upstream, which leaves the underlying
question open: any future static FIT validator needs a way to
understand that these three images do not actually collide. The same
point is being discussed at the spec level in flat-image-tree issue
#32 [2], where a "mutually-exclusive-group" property has been floated
to express runtime-resolved overlaps to static tooling.

This series fixes the problem structurally without moving any
binaries and without a spec extension. Each board's binman dtsi is
updated so the tispl.bin FIT carries one configuration per security
state (conf-hs-se, conf-hs-fs, conf-gp), each containing only the
matching tifsstub. board_fit_config_name_match() in each affected
board reads the SoC security state via get_device_type() and selects
the correct configuration up front, via a shared helper
k3_fit_config_match_security_state() added in arch/arm/mach-k3/
common.c. Each FIT configuration ends up with exactly one tifsstub at
0x9dc00000, so the overlap goes away from any static validator's
perspective and no platform-specific runtime knowledge is needed to
pick the right firmware.

Series ordering is intentional and bisectable. Patch 1 introduces
the helper, migrates the TI EVMs, and leaves the runtime filter in
place. Phytec phycore and toradex verdin boards still use their old
single-config dtsi at this point, and the runtime filter continues
to do the right thing for them in the meantime. Patch 2 migrates the
phytec phycore-am62 SoMs. Patch 3 migrates the toradex Verdin AM62
modules; their previous board_fit_config_name_match() returned 0
unconditionally, which after the dtsi split would have selected the
first listed configuration regardless of silicon and broken HS-SE
parts, so this patch is also a latent-bug fix on top of the migration.
Patch 4 drops the now-dead runtime filter.

Changes since v1, all addressing review feedback from Anshul Dalal:

  1. Patch 1: use strncmp() in k3_fit_config_match_security_state()
     instead of strcmp() with a redundant ternary, since the suffix
     length is already known.

  2. Patches 1, 2 and 3: drop the CONFIG_SPL_LOAD_FIT #if guard
     around board_fit_config_name_match() on the TI EVM, phycore
     and verdin boards. SPL_LOAD_FIT is always selected on ARCH_K3
     and LTO drops the function in any build that does not use it.

  3. The move of enum k3_device_type and get_device_type() from
     arch/arm/mach-k3/common.h to arch/arm/mach-k3/include/mach/
     hardware.h in patch 1 is kept as-is. common.h is currently
     mach-k3-internal and is not in the include search path for
     board files; making it public would be a larger refactor that
     Anshul has offered to take on separately [3].

Patch 4 is unchanged from v1; Acked-by from Neha Malcom Francis and
Reviewed-by from Anshul Dalal collected on v1 are carried forward.

Patch 1 has small non-behavioral changes vs v1, so v1 tags from
Alexander Sverdlin (Reviewed-by), Neha Malcom Francis (Acked-by),
and Akashdeep Kaur (Tested-by) are not carried forward and are
pending re-confirmation against v2.

Boot tested on AM625 SK GP silicon end-to-end through TFA, OP-TEE,
A53 SPL, U-Boot proper, and Linux 6.5. The two "Skipping
authentication on GP device" messages in the SPL banner confirm only
the GP tifsstub variant is present in the selected FIT
configuration; loading any HS variant on GP silicon would fail TIFS
authentication before reaching that point. Building (R5 SPL + A53
SPL + U-Boot proper) was verified clean against v2 on am62x_evm,
phycore_am62x, and verdin-am62 defconfigs.

Akashdeep Kaur tested v1 on AM62PX HS-FS and AM62X HS-SE devices,
including deep-sleep suspend/resume. v2 changes are non-behavioral
so the same code paths exercise as v1, but explicit re-test on v2
would be welcome.

[1] https://lore.kernel.org/u-boot/[email protected]/
[2] https://github.com/open-source-firmware/flat-image-tree/issues/32
[3] https://lore.kernel.org/u-boot/[email protected]/

Link: https://lore.kernel.org/r/[email protected]

0 files changed, 0 insertions, 0 deletions