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:

Stage	Typical owner	Main responsibility	Why the next stage is needed
Boot ROM	SoC vendor, immutable silicon ROM	Samples boot configuration, selects a boot source, loads an initial artifact, and may authenticate it	ROM is deliberately small and cannot contain board-specific DRAM training, storage policy, or interactive recovery features
TPL, if present	Board bootloader build	Performs the absolute minimum initialization when SRAM constraints are extreme	Makes room for an SPL-sized stage
SPL	Usually a reduced U-Boot build	Initializes clocks, pin multiplexing, PMIC interfaces, and external DRAM; loads larger firmware	It is small enough to run before normal DRAM is available
U-Boot Proper	Full U-Boot	Initializes richer peripherals, interprets boot policy, loads kernel artifacts, and can offer a console	It has enough space for drivers, filesystems, networking, scripts, and diagnostics
Linux kernel	Linux	Establishes kernel virtual memory, drivers, scheduling, VFS, and mounts a root filesystem	Kernel initialization creates the environment in which user processes can run
PID 1	/sbin/init, BusyBox init, or systemd	Starts userspace services and establishes the operational system	This becomes the top-level userspace supervisor

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:

Address or location	Meaning	Example question
Storage location	Persistent location on SD, eMMC, OSPI NOR, NAND, or network server	Which partition, filename, or flash offset contains tispl.bin?
Load address	RAM destination selected while copying an artifact from storage	Where does U-Boot place the DTB before launching Linux?
Entry address	Address at which a CPU begins executing an image	Which address does the handoff jump to after a successful load?
Runtime address	Address used while code is executing, sometimes after relocation or virtual-memory translation	Where does relocated U-Boot execute? At what virtual address does Linux run?

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.

Boot phase	Persistent artifact or resident firmware	Executing processor domain	Typical working memory	Main action and handoff
Reset and bootstrap	On-chip Boot ROM	Security-management domain	Immutable ROM plus limited internal memory	Samples boot-mode configuration, establishes minimal state, selects a boot source, and obtains the first vendor-defined boot artifact
Security and device management	TIFS and device-management firmware	Security enclave and device-management MCU domain	Protected or MCU-local memory	Provides security, clock, power, resource, and device-management services requested by later software
First mutable boot artifact	tiboot3.bin	Typically the K3 R5 boot path	R5-accessible execution memory	Continues early platform bring-up and obtains the next packaged stage
A53 early loader	tispl.bin, containing the relevant A53 SPL and associated firmware payloads	Cortex-A53	Initially constrained execution context, then DDR after initialization	Performs the A53-side low-level work required before full U-Boot can operate
Secure monitor, when used	TF-A, commonly its BL31 component	Cortex-A53 at EL3	Reserved secure/runtime region	Establishes secure-monitor behavior and coordinates transition to secure-world and non-secure-world software
Secure OS, when used	OP-TEE, commonly BL32	Cortex-A53 secure world	Reserved secure DRAM	Provides Trusted Execution Environment services while Linux runs non-securely
Full boot manager	u-boot.img	Cortex-A53 non-secure world	DDR, often after self-relocation	Selects boot targets, loads Linux boot artifacts, sets boot arguments, and transfers control to the kernel
Linux boot set	Image, DTB, optionally initramfs; often bundled as fitImage	Cortex-A53 non-secure world	DDR load regions specified by U-Boot and image metadata	Kernel receives the DTB and optional initramfs, initializes the OS, and mounts its root filesystem
Operational userspace	Root filesystem plus its /sbin/init or equivalent	Linux-scheduled processes on A53	Kernel-managed page cache and user virtual memory	Kernel starts PID 1, which starts the product’s service model

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:

$$R_i=[A_i,A_i+S_i)$$

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:

$$R_i\cap R_j=\varnothing$$

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:

Component documented by TI	Default load location	Interpretation for your map
TF-A image	0x70000000	Record as a protected/resident firmware region in the applicable configuration
OP-TEE image	0x9e800000	Treat as reserved secure-world memory; Linux and U-Boot payload placement must respect it
U-Boot or Linux image	0x80080000	A documented default input/load base whose actual owner depends on boot phase and configuration
DTB	0x82000000	A documented DTB placement that must be checked against kernel size and other simultaneous objects

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:

A53 SPL DDR region	Address range	Why it belongs in the address map
Empty lower region	0x80000000 to 0x80080000	Shows the boundary before SPL text
SPL text	0x80080000 to 0x800d8000	Code currently executing in this phase
Bitmap image area	0x80200000 to 0x80b77660	Demonstrates that non-code payloads may reserve significant RAM
Stack	0x80b77660 to 0x80b77e60	Must never be overwritten during SPL execution
Global data	0x80b77e60 to 0x80b78000	Holds U-Boot SPL state
SPL malloc area	0x80b78000 to 0x80b80000	Temporary allocator region
BSS	0x80c80000 to 0x80d00000	Zero-initialized SPL data
Blobs	0x80d00000 to 0x80d00400	Small payload region recorded by the platform layout

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.

Item	Storage location	Physical load / execution location	Lifetime	Evidence to record
Boot ROM	On-chip immutable ROM	SoC-defined ROM address space	From reset until first transfer	SoC technical reference manual and boot-mode configuration
tiboot3.bin	ROM-selected boot device location	Device-specific R5 execution context	Early boot	Boot medium layout, ROM log, TI image-build output
TIFS	Packaged by TI boot flow	Security enclave memory	Remains active while platform runs	Firmware version, boot log, vendor documentation
Device-management firmware	Packaged stage, configuration-dependent	R5 or dedicated management MCU memory	Typically remains active	Firmware version and platform boot diagram
A53 SPL in tispl.bin	Boot medium file or offset	Early A53 DDR/SRAM layout	Until it loads full U-Boot	SPL linker configuration and boot log
TF-A	Packaged with A53 boot artifacts	Default reference: 0x70000000	Resident EL3 monitor	TF-A build configuration and reserved-memory entries
OP-TEE, if enabled	Packaged with A53 boot artifacts	Default reference: 0x9e800000	Resident secure OS	OP-TEE configuration and DTB reserved memory
U-Boot Proper	u-boot.img	Load address plus later relocation address	Active until kernel transfer; may leave data reserved	U-Boot bdinfo, linker configuration, serial log
Kernel Image or FIT member	FAT/ext4 boot partition, flash area, TFTP, or other boot target	U-Boot-selected RAM address; then kernel runtime mappings	Kernel survives for system lifetime	FIT metadata, U-Boot environment, boot log
Board DTB	Separate file or FIT member	U-Boot-selected RAM address; TI reference default 0x82000000	Must remain accessible through early kernel parsing	FIT metadata, U-Boot environment, /proc/device-tree
Initramfs, if used	Embedded in kernel or supplied separately/FIT member	RAM archive, later unpacked	Early root filesystem phase; may be discarded after switch_root	FIT metadata, kernel command line, boot log
Root filesystem	Block partition, network root, or initramfs	No fixed whole-filesystem RAM address for block-backed rootfs	Mounted through VFS	Kernel root= arguments, /etc/fstab, mount output
PID 1 executable	Root filesystem or initramfs	Linux user virtual memory	Process lifetime, normally until shutdown	ps, service manager logs, rootfs contents

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:

Symptom	Likely mapping or handoff issue
U-Boot resets or hangs immediately after loading an image	Load address overwrote U-Boot’s live stack, relocation area, or another required firmware object
Kernel starts but stops before console output	Incorrect console configuration, bad DTB, or early memory conflict
Kernel reports an inaccessible root device	Wrong root= argument, missing storage driver, incorrect DTB, or invalid partition reference
No working init found	Rootfs mounted but lacks a valid init program, its dynamic loader, or required libraries
Kernel boots but a peripheral is absent	Wrong DTB, missing pinctrl/clock/interrupt data, or a U-Boot DTB modification issue
Secure-world or firmware failure during early boot	A protected region was overwritten, or firmware packaging and addresses disagree

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.