Add a Gitter chat badge to README.md - #178
Closed
gitter-badger wants to merge 1 commit into
Closed
gitter-badger wants to merge 1 commit into
gitter-badger wants to merge 1 commit into
Conversation
This was referenced May 23, 2026
widgetii
pushed a commit
that referenced
this pull request
Jun 19, 2026
The bump pulled openhisilicon PR #178 (FEND event-type extension, ISP and MIPI RX edge-detect, ring/counter changes) into nightly images for every HiSilicon SoC in the matrix, but PR #178 was hardware- validated only on ev300 (V4 / IMX335) and av300 (cv500 / IMX415). On V2A / hi3518ev200, the changes inside kernel/isp/arch/hi3516cv200/ firmware/drv/isp.c shift ISP_ISR timing enough to surface a latent i2c-from-hardirq race (rt_mutex_trylock WARN at rtmutex.c:1545, sensor_i2c_write → i2c_transfer chain), and majestic can no longer read /image.jpg (HTTP 000, 10s timeout). The kernel itself stays alive — SSH works, sensor i2c just fails under contention — so cameras on a nightly build are recoverable, but the regression must stop shipping immediately. Pinning back to 7fa06b2 (the prior known-good opensdk version) until openhisilicon PR #178 / #179 are re-scoped to explicitly exclude SoCs without a hardware validation bench. Tracking re-land in openhisilicon, not here.
widgetii
pushed a commit
that referenced
this pull request
Jun 19, 2026
Picks up openhisilicon PR #178 (openhisilicon/issues/176, /177): - ISP_FEND second event source on /dev/openipc-frame-ts alongside MIPI_FS; pairing both gives sensor readout duration directly. ABI extended (event_type field, OPENIPC_FT_IOC_SET_EVENT_MASK ioctl). - Edge-detect on the level-held raw vsync / FEND bits in ISP_ISR and mipi_rx_interrupt_route (V4 + cv500) — fixes a previously-shipped cherry-pick that fired zero FEND events on real silicon. - Per-channel ring 64 → 256 (≈ 0.5 s buffer at 480 Hz of FS+FEND). - Split "dropped" counter: dropped = ring overflow (data loss), coalesced = dedupe rejects (expected). New GET_COALESCED ioctl. End-user impact: with this bump, smolrtsp / majestic (widgetii/majestic PR #83 already shipping) can issue NTP-anchored RTCP Sender Reports correctly across the whole HiSi V4 + cv500 lineup. FEND consumers (ROS fusion, latency telemetry) can also start computing per-frame sensor readout duration without an external probe. Validated empirically on ev300 (V4, IMX335) and av300 (cv500, IMX415) across the full sensor mode lineup — zero drops 21–240 fps, clean readout times scaling linearly with active row count (IMX335 4.4 ms at 480 rows up to 28.4 ms at 1944 rows; IMX415 31.5 ms at 4M).
widgetii
pushed a commit
that referenced
this pull request
Jun 19, 2026
The bump pulled openhisilicon PR #178 (FEND event-type extension, ISP and MIPI RX edge-detect, ring/counter changes) into nightly images for every HiSilicon SoC in the matrix, but PR #178 was hardware- validated only on ev300 (V4 / IMX335) and av300 (cv500 / IMX415). On V2A / hi3518ev200, the changes inside kernel/isp/arch/hi3516cv200/ firmware/drv/isp.c shift ISP_ISR timing enough to surface a latent i2c-from-hardirq race (rt_mutex_trylock WARN at rtmutex.c:1545, sensor_i2c_write → i2c_transfer chain), and majestic can no longer read /image.jpg (HTTP 000, 10s timeout). The kernel itself stays alive — SSH works, sensor i2c just fails under contention — so cameras on a nightly build are recoverable, but the regression must stop shipping immediately. Pinning back to 7fa06b2 (the prior known-good opensdk version) until openhisilicon PR #178 / #179 are re-scoped to explicitly exclude SoCs without a hardware validation bench. Tracking re-land in openhisilicon, not here.
widgetii
pushed a commit
that referenced
this pull request
Jun 19, 2026
Picks up openhisilicon PR #178 (openhisilicon/issues/176, /177): - ISP_FEND second event source on /dev/openipc-frame-ts alongside MIPI_FS; pairing both gives sensor readout duration directly. ABI extended (event_type field, OPENIPC_FT_IOC_SET_EVENT_MASK ioctl). - Edge-detect on the level-held raw vsync / FEND bits in ISP_ISR and mipi_rx_interrupt_route (V4 + cv500) — fixes a previously-shipped cherry-pick that fired zero FEND events on real silicon. - Per-channel ring 64 → 256 (≈ 0.5 s buffer at 480 Hz of FS+FEND). - Split "dropped" counter: dropped = ring overflow (data loss), coalesced = dedupe rejects (expected). New GET_COALESCED ioctl. End-user impact: with this bump, smolrtsp / majestic (widgetii/majestic PR #83 already shipping) can issue NTP-anchored RTCP Sender Reports correctly across the whole HiSi V4 + cv500 lineup. FEND consumers (ROS fusion, latency telemetry) can also start computing per-frame sensor readout duration without an external probe. Validated empirically on ev300 (V4, IMX335) and av300 (cv500, IMX415) across the full sensor mode lineup — zero drops 21–240 fps, clean readout times scaling linearly with active row count (IMX335 4.4 ms at 480 rows up to 28.4 ms at 1944 rows; IMX415 31.5 ms at 4M).
widgetii
added a commit
that referenced
this pull request
Sep 16, 2026
ipcinfo links libipchw, which knows every SoC vendor and every HiSilicon generation ipctool has ever learned: a detection table for eleven vendor HALs, and a chip-ID table, a sensor-bus back-end, a temperature formula and a die-ID reader for each of ten HiSilicon generations. A camera is one SoC. The rest is code that cannot execute on it, and it ships on all but three of this tree's board configs, onto boards whose rootfs cap leaves tens of KB spare -- gk7205v300_lite sits at 5080KB of 5120KB. Upstream takes both as build options defaulting to "all" (ipctool #178 and #211), and majestic already derives them the same way from its VENDOR and SDK code. This derives them from OPENIPC_SOC_VENDOR and OPENIPC_SOC_FAMILY. The family names are not a coincidence: ipctool's getchipfamily() returns the same strings, so `ipcinfo -f` on a board prints the key the table is indexed by. A vendor that is not HiSilicon reaches hal_hisi through nothing -- the only route is a HiSilicon UART0 base in chipid.c's dispatch -- so those boards drop hal_hisi.c and ispreg.c from the library altogether. Checked rather than assumed, on the two non-HiSilicon lab boards: ssc30kq has no uart line in /proc/iomem at all, and t31 reports 0x10031000, which is not one of the six bases that dispatch (and is one digit from xm510's 0x10030000 without being it). Two families are deliberately unmapped. The 3520DV200 ID sets no chip_generation, and no ID in ipctool's table matches a GK7101 or GK7102, so neither has a generation to name -- they keep every one rather than be trimmed on a guess. Unmapped means nothing is passed and upstream's default applies, so ambarella, anyka and ti keep every HAL too, and a new SoC is never silently trimmed to the wrong thing. Nothing derives IPCHW_SENSORS. A mainline image is per-family and gets flashed onto whatever camera someone bought; `ipcinfo --short-sensor` exists to name a sensor nobody catalogued, and it runs once, on an unprovisioned camera, with the answer written to U-Boot env. Compiling a probe family out turns that into "SENSOR is not detected, aborting". IPCHW_PADMUX is left alone too: --gc-sections already drops it from ipcinfo, and libipchw carries its selection as a PUBLIC compile definition, so setting it would break config_tool in sigmastar-osdrv-infinity6 on ssc325_lite and ssc325de_lite. CONF_OPTS only, never DEPENDENCIES: a _DEPENDENCIES line would add an edge to the graph ci-matrix.py walks and move its frozen board counts. Measured on gk7205v300_lite, same tree and commit, only this file differing: ipcinfo 34916 -> 22036 bytes -12880 (-37%) rootfs.squashfs 5080 -> 5076 KB -4KB, headroom 40KB -> 44KB Verified on a hi3516ev200 (V4, SC2315E, musl armv7), which takes the same options this file gives the Goke family: -c -f -v -s -l -F -i -S -x, every long form, the combined -ci that extutils uses, and -t all answer exactly as the stock 35124-byte binary does. ci-matrix --self-test passes and the frozen counts are unchanged; touching this package builds every board, which is the coverage this wants.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OpenIPC/firmware now has a Chat Room on Gitter
@ZigFisher has just created a chat room. You can visit it here: https://gitter.im/OpenIPC/russian.
This pull-request adds this badge to your README.md:
If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.