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.
snlavaise
bc6a059bf8