ARM Boot Flow: Artifact and Address Mapping from ROM to PID 1

Welcome. This module moves from the bootable minimal systems you will build later into the machinery that makes an ARM Linux platform reachable at all. The immediate objective is not to memorize a vendor-specific boot sequence. It is to learn to create two debugging artifacts that remain useful across boards:

1. a boot-artifact map, showing which binary or filesystem component owns each stage of execution; and
2. an address map, showing where each component is stored, loaded, executed, and handed off.

For an automotive or industrial gateway, these maps are foundational engineering evidence. They prevent a common class of bring-up failures: a boot artifact may be valid by itself, yet fail because it was loaded at the wrong address, overwrote a live component, was paired with the wrong DTB, or led Linux to the wrong root filesystem.

Think in artifacts, not simply “the bootloader”

A Linux boot is not one program calling another in the ordinary application sense. Each stage establishes just enough hardware and memory state for a later stage, then transfers control. The earlier stage is often no longer usable after that transfer, and its RAM can sometimes be reused.

At a high level, a conventional ARM Linux boot contains these responsibilities:

TPL is optional. It appears on platforms where even the normal SPL does not fit in usable on-chip SRAM or where a vendor’s boot design needs an additional miniature stage. Do not add it to a map merely because U-Boot supports it. Record it only if the board’s actual boot artifacts include it.

The architecture becomes more interesting on multicore SoCs such as TI K3 AM62x. One processor domain can provide security, power, clock, and resource-management services while the Cortex-A53 cluster ultimately runs U-Boot and Linux. Therefore, a good map identifies which processor executes each artifact, not only the artifact filename.

A useful discipline is to separate four ideas that documentation often conflates under the word address:

These may coincide, but they do not have to. In particular:

• U-Boot Proper may be loaded at one physical address and relocate itself before operating normally.
• The kernel image may be loaded to one physical region, then establish page tables and execute in a kernel virtual-address region.
• A FIT image is a container held in RAM; its kernel, DTB, and optional initramfs members have their own metadata and effective placements.
• A block root filesystem normally has a storage location, but it is not copied as one contiguous RAM object. The kernel mounts it and reads file pages as needed.
• An initramfs is different: it is supplied as an archive in memory, then unpacked by the kernel into an in-memory root filesystem.

The AM62x example: processors, firmware, and named boot artifacts

The following AM62x diagram is useful because it shows that boot is coordinated across processor domains. The security-management subsystem begins with Secure ROM; TI Foundational Security firmware provides critical services; the R5 device-management domain participates in loading and system control; and the A53 cluster reaches TF-A, SPL, U-Boot, and finally Linux.

On the AM62x platform, three externally visible boot files are central to the normal TI U-Boot flow:

• tiboot3.bin
• tispl.bin
• u-boot.img

Those filenames are not generic U-Boot names. They describe a TI K3 packaging and staging design. A map that writes only “SPL” and “U-Boot” loses important information, because it cannot tell an engineer which file to inspect, replace, sign, or locate on the boot medium.

A practical AM62x boot-artifact map

The table below is a reasoning map, not a flash layout that should be copied blindly onto a board. It tracks ownership and handoff responsibilities. Exact packaging differs with device lifecycle, boot medium, SDK release, secure-boot configuration, and whether features such as OP-TEE are enabled.

Two distinctions in this table matter for later secure-boot and OTA design:

1. A filename is not necessarily an execution image. tispl.bin, for example, is a boot package that can contain several components needed at that stage.
2. The boot medium is not necessarily the root filesystem. A board may load early artifacts from an eMMC boot partition but mount its root filesystem from the eMMC user area, NVMe, SD card, or network storage. An A/B update design later makes these choices explicit.

Building the address map without creating false confidence

An address map is not a list of hexadecimal numbers. It is a claim about which memory ranges are simultaneously occupied. To make that claim safely, record each artifact’s:

• storage source;
• physical load address;
• entry address;
• expected size;
• whether it remains resident after handoff;
• relocation destination, if applicable;
• reserved-memory or secure-memory constraints;
• lifetime during the boot sequence.

Represent a memory region for artifact $i$ as:

where $A_i$ is its physical start address and $S_i$ is its loaded size. For two artifacts that must coexist in RAM, the required condition is:

A map that contains only start addresses cannot establish this condition. A kernel loaded at a seemingly sensible address can still overwrite a DTB, an initramfs, OP-TEE, U-Boot’s relocation region, or a DMA buffer if its actual size is not considered.

AM62x reference addresses and their limits

TI’s AM62x documentation provides a valuable set of default load locations. They are configuration data, not an architectural guarantee for every board:

There is an intentional-looking tension in the supplied documentation: the AM62x A53 SPL layout places SPL text at 0x80080000, while the TF-A documentation lists 0x80080000 as the default U-Boot/Linux image location. This is precisely why a temporal boot map is essential.

These uses can be valid if they occur in different lifetimes. SPL text can occupy a region during the early DDR-init phase, then later be overwritten after it has handed control to a stage that no longer needs the SPL code. They would be invalid if both artifacts had to remain alive there simultaneously.

The A53 SPL layout is more detailed than a typical high-level boot diagram:

The listed layout has gaps. Do not assume every gap is automatically safe for a kernel, DTB, or initramfs. Some may be reserved by the board configuration, display handoff, firmware, U-Boot relocation policy, device tree reserved-memory nodes, or an updated SDK.

A complete map for a normal Linux boot

The following format is suitable for a design document, bring-up notebook, or repository artifact. The entries shown as discover from board build must come from your particular U-Boot configuration, FIT image, generated DTB, and serial log.

The kernel handoff boundary

By the time U-Boot transfers control to Linux, it must have selected a compatible combination of:

• a kernel image;
• a DTB matching the actual board and enabled hardware;
• an optional initramfs;
• kernel command-line arguments;
• a root filesystem source, unless the initramfs itself is the intended root.

For ARM64, the essential conceptual handoff is that the kernel receives the physical address of the flattened device tree in register x0. The DTB is not just an inventory of peripherals. It also commonly carries /chosen/bootargs, memory descriptions, reserved-memory regions, and references that determine which hardware drivers can safely initialize.

A mismatch can produce distinctive failures:

A FIT image helps keep compatible artifacts together. It can package a kernel, one or more DTBs, an initramfs, hashes, and signatures. However, it does not eliminate address planning. The FIT itself occupies RAM while U-Boot inspects it, and its component metadata must still be consistent with reserved regions and the boot command used.

How to validate the map on real hardware

When you begin using the AM62x board, treat serial output as primary evidence. Copy the complete power-on boot log into the private implementation repository and extract only non-sensitive, sanitized excerpts for the public showcase.

At the U-Boot prompt, the most useful evidence will usually include:

bdinfo
env print bootcmd bootargs
env print loadaddr fdtaddr fdt_addr_r kernel_addr_r ramdisk_addr_r

Variable names differ among U-Boot configurations. The purpose is not to expect every variable above, but to discover the addresses and boot policy that the installed configuration actually uses.

For a FIT-based boot flow, U-Boot commands such as iminfo can expose image metadata. For a separate DTB, U-Boot’s fdt commands can identify the DTB currently selected in RAM. Later, once Linux reaches userspace, these commands help close the evidence chain:

cat /proc/cmdline
mount
ps -p 1 -o pid,comm,args
dmesg

Together, these answers establish:

• what command line the kernel received;
• which root filesystem actually mounted;
• what program became PID 1;
• whether the kernel detected the intended memory, storage, and device-tree configuration.

For the portfolio repository, a strong public artifact is a sanitized docs/boot-artifact-map.md containing:

• a stage-and-responsibility table;
• a memory map with documented source references;
• a boot-media layout diagram without credentials or signing material;
• sanitized serial-log excerpts;
• assumptions and configuration revision identifiers.

Keep exact production flash offsets, signing configuration, certificates, key identifiers, and provisioning notes in the private repository. The public version should demonstrate the method and the engineering decisions without disclosing security-sensitive implementation details.

Key takeaways

A reliable ARM boot map records more than a familiar sequence of names:

• Boot ROM is immutable, boot-source aware, and constrained; it starts the mutable boot chain but does not replace it.
• TPL and SPL exist to solve the pre-DRAM problem. On AM62x, the staged flow spans security, R5/device-management, and A53 domains.
• The AM62x normal boot artifacts are named tiboot3.bin, tispl.bin, and u-boot.img; these names should appear in a board-specific map.
• Storage offsets, load addresses, entry addresses, and runtime addresses are different facts.
• Address safety depends on both range size and lifetime. Reusing an address can be legitimate after handoff, but overlapping live regions is a boot failure.
• A block root filesystem is mounted, not loaded as one RAM binary; the kernel starts PID 1 from that filesystem or from an initramfs-based root.
• Serial logs, U-Boot environment data, FIT metadata, linker settings, DTB reserved-memory nodes, and Linux runtime evidence together turn a diagram into an auditable map.

Next, you will move inside the bootloader itself: locating temporary stack setup, board_init_f, DDR initialization, relocation, and board_init_r in U-Boot startup code.