Repository navigation
fh8833v100: build from the FH885x V100 kernel and run its media stack - #2715
Conversation
PR Summary by QodoBuild FH8833 on the FH885x V100 stack and guard media startup
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1. Firmware changes lack camera validation
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| if insmod rtvbus.ko ra=0xa3e00000 rs=65536 fn=rtthread_arc_FH8852.bin fa=0xa3f00000; then | ||
| for i in 1 2 3 4 5 6 7 8 9 10; do | ||
| if [ "$(devmem 0xa3e0007c 32)" != 0x00000000 ] || | ||
| [ "$(devmem 0xa3e0807c 32)" != 0x00000000 ]; then | ||
| arc=1 | ||
| break | ||
| fi | ||
| usleep 200000 | ||
| done | ||
| fi | ||
| #insmod rtvbus.ko ra=0xa7e00000 rs=65536 fn=rtthread_arc_FH8856.bin fa=0xa7f00000 | ||
|
|
||
| #reset sensor | ||
| set_gpio 13 1 | ||
|
|
||
| if [ "$arc" = 0 ]; then | ||
| echo "load_fullhan: the ARC did not start, media modules not loaded" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
1. Firmware changes lack camera validation 📘 Rule violation ☼ Reliability
The new load_fullhan path changes ARC detection and media-module loading for the FH8852 V100 family, while the board also switches to that family's kernel and media stack. The pull request states that no FH8632, FH8852, or FH8856 camera was tested, so failures in module startup or streaming can reach shipped firmware without real-hardware evidence.
Agent Prompt
## Issue description
The PR changes shipped kernel/media behavior and explicitly reports no testing on an FH8632, FH8852, or FH8856 camera. The hardware-evidence gate requires before/after output from an affected real camera for firmware behavior changes.
## Fix Focus Areas
- general/package/fullhan-osdrv-fh8852v100/files/script/load_fullhan[21-45]
- br-ext-chip-fullhan/configs/fh8833v100_lite_defconfig[38-64]
## Recommended Fix
Run the affected image on a real FH8632 camera and on an FH8852 or FH8856 camera for the shared loader change. Record before/after boot, module-loading, and streaming output in the pull request, or defer the firmware behavior change until that evidence is available.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| # FH8833 (FH8632) has no HEVC encoder | ||
| grep -q FH8833 /proc/cpuinfo || insmod hevc.ko |
There was a problem hiding this comment.
2. Shared loader names one soc 📘 Rule violation ⚙ Maintainability
The shared load_fullhan script adds an FH8833-specific branch to decide whether to load the HEVC module. Because this loader serves the Fullhan family, the board-specific condition is embedded in shared firmware startup logic instead of a per-board configuration seam.
Agent Prompt
## Issue description
The shared Fullhan loader now contains an `FH8833`-specific module-loading condition, violating the shared firmware blast-radius boundary.
## Fix Focus Areas
- general/package/fullhan-osdrv-fh8852v100/files/script/load_fullhan[51-52]
- br-ext-chip-fullhan/configs/fh8833v100_lite_defconfig[1-66]
## Recommended Fix
Remove the `FH8833` test from the shared loader and express the board-specific HEVC module selection through the per-board configuration or a board-selected module list, while preserving HEVC loading for boards that support it.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| if [ "$arc" = 0 ]; then | ||
| echo "load_fullhan: the ARC did not start, media modules not loaded" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
3. Cameras lose media support after arc failure 📘 Rule violation ☼ Reliability
The shared load_fullhan script exits before loading media_process, isp, vpu, and the encoder modules when the ARC readiness words remain zero. This firmware-side startup workaround compensates for the vendor media stack's failed initialization path and leaves affected cameras without their media stack.
Agent Prompt
## Issue description
The shared firmware startup script suppresses the media stack when the ARC does not become ready, compensating for vendor media-module initialization behavior in firmware.
## Fix Focus Areas
- general/package/fullhan-osdrv-fh8852v100/files/script/load_fullhan[21-45]
## Recommended Fix
Move ARC readiness handling and failed-initialization cleanup into the owning kernel or vendor media driver, then keep the firmware loader's module sequence focused on loading supported modules through the established interface without silently disabling the media stack.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Qodo review, point by point. Fixes are in 5a6916b.
Re-tested |
Point-by-point:
Overall, commit |
|
On finding 2, these are the rules in question. CLAUDE.md, "No board-specific value in shared files":
best_practices.md §1.2:
The |
5a6916b to
e368af1
Compare
FH8632 (kernel machine FH8833) moves onto the FH885x V100 family: OPENIPC_SOC_FAMILY becomes fh8852v100, so the board takes that family's kernel tarball, which now carries the FH8833 machine, its published toolchain, its media package and its majestic. That stack is FH8632's: media_process in the FH8856_IPC_V1.2.0 SDK carries the fh8x33 chip tables (16, 64 and 128 MB), and majestic.fh8852v100 names FH8632 and FH8632v2. majestic is on for this board. The FH8632 SDK's own libraries cannot replace these: they lack API_ISP_SensorKick, which majestic imports. The kernel config moves to board/fh8852v100/: the old one carried into that tree, with the v1 SADC under its new name FH_SADC_V1, eight PWMs, and the USB host the shared fh_otg now drives. The board leaves UNBUILT_FAMILIES. load_fullhan, for the whole family: - hevc.ko is skipped on FH8833, which has no HEVC encoder; - the media modules wait for the ARC. rtvbus.ko loads whether or not the ARC starts; it clears the word at +0x7c of both ring halves and the ARC sets one, and vbus_mesg_doinit() refuses until then. Without it media_process.ko fails, and that failure path leaves a misc device behind that oopses the kernel when majestic opens it. Now the script waits up to two seconds for either flag and otherwise loads no media modules. Where the ARC starts, the same modules load in the same order as before. Depends on the FH8833 machine reaching fullhan-fh8852v100. Built locally against that branch: uImage 1704/2048 KB, rootfs 4444/5120 KB. In qemu-hisilicon's fh8632 machine it boots to the login prompt, gets a DHCP lease, writes the JFFS2 overlay and registers the USB host; with no ARC in QEMU, load_fullhan reports it and loads no media modules, and majestic starts without an oops. Not run on an FH8632 camera, and the load_fullhan change has not run on an FH8852 or FH8856 camera either.
- The ARC-ready check counts only a hex value with a nonzero digit as ready. A failed devmem read printed nothing, which compared unequal to 0x00000000 and passed as ready. - Modules load with modprobe instead of by path; depmod indexes the fullhan/ directory, and nothing here substitutes one module for another, so the dependencies modprobe resolves are the ones loaded. fh8833v100_lite in qemu-hisilicon's fh8632 machine (no ARC): "the ARC did not start, media modules not loaded", majestic starts, no oops; login, DHCP and JFFS2 overlay as before.
e368af1 to
4cfe63b
Compare
Problem
fh8833v100_lite(Fullhan FH8632 / FH8632v2, kernel machine FH8833) has never been built by CI (UNBUILT_FAMILIES), and it does not produce a working image. Itsfullhan-fh8833v100kernel no longer builds with gcc 13; built with older patches, it hangs right after "booting the kernel". It also has no streamer.This PR moves the board onto the FH885x V100 family, where FH8632 belongs:
Kernel:
OPENIPC_SOC_FAMILY=fh8852v100, whose kernel tarball carries the FH8833 machine after ARM: fullhan: bring FH8833 (FH8632) into the FH885x V100 tree linux#159 (draft). This PR depends on it. The kernel config moves toboard/fh8852v100/. It is the old config carried into that tree, with the v1 SADC under its new nameFH_SADC_V1, eight PWMs, and the USB host that the sharedfh_otgnow drives.Media: that family's toolchain,
fullhan-osdrv-fh8852v100and majestic. That media stack is FH8632's own:media_processin FH8856_IPC_V1.2.0 carrieschip_fh8x33_16M/64M/128Mtables;majestic.fh8852v100binary containsFH8632andFH8632v2.The FH8632 SDK's own libraries cannot replace these, because they lack
API_ISP_SensorKick, which that majestic imports. Majestic is on for this board.CI: the board leaves
UNBUILT_FAMILIESand joinsALL_BOARDS.load_fullhan, for the whole V100 family:hevc.kois skipped on FH8833, which has no HEVC encoder (/proc/cpuinfoHardware: FH8833).The media modules now wait for the ARC.
rtvbus.koloads whether or not the ARC starts. It clears the word at +0x7c of both ring halves, the ARC sets one of them, andvbus_mesg_doinit()refuses until then.Without that word,
media_process.kofails. Its failure path leaves a misc device behind, and the kernel oopses when majestic opens it; see the Before log. The script now waits up to two seconds for either word and otherwise loads no media modules. Where the ARC starts, the same modules load in the same order as before. That claim is reasoned from the disassembly, and it needs one FH8852 or FH8856 camera to confirm.Hardware tested on
None. Not run on an FH8632 camera, and the
load_fullhanchange has not run on an FH8852 or FH8856 camera either; draft until it has.Evidence
Built locally against OpenIPC/linux#159:
qemu-hisilicon
fh8632machine,test-fullhan-boot.sh:Before (this board, QEMU has no ARC, previous
load_fullhan):After:
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 source