# BootIntel — full content

> Full-content variant of llms.txt. Includes markdown summaries of the seven current blog posts, each preserving the key log excerpts and load-bearing technical claims. For metadata, canonical URLs, and site navigation, see /llms.txt.

Every log excerpt below is grep-verifiable against its referenced sample file at https://bootintel.com/samples/bootintel-N.txt at the time of publication.

**Dataset:** the full 31-log corpus is packaged as *BootIntel Boot Log Corpus v1.0.0* under CC-BY-4.0. Manifest, methodology, and CITATION.cff at https://github.com/Zenofex/BootIntel.com/tree/main/dataset. Zenodo DOI will be added on release.

---

## Qualcomm SBL secure boot: what BOOT.BF.3.3.1-00163 actually tells you
Slug: /blog/qualcomm-sbl-secure-boot · Published 2026-08-17

**Device:** Arcadyan AW1000 (sold by Deutsche Telekom as the Speedport Smart 4). SoC: Qualcomm IPQ8074 — a networking-class Qualcomm SoC (IPQ line, not Snapdragon-branded). Log source: `/samples/bootintel-4.txt` (723 lines).

**Six-stage boot chain:**
1. **PBL** (Primary Boot Loader) — immutable ROM stage. RSA-verifies SBL1's signature against a certificate chain whose root-key SHA is fused into the chip. Ends at t=132674µs.
2. **SBL1** (Secondary Boot Loader) — runs from on-chip SRAM. Brings up the PMIC (`pm_device_init`), clock tree (`clock_init`), boot flash, then trains DDR (PCDDR3 @ 466 MHz). Loads and authenticates every subsequent image.
3. **QSEE** (Qualcomm Secure Execution Environment) — 1.37 MB TEE at EL3. Services SMC calls from the kernel for the rest of boot.
4. **RPM** (Resource Power Manager) + DEVCFG — RPM firmware (86 KB) runs on a dedicated Cortex-M3 coprocessor. DEVCFG (26 KB) programs pin/clock/rail state.
5. **APPSBL** (Application SBL) — on IPQ this is Qualcomm's U-Boot fork, 572 KB in this build.
6. **Linux** — OpenWrt 6.6.37, kernel starts at EL1 (not EL2 — QSEE owns EL3, no hypervisor stub).

**QC_IMAGE_VERSION_STRING decoded:** `BOOT.BF.3.3.1-00163` — `BOOT` names the image kind. `BF.3.3.1` is a Qualcomm-internal boot-firmware branch identifier (BF for IPQ boot firmware, LA for Linux/Android). `00163` is a build number.

**IMAGE_VARIANT_STRING=HAACANAZA:** 8-character encoded variant identifier whose internal field layout Qualcomm has not published. Differs between OEM SKUs of the same silicon.

**OEM_IMAGE_VERSION_STRING=CRM:** Chipset Release Manager tag — the image came off Qualcomm's CI-signed release pipeline.

**SBL1 microsecond timing log excerpt** (from bootintel-4.txt lines 8-62):
```
B -    132674 - PBL, End
B -    145973 - SBL1, Start
B -    331321 - pm_driver_init, Start
B -    337604 - clock_init, Start
B -    380457 - sbl1_ddr_set_params, Start
B -    448319 - Image Load, Start
D -    216245 - QSEE Image Loaded, Delta - (1374928 Bytes)
D -     23058 - RPM Image Loaded, Delta - (86660 Bytes)
D -     89914 - APPSBL Image Loaded, Delta - (572642 Bytes)
B -    797605 - QSEE Execution, Start
B -    803431 - USB D+ check, Start
B -    809805 - SBL1, End
D -    666150 - SBL1, Delta
S - Flash Throughput, 6903 KB/s
```

**Cross-observation with TI K3:** the Qualcomm log prints `psci: PSCIv1.0 detected in firmware` and `SMC Calling Convention v1.0`. The TI AM62A7 log prints `PSCIv1.1` and `SMC Calling Convention v1.4`. The Qualcomm EL3 stack is a couple of PSCI revisions behind, which is why userspace suspend paths on IPQ routers rely on `qcom_scm`-specific SMCs.

**QSEE A/B slots** visible in the kernel's MTD partition dump: `0:qsee` at 0x600000 and `0:qsee_1` at 0x300000 — Qualcomm's dual-slot pattern for failed-update fallback. Whether rollback protection is enforced via QFPROM anti-rollback fuses is separate; on IPQ networking parts it usually isn't.

**USB D+ check at t=803ms** is Qualcomm's EDL (Emergency Download Mode) entry point. If a USB host is detected on D+ at this point, SBL1 can hand control to the EDL loader (device appears to host as USB VID/PID 05c6:9008).

---

## Allwinner H616 / H618 boot: AXP313 PMIC init and the two-name SoC problem
Slug: /blog/allwinner-h616-h618-axp313-boot · Published 2026-08-17

**Device:** OrangePi Zero3 (Allwinner H618). Log source: `/samples/bootintel-16.txt`.

**Five-stage boot chain:**
1. **Boot ROM** — BROM looks for the eGON.BT0 magic at sector 16 of MMC0 (SD), then MMC2 (eMMC), then SPI-NOR, then FEL over USB.
2. **U-Boot SPL** — talks to the AXP313A PMIC over RSB (Reduced Serial Bus) to bring up rail voltages BEFORE DRAM init. Then trains DRAM (2 GiB LPDDR4 on this Zero3) and loads TF-A + U-Boot.
3. **TF-A BL31** — EL3 runtime. Detects SoC ID 0x1823 = H616 electrically. TF-A v2.9.
4. **U-Boot proper** — enumerates MMC/USB, loads `/extlinux/extlinux.conf`.
5. **Linux 6.6.30 (Manjaro ARM)** — kernel starts at EL2. Loads `axp20x-i2c` which redetects the PMIC as AXP313A variant.

**The two-name SoC problem** (the interesting hook):
- BL31 announces "Detected Allwinner H616 SoC (1823)"
- U-Boot proper shows `Model: OrangePi Zero2`
- The DTB loaded via extlinux is `sun50i-h618-orangepi-zero3.dtb`
- Kernel prints `Machine model: OrangePi Zero3`

Same board, three names. Reconciliation: H616 and H618 share SoC ID 0x1823 electrically; the U-Boot fork on this SD card was labeled for Zero2 but boots Zero3 via the DTB indirection.

**AXP313A pairing:** On the OrangePi Zero3 (Allwinner H618) and Zero 2W it's the primary PMIC. The Zero2 (H616) ships instead with an AXP305. Pairing is board-specific, not fixed by SoC family. SPL abbreviates as "AXP313"; the shipping chip is AXP313A (per public X-Powers datasheet). Kernel-side support landed in Linux 6.5.

**RSB error 0x10003** appears on every H616/H618 boot with AXP313a: `ERROR: RSB: set run-time address: 0x10003`. Non-fatal — an RSB-layer failure setting the run-time address for the PMIC. Exact decode isn't documented in mainline TF-A comments. Board continues to boot normally.

**Extlinux boot** — Allwinner uses standard U-Boot distro-boot infrastructure (which drives `sysboot` against `extlinux.conf`, wired up in U-Boot v2014.10) rather than custom bootcmd. Same convention Debian and Fedora ARM images use.

---

## TI K3 boot on an AM62A7: DMSC, TF-A, U-Boot, and four processor types in one log
Slug: /blog/ti-k3-dmsc-boot · Published 2026-08-17

**Device:** TI AM62A7 SK (Starter Kit). Boot media: eMMC. Log source: `/samples/bootintel-27.txt`.

**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 calls the combined thing "DMSC firmware" in banners and docs.

**Eight-stage boot chain:**
1. **Boot ROM** on the Cortex-M4F security enclave (TIFS). Loads and authenticates the TIFS + Device Manager firmware bundle.
2. **DMSC firmware** (TIFS + DM). Log: `DMSC Firmware Version 9.1.8--v09.01.08 (Kool Koala)`. TIFS on M4F, Device Manager on companion R5F. Stays resident for life of system.
3. **R5F SBL first stage** on the Cortex-R5F MCU core. Small (~205 KB) — loads and verifies second-stage SBL.
4. **R5F SBL second stage** — larger (~1.2 MB). Brings up the rest: HSM M4F, A53 application cores, C7x DSP.
5. **TF-A BL31** on Cortex-A53 EL3. Log: `BL31: v2.9(release):v2.9.0-614-gd7a7135d32-dirty, Built : 09:34:15, Aug 24 2023`.
6. **U-Boot SPL** on Cortex-A53 EL2 (BL33 in TF-A terms).
7. **U-Boot proper** on Cortex-A53 EL2. Log: `SoC: AM62AX SR1.0 HS-FS`, `Model: Texas Instruments AM62A7 SK`.
8. **Linux 6.1.46** on Cortex-A53 EL2.

**SoC banner decoded** (bootintel-27.txt line 64):
- `SR1.0` = 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` = "High-Security Field-Securable" — signature verification is active, but the OTP customer keys have not been burned yet, so the silicon still accepts vendor-test-signed images. Expected on a Starter Kit. On a production board still shipping HS-FS it would be the flag that OTP provisioning never happened.

**BL33 on K3 is U-Boot SPL, not full U-Boot.** SPL is what TF-A hands off to; SPL then loads full U-Boot.

**TF-A stages:** only BL31 and BL33 appear standalone on K3; BL1 and BL2 are rolled into the R5F SBL stages. BL32 (secure payload, OP-TEE) is optional and not loaded here.

**Cores present, per SBL second stage:** hsm-m4f0-0 (TIFS), r5f0-0 (real-time coprocessor), a530-0 (Linux), c75ss0 (C7000 DSP + Matrix Multiply Accelerator).

**"Kool Koala"** is the codename for the TI System Firmware 9.x release stream.

---

## RISC-V bootloader lifecycle, walked through one boot log
Slug: /blog/riscv-boot-lifecycle · Published 2026-08-17

**Device:** StarFive VisionFive V2 (JH7110 SoC, quad U74 + monitor S7 = 5 HARTs). Log source: `/samples/bootintel-6.txt`.

**Four-stage boot chain:**
1. **U-Boot SPL** — 8 GiB DDR init from a StarFive-signed blob.
2. **OpenSBI** — enters at M-mode. Delegates traps down to S-mode via MIDELEG/MEDELEG.
3. **U-Boot proper** — payload at S-mode.
4. **Linux** — with 4 of 5 HARTs running (HART 0 = monitor S7 is masked).

**RISC-V privilege levels:** M (machine, most privileged), S (supervisor, kernel), U (user). M-mode owns the hardware and is where OpenSBI lives; a modern OS never runs there.

**Boot HART report excerpt** (from bootintel-6.txt):
```
Boot HART ID              : 1
Boot HART Domain          : root
Boot HART Priv Version    : v1.11
Boot HART Base ISA        : rv64imafdcbx
Boot HART PMP Count       : 8
Boot HART PMP Granularity : 4096
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109
```

**MIDELEG = 0x222** delegates the three standard S-mode interrupts (SSI, STI, SEI at bits 1, 5, 9). **MEDELEG = 0xb109** delegates instruction-address-misaligned, breakpoint, user-ecall, and the three page-fault exceptions. Standard shape for a Linux-capable config. If you ever debug a mysterious OpenSBI hang, these masks are where to check that S-mode is getting the traps it expects.

**PMP** (Physical Memory Protection): the M-mode-owned mechanism that carves the physical address space into regions with independent R/W/X permissions per HART. Functionally between ARM's per-core MPU and TZASC bus-level partitioning.

**SBI** (Supervisor Binary Interface): the ABI S-mode uses to call up to M-mode. `ecall` from S-mode → OpenSBI. Older OpenSBI (pre-1.0) shipped SBI 0.2; upstream OpenSBI v1.4 and later implement most of SBI 2.0 (ratified in 2024).

**One honest caveat:** the M-mode firmware (OpenSBI) is standardized, open source, and shared across every vendor — a real security-posture win. But the pre-M-mode pieces on any given SoC generally are not. This VF2 log opens with `DDR version: dc2e84f0` — a StarFive-signed DRAM-init blob that runs before U-Boot SPL and is not part of the OpenSBI source tree. The JH7110 boot ROM is likewise closed. So "open M-mode" is real; "every byte of the boot chain is auditable" isn't.

---

## U-Boot 1.1.x from 2005 still ships on 2026 consumer routers
Slug: /blog/uboot-1.1.x-still-shipping · Published 2026-08-15

**Six of the 31 boot logs in BootIntel's public sample corpus show U-Boot 1.1.3 or 1.1.4** — DENX upstream releases from August and October 2005. Vendor-fork build timestamps run 2009-2013. Devices still on retail shelves in 2026.

**Evidence table** (every version string is a literal grep from the referenced file):

| Sample | Version line as captured | Device |
| --- | --- | --- |
| bootintel-12.txt | U-Boot 1.1.3 (Dec 4 2013) | TP-Link Archer C2 v1.0.0, Ralink APSoC |
| bootintel-25.txt | U-Boot 1.1.3 (Nov 7 2013) | ASUS RT-AC51U, Ralink APSoC |
| bootintel-29.txt | U-Boot 1.1.3 (Nov 7 2013) | ASUS RT-AC51U (second capture) |
| bootintel-26.txt | U-Boot 1.1.4 (May 3 2012) | AP121 hobbyist reference, Atheros AR9330 |
| bootintel-14.txt | U-Boot 1.1.4 (Jan 11 2012) | Atheros-based router, HTTP recovery on 192.168.1.1 |
| bootintel-30.txt | U-Boot 1.1.4 (April 17, 2009) | Micrel GPHY 200-16 network appliance |

**Why 21-year-old bootloader code is on shipping firmware:** SoC vendors ship a board-support package that snapshots upstream at whatever version the reference-design engineer forked from, plus proprietary drivers for radio, switch, PMIC, boot ROM. The moment those drivers hit, the vendor owns the diff. Rebasing is real engineering work; commercial pressure is zero. Fork gets forked into the reference design, copied into the OEM board port, shipped as-is.

**Categories of change these forks have missed** (not attributed to specific CVE IDs without vendor patch-history verification):
- Environment parser hardening (setenv/saveenv CRC + bounds handling)
- Network stack fixes (TFTP, BOOTP, DHCP parser bounds)
- Filesystem support (FAT, ext2, JFFS2 malformed-image handling)
- Config subsystem (post-2014.10 Kconfig-era hardening flags require manual backport)

**What to do:** reflash with OpenWrt if the SoC/board is supported (OpenWrt Table of Hardware); retire the device otherwise; if neither, treat the UART header as trusted-code access — physical enclosures with tamper evidence at minimum.

---

## Interruptable autoboot: the 3-second window that gives an attacker root
Slug: /blog/interruptable-autoboot · Published 2026-08-14

**20 of the 31 real boot captures in BootIntel's public sample corpus drop into an unauthenticated U-Boot shell if you press a key during power-on.** The prompt reads `Hit any key to stop autoboot: N` where N counts down 3, 2, 1, 0. It is the vendor deliberately leaving an unauthenticated U-Boot shell on the debug header of shipped consumer devices — not a bug or forgotten debug flag.

**What the shell offers:** an attacker with physical UART access can `printenv` (dumping crypto keys, Wi-Fi provisioning tokens, backend URLs stashed in env), overwrite `bootargs` to inject `init=/bin/sh`, `tftpboot` an arbitrary kernel, `md.b`/`sf read` to dump raw flash, and `saveenv` to persist compromise.

**Concrete attack path (three commands):**
```
# 1. attacker connects UART, powers on, mashes any key
Hit any key to stop autoboot:  1
=> printenv bootargs
bootargs=console=ttyS0,115200 root=/dev/mtdblock2 rw

# 2. rewrite bootargs to drop straight into a root shell
=> setenv bootargs "console=ttyS0,115200 root=/dev/mtdblock2 rw init=/bin/sh"

# 3. boot the vendor kernel with the new bootargs
=> boot
```

Total time from a live serial console to a root shell on the running kernel: seconds. No credentials required. No trace in logs the vendor's userspace generates.

**Scripted attack against a 3-second countdown:**
```
stty -F /dev/ttyUSB0 115200 raw -echo
while true; do printf '\r'; sleep 0.05; done > /dev/ttyUSB0 &
# now cycle power on the target device
```
Even a 3-second countdown falls to a scripted attacker. The exact incantation is public.

**Mitigations, best to worst:**
1. `CONFIG_BOOTDELAY=-2` — no interruption possible.
2. `CONFIG_AUTOBOOT_KEYED` — require a specific key sequence (not any keypress).
3. Physical enclosure with tamper evidence — if you can't defend the shell, defend the header.

---

## UART Adapters Worth Owning (2026)
Slug: /blog/uart-adapter-recommendations · Published 2026-06-23

**Rule zero:** buy the $3 CH340 cable first as a sacrifice probe. A blown-up cable is a $3 mistake; a blown-up Tigard is a $50 one.

**Three real options** for hardware boot log capture:

**Tigard** (~$50, Crowd Supply): best all-round. Hardware level-shifter (1.2/1.8/2.5/3.3/5.0 V), separate UART + JTAG + SPI + I2C headers, buffered outputs. Best for: production benchtop work where you don't want to think about voltage.

**Flipper Zero** (~$169): best if you already own one. UART works via GPIO expansion; sub-GHz and BLE radios trigger corporate BYOD flags (not the UART header). Best for: portable use, one-device-fits-many.

**Bus Pirate 5 (RP2040) and 5XL / 6 (RP2350)** ($70-$95, buspirate.com): best interactive-console workflow. Wide voltage range (1.65 to 5 V), scriptable, actively maintained firmware, mainline revision REV10. Best for: poking unknown chips when you'd rather type than write a pyftdi script.

**Counterfeit FTDI cables** — one thing to skip regardless. In January 2016 FTDI shipped a Windows driver that injected "NON GENUINE DEVICE FOUND" into the byte stream on clones. FTDI backed off after the outcry, and the behaviour never affected Linux or macOS drivers, but the clone market is still full of chips that identify weirdly under various OSes. Buy from Crowd Supply / Adafruit / SparkFun, or a $3 CH340 knowing you got a CH340.

**Capture commands:**
- `picocom -b 115200 /dev/ttyUSB0 --logfile boot.log`
- `tio /dev/ttyUSB0 --baudrate 115200 --log --log-file boot.log`
- `screen -L -Logfile boot.log /dev/ttyUSB0 115200`

**Web Serial** (`/terminal` on BootIntel) works in Chromium-based browsers only — Firefox does not implement the Web Serial API and there are no plans to.