Reset-to-DRAM Boot Sequence Diagram

Welcome back. In the previous lesson, you learned to distinguish the SoC, its internal SRAM, external DDR, nonvolatile boot media, PMIC, and memory-mapped controllers. The key constraint was that eMMC or OSPI can store a boot image, but a processor needs usable memory and a minimal hardware environment before it can execute a substantial bootloader.

This lesson turns that static hardware picture into a time-ordered engineering model. By the end, you will be able to produce a reset-to-DRAM sequence diagram for an AM62x-class board, accurately separating electrical preconditions from Boot ROM and SPL software actions. This becomes the reference timeline for later U-Boot, device-tree, secure-boot, and board-bring-up work.

---

Reset release is a controlled event, not the start of power

A common but misleading mental model is: “power arrives, then the CPU starts.” On an application processor board, the processor must remain held in reset while several dependencies become valid:

• the PMIC or regulator network establishes the required voltage rails;
• the reference clock source begins oscillating and stabilizes;
• boot-mode input levels are held at valid logic levels;
• the reset supervisor or PMIC verifies the required conditions and releases cold reset.

The supplied OSD62x-PM diagram is useful for seeing why “power” is plural. A board-level input is converted into several rails, and those rails feed both the processor and supporting devices. It is a power-distribution diagram, however, not a timing diagram and not an AM62x SK schematic. Do not infer an exact AM62x rail order or voltage from it.

For the AM62x family, think in terms of two linked phases:

Phase	Primary owner	What must become true
Electrical qualification	PMIC, regulators, oscillator, reset circuitry, board strap resistors	Supplies and clock are stable; cold reset remains asserted; boot straps are stable.
Silicon initialization	Boot ROM, security subsystem firmware, MCU R5 ROM/SPL	Boot source is selected, minimal clocks and boot interface are configured, boot images are loaded, and DDR becomes usable.

The distinction matters in diagnosis. A PMIC sequencing fault, a missing reference clock, and an incorrect boot strap can prevent Boot ROM from reaching the first programmable boot stage. At that point, altering U-Boot code cannot solve the problem.

---

Cold reset, strapping pins, and clock assumptions

On a K3-family processor, a cold reset establishes a known initial hardware state. For this lesson, treat MCU_PORz as the externally controlled cold-reset input: while it is asserted low, the board is still in its power-on qualification period.

The reset should not be released merely because a nominal supply voltage appears present. The processor needs its rails within specification and its clock source stable. With a crystal, the oscillator has a start-up interval; with an external oscillator, the clock output must already be stable. TI’s board-design guidance requires reset to remain asserted through these conditions.

The same cold-reset boundary is also where hardware boot straps become meaningful. Pull-up and pull-down resistors impose fixed logic levels on BOOTMODE pins. At cold-reset release, the SoC samples and latches those levels into a device-status register. Boot ROM subsequently uses the latched value rather than repeatedly reading live pin levels.

This has three practical consequences:

1. The boot-mode resistor network is executable configuration.
   It is as consequential to boot behaviour as a bootloader configuration file, but it is fixed in hardware unless the board provides jumpers, switches, or controlled external drivers.

2. Boot straps must be stable before reset release.
   A floating input, unsuitable pull resistance, or an external device driving the line at the wrong moment can select an unexpected boot source or clock configuration.

3. A warm reset is not a substitute for a new boot-strap sample.
   When investigating boot-source selection, explicitly identify whether the test performs a genuine cold reset or power cycle. Do not assume that changing a strap during runtime changes the current boot decision.

On TI devices covered by the board guidance, some boot-mode bits also tell ROM which reference-clock configuration it should expect for PLL setup. An incorrect clock-related strap can therefore produce failures that look like unstable execution, unexpected resets, or inaccessible peripherals rather than an obvious “clock configuration error.”

The exact boot-pin encodings and reset timing for your eventual AM62x board must come from that device’s data sheet, TRM, schematic, and board design files. The following TI guidance is valuable for the mechanism and design discipline, but never copy a specific pin encoding from a neighboring AM62-family variant without checking the AM625-specific documentation.

---

The AM62x-class path from ROM to SRAM-resident SPL

Once cold reset is released, the Boot ROM is the first immutable code involved in the boot path. ROM exists inside the silicon and is available before external DDR works. Its purpose is deliberately narrow: establish enough platform state to select and access a boot source, obtain the next boot artifact, apply the platform’s authentication policy where enabled, and hand off.

Boot ROM does not provide a full Linux environment. It does not need full Ethernet, a mounted filesystem, application drivers, or all peripheral clocks. It configures only the minimum needed for the selected boot path and early handoff.

For an AM62x K3-style boot chain, the early boot flow is more specific than the generic “CPU ROM loads U-Boot” story:

• K3 Boot ROM support begins through the MCU-domain R5 path.
• ROM obtains the first boot artifact, conventionally tiboot3.bin in TI’s U-Boot packaging.
• The chain establishes the system-firmware relationship with TIFS, TI’s security and system-management subsystem.
• The compact R5 SPL executes using constrained on-chip memory.
• R5 SPL performs DDR initialization and loads the larger next-stage artifact, commonly tispl.bin.
• Only after DDR is usable can later stages load and execute comfortably from large external memory.

The names are platform-specific; the underlying architectural pattern is broadly useful:

Generic role	Typical AM62x K3 form	Why it exists
Immutable stage	Boot ROM	Finds and validates the first executable stage using fixed silicon logic.
Constrained first-stage loader	R5 ROM and R5 SPL	Runs before external DRAM, initializes board-critical resources.
System/security management	TIFS and device-management firmware	Provides platform-controlled security, power, clock, and resource-management services.
Larger bootloader stages	A53 SPL, TF-A or OP-TEE where configured, U-Boot Proper	Run after sufficient memory is available and prepare the operating-system handoff.

The first programmable loader has a hard memory budget. TI’s AM62x material describes roughly 256 KB of internal SRAM for this early loader context. That is why early-stage code avoids large features: every byte of executable code, initialized data, BSS, stack, heap, logging, and temporary buffer competes for scarce SRAM.

A short visual explanation can help reinforce the reason for the staged design: internal SRAM is enough for a tightly scoped loader, but not for the large images required by a Linux-capable system.

---

External DDR initialization: the boundary that changes the whole system

DDR initialization is not simply “enable RAM.” Before the controller can reliably read or write external DDR, early firmware must establish a compatible operating environment for the specific board and memory population.

At a high level, the R5 SPL must:

1. Ensure that DDR-related power and clock prerequisites are available.
2. Program the DDR controller with memory geometry and timing parameters appropriate to the attached DDR device.
3. Configure the DDR PHY, which translates controller transactions into the high-speed electrical signaling used at the DRAM pins.
4. Execute required calibration or training operations and check that the interface is usable.
5. Declare a usable DRAM region to later boot stages, which can then load substantially larger images.

The relevant inputs are not arbitrary constants copied from an unrelated board. They depend on the DRAM part, bus width, number of memory devices or ranks, routing topology, termination, reference voltages, intended frequency, and board-level signal integrity. Vendor reference code is therefore the starting point for a board bring-up, not an optional convenience.

A successful DDR boundary changes the feasible software architecture:

Before DDR initialization	After DDR initialization
Internal ROM and limited SRAM only	Large external memory available
Small R5-oriented loader	Multi-megabyte boot artifacts can be loaded
Minimal stack, BSS, buffers, and drivers	U-Boot Proper, kernel, DTB, initramfs, DMA buffers
Debug visibility may be absent or very limited	Serial logs and richer diagnostics are usually practical
A small allocation mistake can exhaust SRAM	Address planning still matters, but capacity is much larger

“DDR initialized” does not mean “all DRAM is free.” Firmware-reserved regions, secure memory, bootloader relocation space, kernel load addresses, device-tree location, initramfs placement, and DMA reservations must later be managed explicitly. But DDR initialization is the threshold at which normal-sized boot artifacts become possible.

For board bring-up, UART and RAM are the first two high-value milestones. UART lets you observe progress, while RAM unlocks the rest of the software stack. However, do not use absence of UART output as proof that ROM never ran: the console might only be initialized by a later stage that has not yet executed.

---

A reset-to-DRAM sequence diagram

A useful sequence diagram should identify:

• physical actors, such as the PMIC, oscillator, straps, boot medium, and DDR;
• silicon actors, including Boot ROM, TIFS, and the MCU R5;
• the exact cold-reset sampling boundary;
• the handoff from immutable ROM to programmable early firmware;
• the moment when DDR changes from unavailable to verified usable memory.

The diagram below is a model for an AM62x-style system. It intentionally stops at DRAM available. U-Boot Proper, device-tree loading, and kernel boot are later milestones.

Two details in this diagram deserve particular attention.

Boot mode is sampled; it is not a runtime policy

The BOOTMODE interaction occurs once at the cold-reset event. In a real board diagram, annotate the physical source of that value:

• fixed resistor straps for production;
• jumpers or resistor options for development flexibility;
• controlled external drivers for test automation, if electrically safe and stable at reset release.

Also show a primary and optional backup boot source in your accompanying notes. If ROM cannot boot the primary source, it may attempt the configured backup mode. For a gateway product, a backup boot path can be a recovery mechanism; for development, USB DFU or UART boot may be essential for unbricking a board after an invalid storage image.

PLL configuration and DDR configuration are different jobs

Both involve clocks, but they occur at different abstraction levels:

• Early reference-clock and PLL configuration lets the silicon derive appropriate internal clocks from the stable board reference clock. Boot straps may convey the expected reference-clock configuration to ROM.
• DDR clock and PHY configuration is part of bringing up the external memory subsystem. It must match the actual DRAM hardware and board electrical design.

Avoid placing “DDR initialization” before reset release, and avoid showing Linux or U-Boot Proper configuring DDR for the first time. The first-stage R5 SPL must establish usable DDR before those larger stages can execute normally.

---

Turn the model into your engineering artifact

Create a version of the sequence diagram for the AM62x board you select later in the course. Store the sanitized version in the public showcase repository under a path such as:

docs/architecture/reset-to-dram.md

Keep board-specific electrical details, boot media offsets, production boot configurations, and future security material in the private implementation repository.

Your diagram should contain the following minimum evidence:

• PMIC or regulator sequencing and stable reference-clock preconditions;
• cold reset held asserted, then released;
• boot straps stable before release and sampled at the PORz_OUT boundary;
• the distinction between ROM, R5 SPL in SRAM, and the later DRAM-resident stages;
• the selected primary boot medium and an identified backup or recovery path;
• explicit DDR controller and PHY initialization, followed by a verified “DRAM usable” state;
• a note identifying which facts came from the board schematic, SoC TRM, processor data sheet, and vendor bootloader configuration.

Do not add invented register addresses, voltage values, DDR timing numbers, or boot-pin encodings merely to make the diagram look complete. Mark such details as to be verified until you have the exact board and silicon documentation.

---

Key takeaways

A reliable reset-to-DRAM model begins before software executes:

• The PMIC, supply rails, oscillator, reset circuitry, and stable boot straps create the preconditions for cold-reset release.
• At the cold-reset boundary, Boot ROM samples and latches boot configuration; it does not continuously inspect boot straps afterward.
• On the AM62x K3 boot architecture, ROM and the MCU R5 path load a compact SRAM-resident early stage, with TIFS providing key system and security services.
• The R5 SPL is constrained by on-chip SRAM and must initialize DDR before large boot stages can be loaded.
• DDR initialization is a board-specific controller-and-PHY configuration problem, not a generic “enable RAM” switch.
• UART plus verified DDR are the first practical bring-up milestones, but lack of serial output alone does not prove that ROM failed.

Next, the course shifts from target initialization to the development side of the system: you will distinguish the build, host, and target machines and make an informed ARM64 toolchain and C-library choice for the automotive or industrial gateway.