Board: Radxa Cubie A7Z (Allwinner A733)
Camera: Radxa Camera 4K (Sony IMX415)
OS: Debian 11 Bullseye, kernel 5.15.147-21-a733
libisp: ISP602, branch libisp-dev, commit 665dc2e9613716c25abb6b64af145a73b989271e (2024-12-18)
Hi all,
We’re building a commercial product on the A7Z and have hit a hard blocker on the camera pipeline. I’ve traced it about as far as I can from outside the closed ISP library and wanted to post the full findings — partly to ask for help, partly so the next person searching for this finds something more detailed than “it’s broken.”
Happy to run any diagnostic you want on request.
Symptom
Single-shot capture is clean. num-buffers=1 at either 4K or 1080p gives a perfectly good frame — correct exposure, correct colour.
Continuous capture is not. Every frame comes out with:
a hard vertical split down the middle of the image, with each half processed differently
pink/magenta colour fringing, strongest along vertical edges
occasionally an entire frame in monochrome (AWB appears to fail outright on some runs)
This affects every frame in a continuous stream, not just the first few — so it isn’t AE/AWB converging over time. Resolution makes no difference: 4K and 1080p are both affected.
Pipeline used:
gst-launch-1.0 v4l2src device=/dev/video1 en-awisp=1 en-largemode=1 num-buffers=60 ! \
video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
jpegenc ! multifilesink location=frame_%03d.jpg
Root cause (as far as I can see it)
The ISP is running a 2-frame DOL-HDR stitch but only ever receives one buffer. From the logs:
[ISP]STITCH_2IN1_LINNER
[ISP]ISP Set Sync Mode = 0x3, isp_sync_mode = 0x20003
[ISP]find imx415_mipi_1920_1080_30_0 [imx415_mipi_1080p_isp_cfg] isp config
…
[ISP_ERR]isp_stat_process_buffer, line: 265,AEWB: stats error, skipping buffer.
[ISP_WARN]can not use sync mode.(buffer0 = 0xffff8c0418c0, buffer1 = (nil))
buffer1 = (nil) is the crux. The ISP is configured to fuse a long and a short exposure, gets one real buffer and one null, and blends against nothing — which produces exactly the split-frame and colour-fringing artefacts we see.
The kernel sensor driver is not the cause. I pulled the matching source (radxa/allwinner-bsp, branch cubie-aiot-v1.4.6, drivers/vin/modules/sensor/imx415_mipi.c) and checked:
sensor_win_sizes contains only single-exposure modes (4K30, 1080p30) — there is no DOL/WDR entry to select
the register tables explicitly set 0x302C = 0x00 (DOL mode = normal) and 0x302D = 0x00 (wdsel = normal exposure)
isp_wdr_mode therefore defaults to normal, and sensor_g_mbus_config() takes the single-channel branch
So the sensor is already in linear mode. Something above it is still asking for a 2-frame stitch.
That “something” appears to be libisp.so. STITCH_2IN1 and isp_sync_mode don’t appear anywhere in the kernel BSP source — only in /usr/lib/aarch64-linux-gnu/libisp.so. The IMX415 tuning also isn’t in the kernel’s ISP config tree (drivers/vfe/isp_cfg/SENSOR_H/ only has gc1034, hm2131, ov2710, ov2775), so it looks baked into the library.
There’s also no runtime escape hatch — the only v4l2 controls exposed on /dev/video1 are:
brightness, contrast, saturation, hue, white_balance_automatic
No WDR/HDR/stitch/mode control at all.
What we tried (all unsuccessful)
Attempt: Device-tree overlay work_mode 0x01 → 0x00
Result: Camera stopped enumerating entirely (/dev/video1 gone). Restored. Not an HDR toggle.
Attempt: Making the ISP tuning context writable (chmod 777 /mnt, remove 0-byte stubs)
Result: Worth keeping — ISP now saves/loads a valid 38872-byte context and init is consistent. Did not fix banding.
Attempt: Manual exposure + gain via /dev/v4l-subdev0
Result: Values apply, image still banded. Confirms it’s the stitch, not the 3A.
Attempt: 4K continuous vs 1080p continuous
Result: Both affected.
Attempt: Capturing RAW Bayer to bypass the ISP
Result: Blocked — see below.
On the RAW-bypass idea
The sensor’s native output is SGBRG10_1X10 and all four video nodes advertise RAW Bayer formats, so this looked promising. But the media topology routes every video node through the ISP:
imx415 → sunxi_mipi.1 → sunxi_csi.1 → sunxi_tdm_rx.0 → sunxi_isp.0 → sunxi_scaler.0 → vin_video0
sunxi_tdm_rx.2 and .3 have unrouted source pads and the raw data clearly exists at sunxi_csi.1, but there’s no capture node tapped before sunxi_isp.0, and sunxi_isp.0 has an [ENABLED,IMMUTABLE] self-link. So RAW capture isn’t reachable without kernel/DT work.
What we’re asking
Is there a working linear/SDR (non-DOL) ISP tuning for the IMX415 on A733? That’s really all we need — we’d happily trade HDR dynamic range for a correct, even image. For a security/CV application, predictable linear output is better than adaptive HDR.
If not, is a libisp.so fix planned? Any rough timeline would help us plan.
Alternatively — can the IMX415 tuning source be shared so we can build a linear tuning with the ISP tuning tool ourselves?
Failing all of the above: is there a supported way to capture RAW Bayer pre-ISP on this topology? If a DT change or an additional video node can expose the CSI output directly, we’re prepared to do the software debayering ourselves.
We’re not looking for a workaround so much as a direction — happy to do the engineering if the path exists.
Related
This looks like the same underlying issue as radxa-build/radxa-a733 issue #3 (“tuning file for imx415 exists but is not working… artifacts and unusable colour tuning”), just with more detail on where it originates.
Also worth flagging while I’m here, since it affects the same product: the hardware H.264 encoder never emits an SPS NAL unit, so encoded output is undecodable. Same issue thread mentions it. We’ve fallen back to MJPEG, which works but costs us 5–8× the storage. If both are being looked at together, that’d be useful to know.
Thanks — and genuinely, thanks for how much of the BSP is open. Being able to pull the sensor driver and rule it out saved us days.
