HiSilicon V5 + aarch64 support (3519DV500 / 3516CV610)

[widgetii]

Brings up the HiSilicon V5 (HISI_OT) family on both 32-bit (Hi3516CV610 / Hi3516CV613) and 64-bit (Hi3516DV500 / Hi3519DV500) variants, and clears three latent bugs that aarch64 surfaces on the way.

Verified end-to-end on a Hi3519DV500 demo board (OS08A10 sensor) and rebuilt without warnings on a 32-bit ARMv7 toolchain.

Summary

1. chipid: V5 dispatch on aarch64 — the case for UART 0x11040000 → SC_CTRL 0x11020000 was previously gated by #ifdef __arm__ together with the legacy V1..V4 dispatches, which made the 64-bit V5 chips fall through to generic_detect_cpu(). Lifted out so both ARMv7 and aarch64 hit it; legacy V1..V4 cases stay 32-bit-only.

2. backup / tools: aarch64-only bugs — pre-existing UB that's invisible on 32-bit ARM / musl but fatal on aarch64 / glibc:

• backup.c:1005 uint32_t payload is passed to fread_to_buf(..., size_t *); sizes coincide on ARMv7, mismatch on aarch64. Switched the local to size_t.
• tools.c:get_god_pid did strncpy(NULL, ..., 0); aarch64 glibc faults on NULL dst even when n == 0. Guarded.
• tools.c:get_pid_cmdline did fclose(fp) on fp == NULL when a /proc/PID disappeared mid-scan. Restructured.

3. mtd: stream-hash UBI volumes — cb_mtd_info() mallocs the entire UBI volume just to SHA1 it. On Hi3519DV500 the rootfs UBI vol is data_bytes = 0x1D008000 (~464 MB) on a 512 MB device, so a bare ipctool immediately exits 137 (kernel oom-killer: Killed process N (ipctool) total-vm:495608kB, anon-rss:450564kB). Added sha1_ubi_volume() that streams 64 KB chunks through SHA1Init/Update/Final. read_ubi_volume() is unchanged because backup.c still needs the buffer.

4. clocks: V5 family — adds clocks_family_v5 (HISI_OT). PLL field layout is identical to V4 so the existing struct pll_info carries the four PLLs. DDR data rate is a three-stage chain (CRG ddr_cksel → DPLL post-divider → PHY dficlk_ratio) that doesn't fit struct mux_info, so this also adds an optional .extra(cJSON *root, bool brief) callback to clock_family. The V5 extra decodes DDR rate, DRAM type, SSMOD (DPLL spread-spectrum), and per-site live HPM samples; the canonical HPM binning value goes through the standard hpm_info table.

Output on Hi3519DV500 (OS08A10)

# bare `ipctool` brief survey
clocks:
  cpu_pll: { freq_mhz: 750 }
  hpm:     { bin: high }
  ddr:     { dram_type: DDR4, data_rate_mtps: 1328 }
  ssmod:   { enabled: true }

ipctool clocks produces full detail: each PLL's ctrl_reg1/2_raw + decoded fb/ref/postdiv/fracdiv + locked bit; HPM value=300 bin=high binning_window=[210,310] aux=hpm_core_reg0; SSMOD raw + cken/disable; hpm_sites block with 4 raw samples each for NPU / MDA / CORE.

Register map sources

All V5 addresses cross-referenced against the vendor SDK (Hi3516CV610_SDK_V1.0.2.0):

• PLL/CRG layout: bsp/components/gsl/include/platform.h, boot/reset.c, drivers/secure_driver/include/platform.h
• DDR map: bsp/components/gsl/drivers/ddr_init/include/hal/chip/hi3516cv610/{ddrtrn_training_custom.h,ddrtrn_low_freq.h}, hal/phy/ddrtrn_hal_phy_s14.h
• HPM map: bsp/components/gsl/include/svb.h
• SSMOD: open_source/u-boot/u-boot-2022.07.patch around line 30246

Test plan

• Bare ipctool produces full YAML on Hi3519DV500 (was: exit 137)
• ipctool clocks decodes APLL/VPLL/DPLL/EPLL, DDR4-1333, SSMOD active, HPM=300 high
• ipctool -c / -s / -t / printenv / dmesg / membw work
• Rebuilds clean with arm-linux-gnueabihf-gcc 11.1 (ARMv7) and aarch64-linux-gnu-gcc 15.2 (aarch64); no new warnings
• Both stripped binaries contain identical V5 symbol strings
• Runtime verification on an actual Hi3516CV610 (32-bit V5) board — should produce chip_name="3516CV610" and the same shape of clocks output

🤖 Generated with Claude Code