Hi,

Commit 684952d17275 ("feat(scmi): add support for discovering and changing parent clocks") first introduced with TF-A v2.14 breaks the barebox bootloader on a STM32MP157-based MC-1 with SCMI clocks over SMC.

The breakage for SCMI consumers is acknowledged in the Gerrit discussion[1], but unfortunately the resolution was limited to patching U-Boot[2].

I find this approach problematic, because it introduces a compatibility break for the whole SCMI ecosystem, e.g. following software is made incompatible with the newest TF-A this way:

- Linux v6.6 and earlier (that's four official LTS releases) - U-Boot v2025.10 and earlier (only one newer release compatible) - barebox v2026.03.1 and earlier (no compatible releases yet)

Firmware and kernel, and to a lesser degree firmware and bootloaders, are not always updated or rolled back in lockstep. A very normal scenario:

- System with Linux v6.6 updates to newer LTS, e.g. v6.12 or v6.18 - In the same update, TF-A v2.14 is installed - New system fails to function for whatever reason - Kernel update is rolled back, but bootloader/firmware stays the same - Kernel v6.6 fails to boot with TF-A v2.14 - Technician moves out to unbrick device in the field

At the very least, marking this feature a breaking change would have been appropriate. Preferably, TF-A would handle existing consumers using SCMI clock v3.0. I haven't looked into the technical feasibility myself and I am unsure it this had been considered.

I will submit patches for the barebox bootloader, but these only solve the problem for new systems or ones where everything can be flashed at once with no rollback. Systems out in the field are at risk of bricking if not resolved properly.

[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/34226 [2]: https://lore.kernel.org/u-boot/20251104-b4-scmi-v1-v4-0-51f101a6f8c3@ti.com/

Thanks, Ahmad