[DmtryJS]

What

Build the CV610 backend in the image, and add a CV610 image that runs waybeam
instead of majestic/divinus.

• waybeam.mk: on hi3516cv6xx the CV610 slice is compiled against the
  public OpenHisilicon headers (CV610_SDK_INC → the opensdk checkout) and
  linked against the vendor MIPI/ISP libraries the osdrv package already
  installs — the same pair the daemon is built against outside the image.
• Sensor plugins, not kernel modules. CV610 has no sensor module to
  compile: its sensors are plugins the daemon dlopens. The package runs the
  tree's sensor-cv610 target and installs libsns_imx662.so and
  libsns_imx335.so over the stock plugin paths, instead of overwriting
  SigmaStar _mipi.ko names.
• The init script stays the shared one — it starts the daemon and never
  loads kernel modules, so on CV610 it runs on the vendor module set that
  S70vendor put up at boot. That is deliberate: every IMX335 mode runs on the
  boot clock, so the patched open_sys_config (runtime sensor clock) and
  open_pm_stub from the separate firmware track are not needed here.
• The shipped /etc/waybeam.json does not name the sensor. waybeam
  resolves the part from the system ($SENSOR, then the u-boot env, then
  ipcinfo) — the same env the loader follows for the sensor modules and the
  input clock. A config key could only disagree with what the craft loaded.
• hi3516cv6xx_waybeam_defconfig: the ultimate 16 MB envelope with Majestic
  and Divinus replaced by waybeam. BR2_OPENIPC_VARIANT="waybeam" gives the
  image its own upgrade identity so it cannot collide with the published
  majestic channel, and ci-matrix.py lists it under UNBUILT_BOARDS because
  it is not one of the standard variants the matrix builds.

Depends on

OpenIPC/waybeam#126 (CV610 sensor plumbing) and #127 (IMX335 plugin): until
they land, WAYBEAM_VERSION=HEAD provides neither the CV610 backend nor
sensors/cv610/imx335.

Verified

• The shipped waybeam.cv610.json was deployed as /etc/waybeam.json on a
  Hi3516CV610 with an IMX335 (daemon built from Anyka ak3918 #126 + [Firmware] Enable the watchdog kernel module on hi3516cv200/hi3518ev200 devices #127) and restarted:
  bring-up logs > CV610 sensor: imx335 (from u-boot env) — the config names no
  sensor — /api/v1/config contains no sensorType, /api/v1/modes reports
  the five IMX335 modes with selected_mode 0, contract_version 0.31.0, and
  the 2592x1944@30 mode produces live 1920x1080 HEVC plus a 5 MP snapshot.
  VPSS 2592x1944 -> 1920x1080, H.265 1920x1080@30 CBR=6000.
• Not flashed: the image itself is built by CI but was not written to NAND
  in this round. The check above exercises the package's config and the daemon
  it installs, not the bootloader/kernel payload.

[DmtryJS]

Rebased onto upstream/master (c72c51ad) and force-pushed as 61b68c30.

What changed in this revision:

• The shipped /etc/waybeam.json no longer names the sensor.
  "sensorType": "imx335" is gone from files/waybeam.cv610.json, together with
  the commit-message paragraph that made the image depend on it. The waybeam PRs
  moved to the same model: the part is resolved from the system
  ($SENSOR → fw_printenv -n sensor → ipcinfo --short-sensor), which is the
  env the loader itself follows for the sensor modules and the input clock. A
  config key could only disagree with what the craft loaded, and on a craft that
  boots the other part it would have been actively wrong.
• Kernel patches stay out of this PR, deliberately. Neither the patched
  open_sys_config (runtime sensor clock) nor open_pm_stub is needed for the
  IMX335: every one of its five fixed modes runs on the boot clock, so the
  shared init script can keep running on the vendor module set S70vendor
  brings up. That is stated in the commit message.

Verified on a Hi3516CV610 with an IMX335, using exactly the file this package
installs:

• files/waybeam.cv610.json copied to /etc/waybeam.json (md5
  a1c1a507c6e0b3cc862dcf1b6c090834), daemon restarted;
• > CV610 sensor: imx335 (from u-boot env) — resolution from the system, not
  from the config; /api/v1/config serves sensor: {index:-1, mode:-1} with no
  sensorType anywhere;
• fps 30 from that config selects IMX335 mode 0: IMX335_5M_30FPS_12BIT_LINEAR,
  VPSS 2592x1944 -> 1920x1080, H.265 1920x1080@30 CBR=6000, live snapshot at
  5 MP (568 KB), two snapshots with different md5;
• /api/v1/modes reports the five IMX335 modes, selected_mode 0,
  contract_version 0.31.0; no unknown config lines in the daemon log.

Caveat, stated in the body too: the image itself is still unflashed — CI builds
it, this run only exercises the package's shipped config and the daemon binary it
installs.

[DmtryJS]

Head is now 2022f656: the ci-matrix.py comment above NOT_BUILT still
claimed that no defconfig in the tree sets BR2_PACKAGE_WAYBEAM=y, which this
PR makes false. It now says what is actually true — the one defconfig that does
select it is hi3516cv6xx_waybeam, which sits in UNBUILT_BOARDS as a
non-standard variant, and that entry (not the package comment) is why the
matrix does not build it. ci-matrix.py --self-test → ok (107 boards, 157 packages, 76 cases).

A real image was built and inspected locally (make BOARD=hi3516cv6xx_waybeam,
waybeam@feat/cv610-imx335 supplied through WAYBEAM_OVERRIDE_SRCDIR; build
time 7 min):

• output/images/firmware.bin — 8,192,000 B, md5 92ee562ca863dd46fb782d49089a050e,
  fits the split layout at 0x50000 in the 16 MiB part (budget 15,808 KB);
  openipc.hi3516cv6xx-nor-waybeam-split.tgz — md5
  56eda38c388526ab2ee2de6f9adc7931, uImage 2,078,773 B.
• The image carries this PR's waybeam, verified by checksum, not by eye:
  /usr/bin/waybeam is the byte-identical daemon the craft has been running
  (the only delta after Buildroot's target-finalize is the RPATH string
  /usr/lib being neutralised, as it does for every target binary);
  /usr/lib/sensors/libsns_imx335.so is byte-identical to the branch's plugin
  after Buildroot's strip flags; /etc/waybeam.json is byte-identical to
  files/waybeam.cv610.json here and contains no sensorType.
• The kernel in that uImage (zImage-dtb, Linux 5.10.221-hi3516cv6xx) lists
  zb25vq64d/zb25vq128d in its SPI-NOR ids, so the Zbit part on the board is
  recognised — the failure mode that turns a wrong image into a panic.
• All downloads were hash-checked (squashfs, wireguard-tools retried once
  after a truncated first attempt and now match their expected sha256).

Still not flashed: the image is for a UART/NAND flash that has not happened yet.

[DmtryJS]

The image has been flashed on the Hi3516CV610 + IMX335 board (split layout,
firmware.bin written at 0x50000), and the result checks out end to end.

What the board reports after the reboot:

• /etc/os-release: VERSION=-g2022f656, BUILD_OPTION=waybeam,
  BUILD_PLATFORM=hi3516cv6xx_waybeam — built from this PR's head.
• The NAND content is byte-identical to the build. Reading the first
  8,192,000 B of mtd2 back,
  dd if=/dev/mtd2 bs=65536 count=125 | md5sum → 92ee562ca863dd46fb782d49089a050e,
  i.e. exactly the firmware.bin this tree produced.
• /usr/bin/waybeam 4f854550…, /usr/lib/sensors/libsns_imx335.so
6e121e66…, /etc/waybeam.json a1c1a507… — the same three hashes the build
  produced (the daemon's only delta from the branch build is Buildroot's RPATH
  neutralisation, as for every target binary).
• /api/v1/version → 0.86.0, contract 0.31.0, backend cv610;
  /api/v1/modes → five IMX335 modes, selected_mode 0, master's key set
  (no sensorType, no bitDepth); /api/v1/snapshot.jpg → 200, ~594 KiB, two
  snapshots with distinct md5.
• /tmp/waybeam.log: > CV610 sensor: imx335 (from SENSOR env) — the config
  names no sensor, the system's hint decided — then
  IMX335_5M_30FPS_12BIT_LINEAR Init OK, VPSS 2592x1944 -> 1920x1080,
  H.265 1920x1080@30 CBR=6000 (the shipped fps: 30, 1920x1080, 6000).
• The kernel-module story holds on real hardware: the shared init script
  loads no modules (grep -c 'insmod\|load-cv610\|SENSOR_PROFILE' /etc/init.d/S95waybeam
  → 0), there is no /etc/waybeam-cv610.conf, and the pipeline runs on the
  vendor set — open_mipi_rx, open_isp, open_vi, open_vpss, open_venc
  are loaded by S70vendor. fw_printenv -n sensor is still imx335: the
  u-boot/env partitions were not touched.

One observation that is not this PR's making, recorded so it is not
discovered later: curl in the image does not run —
Error loading shared library libz.so.1 — because no defconfig for
hi3516cv6xx selects BR2_PACKAGE_ZLIB except lite (libcurl-openipc.mk
only builds zlib when that symbol is on, yet libcurl ends up linked against it).
wget works, which is what sysupgrade and the deploy helpers use. Fixing it
is a defconfig change (BR2_PACKAGE_ZLIB=y) that belongs in its own patch —
say the word if you would rather have it folded in here.

[DmtryJS]

will back later