TI K3 boot on an AM62A7: DMSC, TF-A, U-Boot, and four processor types in one log

One TI AM62A7 SK boot log walks through eight stages across four distinct processor types before Linux gets to execute a single instruction. DMSC firmware on the M4F security core hands off to a two-stage SBL on the R5F. The R5F wakes the A53 application cores, which run ARM Trusted Firmware, which runs U-Boot SPL, which runs U-Boot proper, which finally starts Linux at EL2. If you're coming from Cortex-A boot flows on other SoCs, K3 makes some deliberately different architectural choices: and the log makes them legible.

One naming warning up front: on AM62A the DMSC role is split across two cores (TIFS on the M4F security enclave, Device Manager on a companion R5F), but TI still calls the combined thing "DMSC firmware" in banners and docs. Where the post says DMSC generically it means both.

The full capture is at /samples/bootintel-27.txt. Board self-identifies as Texas Instruments AM62A7 SK (the SK-AM62A7 Starter Kit).

The eight stages, in order

What DMSC actually is

DMSC is the piece that has no direct equivalent on most non-TI SoCs. It's a small firmware image that runs on a dedicated security enclave physically separated from the application processors, with its own private SRAM. TI documents it as the "Device Management and Security Controller." On the older K3 devices (AM65x, J721E) DMSC is a single Cortex-M4F. On AM62A the responsibilities are split: TI Foundational Security (TIFS) runs on a Cortex-M4F security enclave, and the Device Manager (the TI-SCI server) runs on a dedicated Cortex-R5F in the wake-up domain. The single "DMSC firmware" banner in the log covers both. The banner line:

DMSC Firmware Version 9.1.8--v09.01.08 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

"Kool Koala" is the codename for the 9.x release stream of TI System Firmware. The version number is the interesting bit: DMSC firmware is on its own release cadence, independent of Linux, U-Boot, or TF-A, and vendors ship it as a signed blob loaded from boot media.

Once loaded, DMSC provides three services the rest of the SoC depends on:

• TI-SCI (System Control Interface) messages for power, clock, and reset control. When U-Boot or the Linux kernel wants to power on a peripheral or scale a PLL, it doesn't touch the hardware directly: it sends a TI-SCI message to DMSC, which does the work.
• Resource management. DMSC owns the mapping of DMA channels, interrupt aggregators, ring accelerator rings, and other shared fabric resources to specific host processors. Requests come in over TI-SCI.
• Secure boot verification. DMSC checks signatures on downstream boot images before releasing the next core from reset. Modern K3 Starter Kits typically ship as HS-FS (High-Security Field Securable) rather than GP : signature verification still runs but any key passes until customer eFuses are burned. HS-SE (High- Security Security-Enforced) variants require the customer-programmed root of trust.

Why two SBL stages

The log shows the DMSC banner twice, each time followed by a [BOOTLOADER_PROFILE] block. That's not a duplicate print: it's two distinct SBL runs on the R5F.

The first stage is small (Boot Image Size : 205 KB) and does the minimum: bring up the "mcu-r5f0-0" and "r5f0-0" cores, prove they can talk to DMSC, verify the second-stage SBL image. The second stage is larger (Boot Image Size : 1178 KB) and does the rest: bring up the HSM M4F, the A53 application cores, and the C7x DSP subsystem. In the log the cores-present list expands from two entries to four across the two stages:

# First SBL:
[BOOTLOADER_PROFILE] Cores present    :
mcu-r5f0-0
r5f0-0

# Second SBL:
[BOOTLOADER_PROFILE] Cores present    :
hsm-m4f0-0
r5f0-0
a530-0
c75ss0

The pattern is the same "cascading trust" idea that appears on any secure-boot chain: a small, minimally featured loader verifies the next larger loader, which verifies the payload after that. On K3 the split lives on the R5F rather than in ROM, which is unusual when comparing to i.MX or Snapdragon flows.

ARM Trusted Firmware: the BL31 stage

Once the A53s come up, they don't jump straight to U-Boot. First they run TF-A's BL31 stage:

NOTICE:  BL31: v2.9(release):v2.9.0-614-gd7a7135d32-dirty
NOTICE:  BL31: Built : 09:34:15, Aug 24 2023

ARM Trusted Firmware is the reference implementation of the EL3 secure monitor. TF-A defines a chain of Boot Loader stages: on K3, only BL31 and BL33 appear as standalone stages; the others are rolled into earlier pieces. For reference:

• BL1: the ROM code.
• BL2: trusted boot firmware, loads BL31/32/33.
• BL31: EL3 runtime. Handles PSCI (Power State Coordination Interface) calls for CPU on/off/suspend and dispatches to BL32.
• BL32: optional secure payload (OP-TEE or vendor equivalent).
• BL33: the non-secure world's boot payload: on K3 that's U-Boot SPL.

On K3, BL1 and BL2 are effectively rolled into the R5F SBL stages above: the SBL is what loads and jumps to BL31. Once BL31 is resident, it stays at EL3 for the life of the system, exactly analogous to how OpenSBI stays at M-mode on RISC-V (see the RISC-V lifecycle post). The subsequent stages all run at EL2 or below; anything that needs an EL3 service issues an SMC instruction into BL31.

U-Boot SPL and U-Boot proper

U-Boot SPL 2023.04-gb0d717b732 (Dec 06 2023 - 15:11:45 +0000)
…
U-Boot 2023.04-gb0d717b732 (Dec 06 2023 - 15:11:45 +0000)
SoC:   AM62AX SR1.0 HS-FS
Model: Texas Instruments AM62A7 SK

Same base tag on both SPL and full U-Boot, same build timestamp, both from the same Yocto build (gb0d717b732). SPL enumerates the boot media, loads full U-Boot, and jumps to it. Nothing K3-specific about the transition from this point on: it's standard U-Boot.

Two details in the SoC: line are worth naming. SR1.0 is the silicon revision: DMSC ABI compatibility windows are tied to silicon rev, so a customer board on SR2.0 won't necessarily accept the same DMSC firmware image. HS-FS means "High-Security Field-Securable": the OTP keys have not been burned yet, so this silicon will still accept unsigned or vendor-test-signed images. That's expected on a Starter Kit; on a production board still shipping HS-FS it would be the flag that OTP provisioning never happened.

Cores present

The second-stage SBL profile lists four core types the SoC makes available. What each is for:

• hsm-m4f0-0: the security-enclave Cortex-M4F. On AM62A this is where TIFS runs: the security half of what TI collectively calls DMSC. On HS-SE devices it owns key material and signature verification.
• r5f0-0: Cortex-R5F, TI's real-time coprocessor. In production it runs a customer real-time application (motor control, PLC logic, safety monitor). At boot it also happens to be where the SBL runs before A53 wake-up.
• a530-0: the four Cortex-A53 application cores that will run Linux. Named as one entry in the SBL log because the SBL only kicks off the primary; the rest get brought online later via PSCI.
• c75ss0: C7000 series DSP subsystem. On AM62A this is the DSP + Matrix Multiply Accelerator combination TI markets for edge-AI inference. Optional to bring up.

So one SoC has four architecturally distinct processor classes on it, plus the DMSC M4F that isn't in the "cores present" list at all because DMSC owns itself. Reading a K3 boot log for the first time, this is the part that looks strangest coming from a "single-cluster A53" SoC.

Boot timing

Each SBL run reports a full timing breakdown. The headline numbers from this capture:

# First SBL (line 18):
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     150980us

# Second SBL (line 44):
[BOOTLOADER_PROFILE] SBL Total Time Taken             :     146374us

~300 ms of SBL work between DMSC and TF-A. On top of that you get whatever U-Boot takes to enumerate MMC and PCIe, plus the Linux boot itself. Total time-to-userspace on the eMMC path for a stock AM62A7 SK boot lands somewhere between 4 and 8 seconds depending on rootfs contents.

Kernel handoff and EL2

Starting kernel ...
[    0.000000] Linux version 6.1.46-g247b2535b2 (…) aarch64-oe-linux-gcc …
…
[    0.210811] CPU: All CPU(s) started at EL2

The started at EL2 line matters: on ARMv8, Linux can run at either EL1 (traditional kernel privilege) or EL2 (hypervisor). U-Boot's armv8_switch_to_el1 function chooses. Booting at EL2 means KVM can be enabled without additional setup and any hypervisor-only registers (ID_AA64MMFR* etc.) are directly accessible. On a headless AM62A that's often what you want; on a locked-down appliance you'd configure U-Boot to drop to EL1 instead.

How this compares to RISC-V and other ARM SoCs

The high-order bit: K3 puts the persistent root of trust on a separate physical core that never runs Linux. That's stronger than the OpenSBI-on-the-application-cores model on RISC-V, and stronger than TrustZone-on-the-application-cores on a generic ARM SoC. The trade is complexity: five firmware streams to keep updated (DMSC, HSM firmware, R5F SBL, TF-A, U-Boot) instead of two.

What to check on your own AM62A / K3 device

1. DMSC version. "Kool Koala" is the 9.x train (September 2023-ish for 9.1.8); TI publishes a matrix of DMSC versions per silicon revision at software-dl.ti.com/tisci. If your board is running an older codename you're missing DMSC-side fixes.
2. TF-A version. Log line above shows v2.9.0-614-gd7a7135d32-dirty. TF-A is released quarterly; anything more than two releases behind current should be checked against the TF-A security advisories.
3. Kernel EL. started at EL2 vs. EL1 tells you whether KVM is available. It also tells you whether U-Boot's CONFIG_ARMV8_SWITCH_TO_EL1 flag is set, which is a defense-in-depth control on locked-down appliances.
4. Whether there's an interruptable autoboot prompt in U-Boot proper. AM62A7 SK reference builds ship with one enabled by default.

Related

• RISC-V bootloader lifecycle: the same problem (multi-stage firmware, root of trust, ABIs into the kernel) with a different vendor's naming and different privilege model.
• Interruptable autoboot: AM62A7 SK reference U-Boot ships with the countdown by default; same mitigation (CONFIG_BOOTDELAY=-2) applies.
• UART adapters worth owning: the AM62A7 SK MAIN UART is 3.3 V and 115200 8N1 by default; any of the three adapters covered there works.
• Device Fingerprinter : paste the boot log, get bootloader stages called out inline. Client-side, no upload.
• Managing a fleet of K3-family boards and want DMSC / TF-A / U-Boot version drift tracked automatically instead of by spreadsheet? BootIntel's paid tiers hold per-device history and diff firmware versions across fleet snapshots.