Repository navigation
Conversation
openipc-ai
left a comment
There was a problem hiding this comment.
Thanks, this is a solid piece of work: the ARC firmware is real source, the 3A tables are documented measurements, and the module loading fits the existing S70vendor → load_fullhan -i path. ci-matrix.py --self-test, test_shell_parse.sh and test_strip_shell_comments.sh pass on the branch. It can't merge in its current state, though.
Blocking
- The board does not build.
RDA5995_OPENIPC_VERSIONis still06fd4b61252788bc46a66c88fd2773493ab5dd2a, and that tree has nordawlan-rda5995/(onlyrdawlan,include,Kconfig,Makefile,README.md). The directory arrives with OpenIPC/rda-wlan#1, which is still open. Once it merges, pin the merge commit as a full SHA. - No streamer until OpenIPC/divinus#72 lands.
DIVINUS_VERSION = HEADbuilds divinus master, where-DDIVINUS_V4L2does nothing. The image would start divinus with no backend for this SoC. Please wait for #72 to merge. - This branch has never been built on its own. The evidence image includes #2804, and #2804 says the 4.9 headers lack UAPI the 4.19 drivers use (the HEVC pixel format). With the borrowed fh8852v200 toolchain, the build will probably break as soon as #72 is in. Please fold #2804 into this PR rather than merging the two separately.
- The description says this stays a draft until rda-wlan#1 merges. Leaving it open for review is fine, but it can't merge before then.
Smaller
.github/scripts/ci-matrix.py: please drop the"gdbserver-lite"reflow inNOT_BUILT. Any edit to that file builds the full matrix, and with #2804 folded in, the reflow is the only change left there.fh8626-3ad.mkhas noFH8626_3AD_LICENSE_FILES.fullhan-osdrv-fh8626declares MIT, but neither the package norload_fullhancarries a license file or header.S80fh8626-3adaccepts gc1054, gc2053, jxf37, sp2306 and sp1405, butisp-tuning.cholds GC1054 tuning only. Either limit the list to what is tuned, or say in the README what the other sensors get.load_fullhan: one line on whytotal_mem=64Mholds for every FH8626V100 (the DDR is built into the chip package) would save the next reader the question.arc-binutilsfollows Buildroot'sBINUTILS_VERSION(2.40 today). That is fine, but a note in the.mkwould help, because it changes whenever Buildroot is bumped.
Order of operations: rda-wlan#1 and divinus#72 merge → bump the rda5995 pin → fold in #2804 → run toolchain.yml from the branch so that toolchain.fullhan-fh8626 exists → then CI is approved. CI is held for workflow approval, and because the PR touches ci-matrix.py and divinus.mk it builds every board, so it will be approved once the steps above are done.
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. 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 FH8852V200 toolchain's 4.9 kernel headers predate UAPI these drivers use, such as the HEVC pixel format, so add the board to the toolchain workflow, which publishes toolchain.fullhan-fh8626 with 4.19 headers, and build against that. 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.
b71a1de to
be3f7f6
Compare
PR Summary by QodoMove FH8626V100 to the Fullhan 4.19 camera kernel
AI Description
Diagram
High-Level Assessment
Files changed (33)
|
|
Thanks. Updated:
Rebuilt and flashed: 3A starts on GC1054, RTSP streams, and sysupgrade finds divinus on Order as you wrote: rda-wlan#1 and divinus#72 (and #77) merge, then the rda5995 pin bump, then a |
Code Review by Qodo
1. Some supported sensors block exposure
|
|
Thanks. Remaining blockers before this can merge:
Until 1 and 3 are done, expect |
Problem
fh8626v100_lite builds the FH8852V200 4.9 kernel with an FH8626 config. That kernel has no FH8626V100 media, audio or ARC drivers, so the image does not work as a camera.
This moves the board to OpenIPC/linux's
fullhan-fh86264.19 kernel (OpenIPC/linux#187, merged), whose media, audio and coprocessor drivers are in-tree V4L2, ALSA and remoteproc drivers, with the board DTB appended to the uImage. Commits:fh8626-arc-firmware: a minimal firmware for the ARC coprocessor, which thefh8626-arcremoteproc driver loads from/lib/firmware/fh8626-arc.elf. It is ARC600 assembly built from source: a resource table with two 32-entry vrings, therpmsg-arc-echoname service and an echo endpoint at address 1024.arc-binutilsbuilds the arc-elf32 assembler and linker from the binutils sources Buildroot already uses.rda5995-openipc: the driver becomes a choice.rdawlan(default) is the existing build, unchanged, so no board that selects the package changes.rdawlan-rda5995builds rda-wlan's 4.19 USB driver, which takes its firmware from/lib/firmware, and installs only the station images it loads (the AP images would cost 160 KB of rootfs). The rda-wlan is another seperate PR.fh8626-3ad: automatic exposure and white balance, a daemon that uses the kernel's ISP statistics and controls (local source, Apache-2.0 or GPL-2.0). This is basically "our version" of the vendor daemon.fullhan-osdrv-fh8626:load_fullhan, which loads the modules the devices ask for (mdev does not do that for devices present at boot) and raises a 4.9 SDKosmemto all of the DDR once. There is no vendor SDK, so nothing goes infiles/andmake toolchainbundles none.divinus: with that driver package selected, divinus is built with its V4L2/ALSA backend (Add V4L2 support divinus#72) and gets a start script, as it is the only streamer on the image. No other board changes.fh8626v100: the board itself. It selects all of the above and openipc-failsafe, because the kernel reserves U-Boot's boot counter. The kernel config leaves out ext4, swap, VT/PS2 input, IPsec transforms and signed regdb support, and builds cfg80211 and the V4L2 core as modules. The board also gets its own toolchain,toolchain.fullhan-fh8626(added totoolchain.yml): the borrowed FH8852V200 one has 4.9 kernel headers, which predate UAPI the 4.19 drivers use, such as the HEVC pixel format. This was fh8626v100: build its own toolchain, with 4.19 headers #2804, folded in here.Depends on OpenIPC/rda-wlan#1 and OpenIPC/divinus#72, and on OpenIPC/divinus#77 so that sysupgrade finds divinus feeding the watchdog.
DIVINUS_VERSIONisHEAD, so divinus needs no bump; once rda-wlan#1 merges, this PR gets one more commit that movesRDA5995_OPENIPC_VERSIONto the merge commit. After that,toolchain.ymlneeds one run from this branch so thattoolchain.fullhan-fh8626exists before CI builds the board.Hardware tested on
FH8626V100 (GC1054 sensor, RDA5995 USB Wi-Fi 1e04:8888, 8 MB NOR), OpenIPC U-Boot. The image was built from this branch, with a locally built
toolchain.fullhan-fh8626(GCC 13.3, musl, 4.19 headers) and the divinus PRs above applied.Evidence
Image sizes (the uImage was 2025 KB with the full 4.19 defconfig, before the config trim):
After boot (uptime, boot counter word, wlan0 address, unresolved module symbols,
/dev/snd, number of/dev/video*nodes):Wi-Fi driver, and the 3A daemon:
ARC coprocessor, started through sysfs:
RTSP from divinus, 10 s:
With audio enabled in
divinus.yaml:sysupgrade from this image to itself:
After each upgrade the camera reboots, Wi-Fi (WPA-PSK), DHCP and SSH come back on their own, and
S99bootokclears the counter.