waybeam: add the SigmaStar encoder package - #2332
Conversation
|
Reviewed — answers to both questions, three comment corrections, and one thing that has to change before this leaves draft. ISP bins: no dependency — the drop is provably free. The vendored They were pulled off a bench running stock OpenIPC firmware, so vendoring them was round-tripping this repo's own files. The only non-stock file, Sensor modules from source: right call, and the invocation is the documented one ( Scope: the commit carries seven files I did not write, under my authorship. Hardware: running the gate now on an SSC338Q and an SSC378QE; output to follow here. Checklist beyond boot/insmod/stream: verify the installed |
10ee943 to
23c57fe
Compare
|
Scope: you're right, and it's fixed. Force-pushed The cause was mine and worth stating plainly: this checkout is shared, HEAD moved to another branch mid-task, and my One correction to your correction: ISP bins — confirmed independently, and the comments are rewritten. Same md5s from the fetched source and from this tree: Both of your precision fixes are in. The The "no in-tree modules at all" line is gone, replaced with your actual justification: OpenIPC/sensors does carry On your module-path check — good catch, and it is answerable without hardware. The stock packages install to literal paths ( That I6C run also exercised the Maruko backend and the musl toolchain for the first time in this migration, producing an image at 4472KB/5120KB. That still leaves the runtime half to your bench — paths agreeing at build time does not prove the module loads and streams. |
|
Hardware gate, first half: SSC378QE (Infinity6C), IMX335 fitted — booted an image from this branch ( PASS — the four gate items:
FAIL — out of the box, the shipped The abort path wedges in the i6c MI flush, the encoder's recovery forces a reboot, and the board cycles every ~60 s. Control: with Fix, verified on the bench: ship Two smaller notes:
SSC338Q half: image builds from this branch — |
|
Correction to my previous comment — the There were two independent faults, neither of them in 1. The
With 2. The OSDRV MI libraries are a different SDK revision than the encoder targets, so 3A never actuates and the image is black. So the PR's "the package ships no libraries itself" needs revisiting for Infinity6C: as it stands the encoder runs against libs it was not built for. Two honest options — have the package carry (or depend on) the newer MI set, or build the i6c backend against the revision OSDRV ships. That decision is yours; I only have evidence that the current pairing does not work. One practical detail if the newer libs are shipped: With both addressed, the shipped defaults are fine as written. A So the four gate items in this PR all pass, and the earlier evidence for them stands unchanged — source-compiled modules at the right path ( What still needs hardware is the SSC338Q half. That image builds from this branch ( |
Hardware testing on an SSC378QE (#2332) found the encoder running against MI libraries it was not built for. waybeam's Infinity6C backend targets the 2024-06-18 SigmaStar MI set; sigmastar-osdrv-infinity6c installs 2022-09-07. The pipeline streams on those, but AE never actuates and the frame is black -- mean luma 2.05/255 measured through the encoder's own snapshot endpoint, against 153.91 with the 2024 libraries, everything else held constant. So the package's claim to need no libraries of its own holds only where the revision OSDRV ships is one the backend targets. On Infinity6E it is; on Infinity6C it is not, and a package that builds, installs and streams black is worse than one that is not offered. Config.in drops the I6C dependency and says why, and the unreachable maruko branch comes out of the .mk with the measurement recorded so it is not rediscovered from scratch. Reconciling the two revisions belongs in sigmastar-osdrv-infinity6c, where bumping the MI libraries affects every I6C board -- majestic links them too -- and needs evidence of its own. I6C returns here once they agree. Verified: ssc338q_lite with Majestic off still builds -- waybeam and json_cli install, sensor_imx335_mipi.ko lands at /lib/modules/4.9.84/sigmastar with the kernel's vermagic, rootfs 5180KB/8192KB.
|
Thanks — and the retraction is appreciated; that's a harder thing to post than the original finding. Both of your claims reproduce against the tree here: On the MI library mismatch — you're right, and the package now offers Infinity6E only ( The I've deliberately not taken either of your two options here. Bumping the MI libraries belongs in On the DTB, I'd frame it differently. What's left is the SSC338Q half, which is now the only thing between this and coming out of draft, since I6C is no longer in scope. No rush on the powered bench — the I6C result was worth having on its own. |
Migrated from OpenIPC/builder#110. waybeam is a standalone H.265 encoder and streamer for Infinity6E (SSC338Q/SSC30KQ) and Infinity6C (SSC378QE), selected from OPENIPC_SOC_FAMILY. It serves whole SoC families rather than one retail model, so it belongs in the shared tree rather than in builder. Three things changed on the way over, all of them to clear gates this tree enforces and builder does not: - The site pointed at OpenIPC/waybeam_venc, since renamed to OpenIPC/waybeam. - The sensor modules shipped as prebuilt .ko lifted from the source tree, which is a binary without a buildable source, and had to match the target kernel's vermagic by hand -- the builder PR left an I6E boot check as the open gate for exactly that reason. They are now compiled from drivers/*.c against the kernel this build just produced, so vermagic cannot drift. The SigmaStar headers they need come from the OpenIPC/sensors submodule, hence WAYBEAM_GIT_SUBMODULES. The install path follows LINUX_VERSION_PROBED rather than a literal 4.9.84 / 5.10.61. - The Infinity6C ISP tuning bins are not installed. They were pulled off a running SSC378QE, and are byte-identical to this tree's own copies in sigmastar-osdrv-infinity6c, so vendoring them round-tripped our files back at us. Nothing is lost: with isp.sensorBin empty waybeam resolves /etc/sensors/<sensor>.bin itself, the same stock tuning Majestic loads. No mainline defconfig can select this: it depends on !BR2_PACKAGE_MAJESTIC and every sigmastar board in ALL_BOARDS sets Majestic on, so it is listed in ci-matrix NOT_BUILT with that reason.
Hardware testing on an SSC378QE (#2332) found the encoder running against MI libraries it was not built for. waybeam's Infinity6C backend targets the 2024-06-18 SigmaStar MI set; sigmastar-osdrv-infinity6c installs 2022-09-07. The pipeline streams on those, but AE never actuates and the frame is black -- mean luma 2.05/255 measured through the encoder's own snapshot endpoint, against 153.91 with the 2024 libraries, everything else held constant. So the package's claim to need no libraries of its own holds only where the revision OSDRV ships is one the backend targets. On Infinity6E it is; on Infinity6C it is not, and a package that builds, installs and streams black is worse than one that is not offered. Config.in drops the I6C dependency and says why, and the unreachable maruko branch comes out of the .mk with the measurement recorded so it is not rediscovered from scratch. Reconciling the two revisions belongs in sigmastar-osdrv-infinity6c, where bumping the MI libraries affects every I6C board -- majestic links them too -- and needs evidence of its own. I6C returns here once they agree. Verified: ssc338q_lite with Majestic off still builds -- waybeam and json_cli install, sensor_imx335_mipi.ko lands at /lib/modules/4.9.84/sigmastar with the kernel's vermagic, rootfs 5180KB/8192KB.
PR Summary by QodoAdd Waybeam encoder package for SigmaStar Infinity6E
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
dedf78f to
6088ea0
Compare
Code Review by Qodo
1. Infinity6E lacks hardware evidence
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
wait_exit() fell out of its loop with a warning and no failing status, and stop() printed OK regardless, so `restart` ran start() against a process that had not died. start()'s own duplicate-instance guard then found it still running, printed "already running" and returned 0 -- a requested restart that silently never happened, which is exactly the failure mode the three-name matching in this script exists to avoid. wait_exit() now returns 1 on timeout. stop() escalates to SIGKILL once, and only claims OK when nothing is left; restart is `stop && start`. Found by the Qodo review on #2332.
|
Infinity6E half of the hardware gate: PASS, on an SSC338Q + IMX415, with the package's stock defaults and no modifications at all. This is the half I owed from the earlier comment. Unlike Infinity6C, it needed neither of the two workarounds — no device-tree override, no MI library swap. Image built from this branch as Modules compiled from source, installed over the stock names, loaded clean. Both carry the internal modname of this package's own drivers rather than the stock ones, and the vermagic matches the kernel from the same build — matching the local
Unlocked modes enumerate, and the unlocked one is what gets used. Stock IMX415 on this SoC does not offer 1080p90; the package's driver does, and Empty Stream is live and correctly exposed, Stable over a soak, which is the part I got wrong on the i6c side and want to state explicitly here: 6 minutes of monotonic uptime, the same PID throughout (no supervisor restart), zero
What this means for the two findings in my previous comment: both are Infinity6C-only. The MI libraries that OSDRV installs for Infinity6E are the same SDK build the encoder targets — One note for anyone reproducing this on a 16 MB board: mainline |
|
Post-merge note on SIGKILL bypasses the encoder's shutdown path, so This is not theoretical. We hit it on a Star6E bench on 2026-05-14: a There is a second-order cost too. The Two suggestions, either of which keeps the fix that matters:
Worth noting on the timeout as well: 15 s of SIGTERM is tight. We routinely see legitimate teardown take on the order of 12 s on these parts when the MI flush is slow, so the current window can fire on a shutdown that was going to succeed. To be explicit about what I have and have not tested: my Infinity6E evidence above was gathered on the tree as of Separately, the one review item still standing is |
2 participants
Migrates the
waybeamBuildroot package from OpenIPC/builder#110, authored by@snokvist, who is the commit author here too.
His review is wanted on this: the migration changes his work in a few places
and he is the person best placed to say whether those changes are right. He
could not be added through the reviewer field — GitHub only accepts review
requests for repository collaborators — so this mention is standing in for it.
Draft: the SSC338Q half has not run on a camera. See Hardware tested on.
Problem
waybeamis a standalone H.265 encoder and streamer for SigmaStar Infinity6E(SSC338Q / SSC30KQ). It serves a whole SoC family rather than one retail
model, which is what this repository is for, so the package was proposed
against OpenIPC/builder but belongs in the shared tree.
Four things changed on the way over, all of them to clear gates this repository
enforces and builder does not.
The sensor modules were prebuilt
.ko. The builder version installedsensors/star6e/sensor_imx*_star6e.kostraight out of the source tree. That isa binary without a buildable source, and it also has to match the target
kernel's vermagic by hand — builder#110 lists an I6E
insmodcheck as its oneremaining gate for exactly that reason.
Real source exists, at
drivers/sensor_imx*_star6e.c, so the package nowcompiles the modules against the kernel this build just produced:
$(MAKE) -C $(@D)/drivers sensor SOC=$(WAYBEAM_SOC) \ KSRC="$(LINUX_DIR)" CROSS="$(TARGET_CROSS)"Vermagic drift stops being possible. The SigmaStar headers that build needs are
not in the waybeam tree —
sensors-src/is a submodule on OpenIPC/sensors — sothe package sets
WAYBEAM_GIT_SUBMODULES = YES. The install path followsLINUX_VERSION_PROBEDinstead of a literal4.9.84.Infinity6C is not offered, even though the encoder has a backend for it.
@snokvist established on an SSC378QE that waybeam's I6C backend targets the
2024-06-18 SigmaStar MI libraries while
sigmastar-osdrv-infinity6cinstalls2022-09-07. The pipeline streams against those, but AE never actuates:
Everything else held constant. A package that builds, installs, streams and
produces black frames is worse than one that is not offered, so
Config.inrequires
BR2_PACKAGE_SIGMASTAR_OSDRV_INFINITY6Eand says why. Reconciling therevisions belongs in
sigmastar-osdrv-infinity6c— bumping those librariesreaches every I6C board, majestic included — and needs evidence of its own.
No ISP tuning bins are installed.
isp.sensorBinships empty and theencoder resolves
/etc/sensors/<sensor>.binitself, which is the same stocktuning Majestic loads, installed by OSDRV filtered on
OPENIPC_SNS_MODEL. Thebins vendored in the source tree were pulled off a running camera — the
binary-without-source case this repository refuses — and are byte-identical to
our own copies anyway.
The site moved.
OpenIPC/waybeam_vencwas renamed toOpenIPC/waybeam.WAYBEAM_VERSIONisHEAD, matching the other OpenIPC-org packages here.Hardware tested on
SSC378QE + IMX335, by @snokvist — see his comment below for the full
report. That bench is what established the MI library mismatch above. It also
confirmed the parts of this package that are not I6C-specific:
source-compiled modules installing at the right path with the kernel's own
vermagic and binding to
mi, all six unlocked modes enumerating, emptyisp.sensorBinresolving to the stock/etc/sensors/imx335.bin, and a live1792x1344@90 stream surviving a six-minute soak with no encoder errors.
SSC338Q / SSC30KQ: not yet. This is the family the package now ships for,
and its bench is not currently powered. The image builds (
uImage.ssc338q2,074,128 bytes, fits the 2MB kernel partition; installed
sensor_imx335_star6e,vermagic=4.9.84 SMP preempt mod_unload ARMv7 thumb2 p2v8), but nothing has streamed on it. That is why this is still a draft.Evidence
CI cannot build this package — no mainline defconfig can select it, see
Scope — so the build evidence is local, from
ssc338q_litewith Majestic offand
BR2_PACKAGE_WAYBEAM=y. That is a scratch defconfig and is not part ofthis diff.
The point of the driver change — the modules are compiled here, so they carry
the vermagic of the kernel in the same image rather than one matched by hand,
and they land in the directory the stock package writes to, which is what makes
it an overwrite rather than a second copy:
Repository checks:
Scope
general/package/all-patches/linux/(those go to OpenIPC/linux)general/overlay/or in a sharedload_<vendor>script hardcodes a value specific to my boardLD_PRELOAD, and no binaries that cannot be rebuilt from sourceTwo boxes are deliberately unticked.
The pin box: the source is an OpenIPC-org repository (
OpenIPC/waybeam),but
WAYBEAM_VERSIONisHEADrather than a 40-character SHA, so the box asworded is not honestly tickable. That is the house convention for first-party
packages —
ipctool,msposd,aura-httpd,divinus,osd-openipcand 19others do the same.
The defconfig box: nothing here can select
waybeam. It declaresdepends on !BR2_PACKAGE_MAJESTIC— the two drive the same sensor and encoder,and
sigmastar-osdrv-infinity6einstalls the MI libraries to/usr/libonlywhen Majestic is absent — and every sigmastar defconfig in
ALL_BOARDSsetsBR2_PACKAGE_MAJESTIC=y. It is unbuildable by construction here, not merelyunselected, so it is listed in
ci-matrix.py'sNOT_BUILTwith that reason.The FPV variants in OpenIPC/builder are what select it. A mainline defconfig
with Majestic off would take it off that list and tick this box.