Repository navigation
ak3918ev200: video on OpenIPC conventions -- kernel at the bottom, osmem split, ak-cam, sensor tunings in /etc/sensor - #2796
Merged
Merged
Conversation
…plit
The AK3918EV200 drivers are built into the kernel; what the family
needs from a package is the sensors' ISP tuning and a bootloader
environment the kernel can take its memory split from.
files/sensor/<sensor>.conf is installed into /etc/sensor, where the
kernel's ISP driver reads the tuning of the sensor it detected by the
name ipctool gives it. sc1345.conf (SmartSens SC1345, DVP) is
isp_sc1345_dvp.conf from the stock firmware of a Gwell AK3918EV200
camera, converted from the vendor's "3.004" layout to the "3.05_032401"
one the kernel validates with files/sensor/convert-3.004.py; only header
fields change, no tuning value.
load_anyka: Linux gets osmem (mem=${osmem}) and video the rest of
totalmem. An environment with osmem equal to totalmem leaves no video
memory, so load_anyka -i lowers osmem by the 24 MiB the vendor firmware
gives video, once, and reboots.
The kernel now starts at 0x80000000 (load address 0x80008000) and takes its video memory as totalmem - osmem, like the other SoCs, instead of a device tree pool below a kernel at 0x81800000. The soc_camera host (VIDEO_AK) cannot capture with this kernel: it asks for /dev/isp_char to be open first, and that refuses to open until the ISP is prepared, which only the ak-cam bridge does. Build ak-cam and its sensor subdev instead, add the SC1345 driver, and install anyka-osdrv-ak3918ev200 for the sensor tuning and the osmem split. Needs the OpenIPC/linux anyka-ak3918ev300 changes that take video memory from mem= and the tuning from /etc/sensor, and the SC1345 driver.
…r tunings Build the six sensor drivers the vendor's AK3918EV200 firmware supports and the kernel now has, and ship ISP tunings for them and for the SC1235 and SC1245 the kernel already drove: nine files in /etc/sensor, each the newest generic vendor tuning for that sensor in the layout the EV200 ISP reads, converted by convert-3.004.py. The .mk lists where each came from. uImage 1618 KB of 2048, rootfs 4896 KB of 5120. Boots on qemu-hisilicon ak3918ev200; none of the new sensors has been run on hardware.
The kernel looks a tuning up by the name the sensor driver registers, which is now the one `ipcinfo -s` prints. Four files carried the vendor's name for a chip ipctool knows by another: gc1024.conf -> gc1004.conf ID 0x1004 h62.conf -> jxh62.conf ID 0xa062 sc1245.conf -> sc2145h.conf ID 0x1245 sc2232.conf -> sc2235p.conf ID 0x2232 Contents unchanged. Needs the OpenIPC/linux change that registers the drivers under these names.
PR Summary by QodoEnable AK3918EV200 video capture with reserved memory and sensor tunings
AI Description
Diagram
High-Level Assessment
Files changed (16)
|
Code Review by Qodo
1. Shipped tunings not regenerated by build
|
…ideo too little check_mem only acted when osmem was unset or at least totalmem, so osmem=60M on a 64M camera kept a 4 MiB video pool, too small to capture. Bring any split that leaves video less than the vendor's 24 MiB down to it; a larger pool, chosen on purpose, is left alone. Raised by the Qodo review of #2796. Dry-run against a stub environment: 64M, 60M and unset become 40M, 40M and 32M stay.
Collaborator
Author
|
On the Qodo review:
1 and 2 are the trade-off the description already declares (Scope, unticked box):
|
dimerr
enabled auto-merge (squash)
November 8, 2026 07:38
dimerr
disabled auto-merge
November 8, 2026 12:01
dimerr
enabled auto-merge (squash)
November 8, 2026 12:01
dimerr
marked this pull request as draft
November 8, 2026 12:23
auto-merge was automatically disabled
November 8, 2026 12:23
Pull request was converted to draft
dimerr
marked this pull request as ready for review
November 8, 2026 12:23
dimerr
enabled auto-merge (squash)
November 8, 2026 12:23
|
Code review by qodo was updated up to the latest commit 54a4b91 |
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
AK3918EV200 (
ak3918ev200_lite) gives no video:VIDEO_AK) cannot capture with this kernel: it wants/dev/isp_charopen, and that refuses to open until the ISP is prepared, which only theak-cambridge does.ak-cam, the first capture hard-locked the board. The 24 MiB video pool was a CMA region inside Linux's 40 MiB.This PR moves the EV200 to OpenIPC conventions:
mem=(anyka: EV200 video memory from mem=, sensor tuning by name, SC1345 and six more sensors linux#186). New boards getosmem=40Mfrom U-Boot (anyka: EV200: osmem 40M, the rest of the 64 MiB is video memory u-boot#112). Boards in the field get it fromload_anyka -i, which lowers anosmemequal tototalmemonce and reboots.ak-camcapture bridge instead ofVIDEO_AK.anyka-osdrv-ak3918ev200. It ships ISP tunings in/etc/sensor/<name>.conf, named asipcinfo -snames the sensor. The kernel loads the detected sensor's file.Needs OpenIPC/linux#186 merged first. Without its memory change, any capture with
ak-camlocks the board up.Hardware tested on
ak3918ev200, Gwell camera (SC1345 sensor, XM25QH64A, Wi-Fi only), flashed with
sysupgrade --archive.ak-cam, SC1345 and its tuning,load_anyka.ak3918ev200only: the last two commits (six more sensors and the tuning renames). Each tuning was checked against the kernel's validator, its driver's sensor ID and the frame rates the driver accepts. None of those sensors was available.Evidence
Before:
After. The migration from an old environment, as seen under qemu-hisilicon with this camera's own U-Boot and environment:
On the camera after the same migration (
fw_printenv:osmem=40M,totalmem=64M):Image size: uImage 1618 KB / 2048, rootfs 4896 KB / 5120.
ci-matrix.py --self-testandSTRICT=1 test_shell_parse.shpass. With the index diff, the selector builds the seven Anyka boards plus the smoke set.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 sourceUnticked, deliberately:
files/sensor/*.conftunings are vendor data: ISP tables and sensor register lists from the stock firmware of AK3918EV200 cameras (and one from the AnyCloud39EV300 SDK). On this ISP the sensor's init list lives in the tuning, so no driver can start its sensor without one. They are converted byfiles/sensor/convert-3.004.py(header fields only), and the.mklists where each came from.*_SITE; it installs files from this tree.There is no
LD_PRELOAD.