load_hisilicon: derive os_mem_size from kernel cmdline mem=

[widgetii]

What was wrong

load_hisilicon was deciding where to put the MMZ region by reading osmem from the U-Boot environment. But the kernel's actual memory size is set by the mem= argument on the kernel command line — osmem is just a hint U-Boot uses when it builds that command line at boot.

On a hi3516av200 camera those two had drifted apart: the kernel was booted with mem=256M, while osmem in the env still said 128M. The script trusted osmem, computed mmz_start = 0x80000000 + 128M = 0x88000000, and asked the MMZ allocator for a 384MB region starting there. The kernel had already claimed everything up to 0x8FFFFFFF, so the request overlapped kernel memory by 128MB and got rejected.

What this PR does

Reads mem= directly from /proc/cmdline and uses that value as os_mem_size:

os_mem_size=$(awk 'BEGIN{RS=" "} /^mem=[0-9]+M/{gsub(/^mem=|M.*$/,""); print; exit}' /proc/cmdline)
if [ -z "$os_mem_size" ]; then
    os_mem_size=$(fw_printenv -n osmem | tr -d 'M')
fi
os_mem_size=${os_mem_size:=32}

/proc/cmdline is what the running kernel actually claimed — it can't lie. So now the script's "where does kernel memory end / where does MMZ start" matches reality, regardless of what osmem says. On the affected camera that produced mmz_start=0x90000000, mmz_size=256M, which fits cleanly above the kernel's 256MB and below the end of the 512MB DDR.

Why a fallback to osmem

If a kernel is booted without an explicit mem= (uncommon on these SoCs, but possible — the bootargsubi/bootargsnfs templates show that mem=${osmem} is normal but not enforced), /proc/cmdline won't have it. Falling back to the env keeps that boot path working instead of forcing every user to add a kernel arg. The final :=32 keeps the original behaviour as a last resort.

Why this layering instead of "just fix the env"

The env can be wrong in either direction (osmem larger or smaller than mem=), and on a remote camera you can't always rewrite U-Boot env safely. The cmdline-first approach makes the script self-correcting: whatever the kernel actually got, MMZ will agree with it. The env stays meaningful only as the boot-time hint it always was.

Pairs with opensdk bump (commit 2)

Also bumps HISILICON_OPENSDK_VERSION to e866011, which picks up openipc/openhisilicon#73 — mmz: fail allocator init when every configured zone is rejected.

Without the bump, a corrected osmem still leaves users on older opensdk builds silently passing a bad mmz= range without noticing; with the bump, that case becomes a loud insmod failure with the conflict line in dmesg right above it.

The two changes are complementary: this PR fixes the misconfig that produced the conflict, the opensdk bump ensures any future misconfig fails fast and visibly instead of presenting as zombie modules with empty MMZ.

Test plan

• Verified end-to-end on a live hi3516av200 (V3 family / kernel 3.18.20):
  • Before: mmz_start: 0x88000000, mmz_size: 384M → MMZ rejected → on opensdk e866011 insmod hi_osal.ko fails with MMZ: all 1 configured zone(s) failed to register and exit 19.
  • After: mmz_start: 0x90000000, mmz_size: 256M → MMZ registered successfully → all hi3519v101_* modules load → /proc/media-mem shows ZONE: PHYS(0x90000000, 0x9FFFFFFF), nBYTES=262144KB, NAME="anonymous" → majestic starts and reaches sensor init.
• CI: build all 8 affected boards.
• QEMU smoke test boots cleanly on each.

🤖 Generated with Claude Code