bootm's ramdisk initrd delivery (boot_ramdisk_high()/LMB high-address
placement plus the fixed start/loados/ramdisk/fdt/cmdline/bdt/prep/go
ordering in bootm_run_states()) kept producing a kernel that booted
cleanly but silently discarded its initramfs, ending in "VFS: Cannot
open root device". Confirmed on hardware, multiple attempts, none
panned out (in-place mode collided with the kernel relocation;
reordering bootm substates is rejected by U-Boot itself as "out of
order"; the reserved-memory collision theory was disproven against the
compiled dtb).
Switched to bootefi instead: same FIT (no repackaging), parsed with
imxtract (kernel/fdt/ramdisk each extracted to a separate address),
then booted via the kernel's own EFI stub + LoadFile2 initrd protocol
-- a different code path in both U-Boot (efi_loader, not
boot_ramdisk_high()) and the kernel (efi_load_initrd(), never touches
reserve_initrd_mem()).
Two real bugs found and fixed along the way, both confirmed on
hardware:
- ramdisk destination must not be a hand-computed offset from
(that address is our own scratch buffer holding the
whole FIT, not the board's dedicated ramdisk block) -- use
$kernel_comp_addr_r instead, a separate 64 MiB LMB block the board
reserves for kernel decompression, unused since our Image is
uncompressed.
- bootefi's first argument (the kernel) needs an explicit ":size"
suffix. Without it, cmd/bootefi.c assumes the address was set by a
prior load/tftp command tracked via efi_set_image_parameters() --
imxtract never touches that tracking, so the address never matches
and bootefi fails with "No UEFI binary known" even though the
bytes there are a perfectly valid kernel image.
CONFIRMED ON HARDWARE 2026-09-18: reaches a live debug shell console.
Several stacked bugs were blocking boot_a resolution and kernel handoff,
found by working backwards from "could not resolve boot_a partition":
- clock-sm8550.c: add missing GCC_CFG_NOC_USB3_PRIM_AXI_CLK gate
(offset 0x39088 bit 0, verified against upstream gcc-sm8550.c). Needed
by the mainline USB DT nodes added to the vendor control-DTB (not
tracked in this repo, see ~/pmos/uboot-chainload/vendor-dtb-from-
boot_v14_dbg.dtb on the dev machine).
- bootcmd: boot_a is on `scsi 3`, not `scsi 0` -- Motorola splits UFS
into multiple LUNs, with boot-critical A/B partitions (boot_a/b,
dtbo_a/b, vbmeta_a/b) on a small 1.1 GB LUN separate from the ~236 GB
"user" LUN. Confirmed via `part number scsi N boot_a` sweep on
hardware.
- bootcmd: every setexpr call was missing the `$` before its operand
variable names (`boot_a_size` instead of `$boot_a_size`, etc).
setexpr always parses operands as hex via hextoul(), so the literal
string "boot_a_size" was read as 0xb (stops at the first non-hex
char), producing a nonsensical blksz and an integer-underflowed
fit_blk_cnt. This silently produced garbage even before the UFS fixes
below, since boot_a was never reached until now.
- bootcmd: `scsi read` doesn't take a device argument, it operates on
the last device selected via `scsi dev`; add that before the read.
The UFS host controller (ufshc@1d84000) and its PHY were never binding
at all in U-Boot, independent of all of the above -- three separate
issues in the vendor control-DTB (not in this repo):
1. Both nodes used `status = "ok"`, which fdtdec_get_is_enabled()
treats as disabled (it only accepts "okay").
2. The UFS PHY's compatible was the downstream
"qcom,ufs-phy-qmp-v4-kalama", unrecognized by phy-qcom-qmp-ufs.c
(needs "qcom,sm8550-qmp-ufs-phy").
3. Both the host controller's and PHY's clocks lists referenced
"qcom,kalama-rpmh-clk" (the root XO), which has no matching driver
in this U-Boot tree -- clk_get_bulk()/clk_get_by_index() on it
returned -ENODEV, aborting ufshcd_probe(). Removed the unused
reference on the host controller and added a plain 19.2 MHz
fixed-clock node for the PHY's ref_clk_src, which is the only
actual consumer of it by index.
Confirmed on hardware (2026-09-17): boot_a resolves, the raw FIT read
from UFS succeeds, and bootm loads kernel+ramdisk+fdt with hash
verification OK and reaches "Starting kernel ...". The kernel itself
now resets very early after that -- separate, unrelated bring-up work,
not a U-Boot/chainload issue.
Diagnostic bootmenu entries (12-14) are debugging aids kept for the
next round of hardware bring-up, along with the two `pause` statements
added to bootcmd around the SCSI read and bootm calls.
Confirmed on hardware that the chainload boots. The per-call blink
instrumentation lived in hot paths (clk_enable/qcom_gate_clk_en/serial
probe) and did a full 10 MiB framebuffer clear + cache flush on every
call, noticeably slowing boot. Replaced with a single progress bar
hooked once per INITCALL step (include/initcall.h) plus an explicit
100% draw at the end of board_late_init(), touching only the bar's
rectangle instead of the whole screen. Kept the real fixes from the
same patch (qcom,kalama-gcc-v2 GCC compatible, the IS_ERR(clk) handling
in serial_msm_geni.c) untouched.
The rtwo (Motorola Edge 40 Pro, SM8550/kalama) vendor DTB -- used by
U-Boot as its own control FDT (see board.c board_fdt_blob_setup(),
which sources it from the ABL-supplied vendor DTB rather than a
compiled-in one) -- describes the GCC with the downstream binding
"qcom,kalama-gcc-v2" instead of mainline's "qcom,sm8550-gcc". Same
hardware/register map (confirmed the vendor DT's raw clock IDs, e.g.
0x6b/0x7f/0x80, match GCC_QUPV3_WRAP1_S7_CLK/M_AHB_CLK/S_AHB_CLK from
dt-bindings/clock/qcom,sm8550-gcc.h 1:1), so reusing sm8550_gcc_data
for the new compatible is correct.
Without this alias the GCC driver never binds to that node, so any
clk_get() depending on it (e.g. the debug UART's "se" clock) returns
an error that is not -ENOENT/-ENODATA.
serial: msm_geni: don't clk_enable() an unfiltered error pointer
devm_clk_get_optional() only converts -ENOENT/-ENODATA to NULL; any
other error (such as the unbound-GCC case above) is returned as-is.
msm_serial_probe() passed that error pointer straight to clk_enable(),
which dereferences it in clk_valid() -> hard hang with no console, no
panic message, nothing (CONFIG_PANIC_HANG masks it further). Clamp any
IS_ERR(clk) to NULL so it degrades to "no clock" like the two error
codes that were already handled.
Debug: add 7-segment digit instrumentation for UART-less bring-up
Isolating the hang above required visual output on a device with no
serial console, no fastboot response while hung, and no crash log.
INITCALL() and a handful of clk/serial entry points now draw a large
two-digit 7-segment style zone number straight onto the ABL's
framebuffer at 0xb8000000 so the exact call site can be read directly
off the screen instead of inferred from blink/bar-count/binary-stripe
patterns, which gave contradictory readings across multiple attempts.
Zone 23 (entry to clk_enable()) is what pinpointed the hang above.
Harmless to leave in; candidate for removal once the rtwo port is
past active UART-less bring-up.
Confirmed on hardware: `fastboot boot` of this build reaches a live
U-Boot console (banner + prompt) on the rtwo. See project notes
rtwo-uboot-clk-compat-fix / rtwo-bring-up-estado for the full
debugging trail.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015ADQrjdgE8awSA7TSaGgfr
Custom bootcmd/bootargs for the Motorola Edge 40 Pro (rtwo, SM8550).
The Motorola ABL loads this U-Boot as its "kernel" and always fills
/chosen/linux,initrd-start with the RAM address of whatever it loaded
as "ramdisk" (standard Android/GKI boot protocol). We package a FIT
image (mainline pmOS kernel + dtb + initramfs) as that ramdisk, so
bootcmd reads $prevbl_initrd_start_addr (populated by
CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR from that same DT property)
and does `bootm` on it, with a menu/bootefi fallback if the FIT boot
fails.
Part of the rtwo bring-up: see project notes rtwo-uboot-chainload for
the full mechanism and why this replaced booting the mainline kernel
directly from the Motorola ABL.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015ADQrjdgE8awSA7TSaGgfr
snlavaise
