Boot log & firmware analysis: specific questions

It's a Qualcomm SBL image identifier. BOOT names the image kind (secondary bootloader). BF.3.3.1 is a Qualcomm-internal boot-firmware branch code (BF for IPQ, LA for Linux/Android, among others; the full mapping is not published by Qualcomm). 00163 is a build number within that branch. See the Qualcomm SBL walkthrough for the full decoding, including the accompanying IMAGE_VARIANT_STRING and OEM_IMAGE_VERSION_STRING.

HS-FS stands for High-Security Field-Securable : a K3 silicon-security state where signature verification is active but the OTP customer keys have not yet been burned, so the chip still accepts vendor-test-signed images. Expected on a Starter Kit; on a production board still shipping HS-FS it means the OTP provisioning step never happened. Full context in the TI K3 AM62A7 walkthrough.

DMSC (Device Management and Security Controller) is TI's umbrella name for the security-enclave firmware that runs on a dedicated core physically isolated from the application processors. On older K3 silicon (AM65x, J721E) DMSC is a single Cortex-M4F. On AM62A the role is split: TI Foundational Security (TIFS) runs on the M4F security enclave, and the Device Manager runs on a separate Cortex-R5F in the wake-up domain. The combined thing still shows up in banners as "DMSC firmware." See the full TI K3 walkthrough.

APPSBL (Application Secondary Boot Loader) is Qualcomm's name for the non-secure bootloader that SBL1 hands off to after loading QSEE, RPM, and other early images. On IPQ (networking) platforms APPSBL is Qualcomm's U-Boot fork, typically shipped as part of QSDK. On Snapdragon mobile platforms it is usually LK (Little Kernel) instead. See the Qualcomm SBL secure-boot post for a 6-stage walk from PBL to Linux.

Because the Qualcomm EL3 runtime (QSEE / tz image bundle) owns EL3, and the QSDK U-Boot image set has no EL2 hypervisor stub. Mainline ARM64 typically enters the kernel at EL2 to leave KVM/hypervisor open; IPQ boards drop straight to EL1. It is a QSEE-stack architectural choice, not a U-Boot config setting. Consequence: no in-guest virtualisation on stock IPQ router firmware. Detail in the Qualcomm SBL post.

MIDELEG is the RISC-V machine-mode interrupt-delegation register: a bitmask specifying which M-mode interrupts get delegated down to S-mode instead of being handled by the M-mode firmware (OpenSBI) itself. The common value 0x222 delegates the three standard S-mode interrupts (SSI, STI, SEI at bits 1, 5, 9), which is the expected shape for a Linux-capable board. The paired MEDELEG register does the same for synchronous exceptions. If S-mode isn't getting the traps it expects, these masks are where to check first. Full walkthrough in the RISC-V bootloader lifecycle post.

It opens an unauthenticated U-Boot command shell on the serial console. Pressing any key within the countdown drops the boot into a shell that lets the operator (or an attacker with UART access) printenv, setenv bootargs init=/bin/sh, tftpboot an arbitrary kernel, dump raw flash, or rewrite persistent env. No password, no token. 20 of 31 real boot captures in our sample corpus expose this. Attack walkthrough + mitigation Kconfig flags in the interruptable-autoboot post.

The AXP313A is an X-Powers PMIC. On the OrangePi Zero3 (Allwinner H618) and Zero 2W it's the primary power- management IC, sitting on the SoC's RSB (Reduced Serial Bus). The Zero2 (H616) ships instead with the AXP305: the pairing is board-specific, not fixed by SoC family. U-Boot SPL prints the abbreviation "AXP313"; the kernel's axp20x driver prints the full name AXP313A. Driver support landed in Linux 6.5. Full log walkthrough in the Allwinner H616/H618 post.

sun50i is the linux-sunxi family prefix for all Allwinner ARMv8 SoCs (A64, H5, H6, H313, H616, H618, H700). The BROM and BL31 print the model as "SUN50I" because they only know the family; the specific-part identification (H616 vs H618, etc.) happens further up the stack once the DTB is loaded. Related: the H618 boots with the H616 SoC ID (both are 0x1823 electrically), so the same TF-A image works for both. Detail in the Allwinner boot walkthrough.

SoC vendors ship a board-support package that snapshots upstream U-Boot at whatever version their reference-design engineer forked from, plus proprietary drivers for the radio, switch, PMIC, and boot ROM. The moment those drivers land, the vendor owns the diff: and there is zero commercial pressure to rebase. Six real router boot logs in the BootIntel sample corpus show U-Boot 1.1.3 / 1.1.4 forks of DENX releases from August and October 2005, with build timestamps 2009-2013 and devices still on retail shelves in 2026. See the U-Boot 1.1.x post for the evidence table.

Rule zero: keep a $3 CH340 cable as a sacrifice probe. Beyond that, three real options: the Tigard (best all-round, hardware level-shift, JTAG plus UART), the Flipper Zero (best if you already own one; UART works, corporate BYOD may flag it), and the Bus Pirate 5 / 5XL / 6 (best interactive console workflow, RP2040 on BP5, RP2350 on 5XL/6). Comparison table and per-device recommendations in the UART adapters post.

Paste a UART / boot log at /terminal for a free server-side preview: fingerprint, CVE match, and top findings, with CVE IDs masked. For a fully local, no-upload identification, use the browser-only fingerprinter. Paid tiers ( from $15/mo) unlock full CVE IDs, PDF / JSON export, unlimited scans, API access, and per-account AI opt-out.