Repository navigation
Conversation
The fh8626-arc remoteproc driver in OpenIPC/linux's fullhan-fh8626 kernel loads /lib/firmware/fh8626-arc.elf onto the FH8626V100's ARC. This is the minimal firmware for it, in ARC600 assembly: a resource table with two 32-entry vrings, the rpmsg-arc-echo name service and an echo endpoint at address 1024. It checks every descriptor against the shared DMA pool and reports a bad one as a crash, on doorbell bit 1, which it keeps set until the driver resets the core. arc-binutils builds the arc-elf32 assembler and linker for it from the binutils sources Buildroot already uses.
rda-wlan carries a second driver, rdawlan-rda5995, for Linux 4.19. It takes its firmware from /lib/firmware instead of compiling it in. Make the driver a choice. The default stays the existing rdawlan build at its current pin, so no board that selects the package changes. The new choice installs only the station images the driver loads.
The FH8626V100 ISP driver in the kernel exports per-frame zone statistics and its tuning controls through its V4L2 subdevice, but nothing closes the loop: without it the sensor stays at its initial exposure and the ISP at unity white balance. The daemon meters the statistics and drives the sensor's exposure and gain and the ISP's white balance, noise reduction and black level, next to whichever application streams from the capture device.
On the 4.19 kernel the FH8626V100 media, audio and remaining SoC drivers are modules bound from the device tree, and mdev does not load modules for devices present at boot. Provide the family's load_fullhan: it loads the modules the devices ask for. The device tree also reserves the media and ARC memory, so the kernel needs all of the DDR; an environment saved with the 4.9 SDK kernel's osmem 29M is raised once, and the camera rebooted.
The FH8626V100 media and audio drivers are V4L2 and ALSA drivers in the kernel, which divinus streams from when built with DIVINUS_V4L2. Build it that way with alsa-lib when the board's driver package is selected, and install a start script, since divinus is the only streamer there.
The board built the FH8852V200 4.9 kernel with an FH8626 config. That kernel has no FH8626V100 media, audio or ARC drivers, so the image had no streamer, and the only wireless firmware it carried was for a dongle the kernel has no driver for. Build OpenIPC/linux's fullhan-fh8626 kernel, whose drivers are V4L2, ALSA and remoteproc drivers in the tree, with its device tree appended to the uImage, and the FH8852V200 toolchain. Select divinus as the streamer, the 3A daemon, the ARC firmware, the driver loader and the RDA5995 driver for 4.19. The kernel reserves U-Boot's boot counter, so select openipc-failsafe as well, which clears it once the camera is up. The kernel config is the kernel's fh8626_defconfig less what a camera has no use for: ext4, swap, the VT console and PS/2 input, IPsec transforms and signed regulatory database support. cfg80211 and the V4L2 core are modules, loaded with the drivers that need them. That takes the uImage from 2025K to 1678K of its 2048K.
The board borrowed the FH8852V200 toolchain, whose 4.9 kernel headers predate UAPI the 4.19 kernel's drivers use, such as the HEVC pixel format. Add the board to the toolchain workflow, so that it publishes toolchain.fullhan-fh8626, and build against that with 4.19 headers.
difanz
requested review from
ZigFisher,
cronyx,
flyrouter,
p0i5k,
viktorxda and
ystinia
as code owners
November 9, 2026 10:45
PR Summary by QodoGive FH8626V100 a 4.19 toolchain and complete camera support
AI Description
Diagram
High-Level Assessment
Files changed (34)
|
Code Review by Qodo
1. FH8626 cameras start without media drivers
|
Collaborator
|
The change itself looks right: Before CI can pass, |
Author
|
Folded into #2803 as asked; the toolchain change is now part of its board commit. |
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
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.
Problem
After the move to the 4.19 kernel, fh8626v100_lite still borrows the FH8852V200 toolchain, whose 4.9 kernel headers predate UAPI the 4.19 drivers use, such as the HEVC pixel format. This adds the board to the toolchain workflow, so that it publishes
toolchain.fullhan-fh8626, and builds against that with 4.19 headers.Stacked on the board PR (fh8626v100: move to the fullhan-fh8626 4.19 kernel). The toolchain workflow has to be dispatched once, after this merges or from this branch, before CI can fetch the new toolchain.
Hardware tested on
FH8626V100, fh8626v100_lite image built with a locally built
toolchain.fullhan-fh8626(GCC 13.3, musl, 4.19 headers). It is the same image as in the board PR's evidence.Evidence
See the board PR: that image was built with this commit applied.