Repository navigation
anyka: one 4.4.302 kernel for every AK39 part, and the AK3918AV130 - #2635
Merged
Merged
Conversation
Anyka was the one vendor with boards in the tree and no entry in either map, so ak3918ev300 got every vendor HAL compiled into libipchw. ipctool's IPCHW_VENDORS has had an anyka option all along, and Anyka is not a HiSilicon derivative, so it asks for no HiSilicon generation.
The family ran the vendor's 3.4.35 for the AK3918EV300 and AK3916EV300
only, with no camera drivers in it. It now builds every AK39 generation
from one kernel, OpenIPC/linux anyka-ak3918ev300 at 4.4.302 (the
AK3918EV200 port at github.com/difanz/ak3918ev200-kernel, with the parts
below added), one toolchain, and the media drivers from source:
ak3910, ak3918 AK3910/AK3916/AK3918 (Aimer39): ISP v1 host and the
aksensor sensors, the old Anyka MAC
ak3918ev200 AK3918EV200: ISP2, the 8290 H.264/JPEG encoder on
V4L2, ALSA
ak3918ev300 AK3918EV300/EV330 and their AK3916/AK3919 packages,
one 64 MB image: ISP2 with DVP and MIPI sensors, the
Synopsys GMAC, the encoder's UIO
ak3916ev300 the same image under the name it already had
ak3918ev331 the 128 MB EV331 parts
Anyka's own 4.4 SDK builds its AK3918EV300 boards from the ak39ev330
dtsi, and the chip-ID registers tell EV300 and EV330 apart only by
revision, hence one image and the aliases. The uImage is the zImage with
the board's DTB appended, built by the kernel as on hisilicon.
Not one of these has booted on a camera. No toolchain.anyka-ak3918ev300 is
published yet, so the family stays in UNBUILT_FAMILIES and toolchain.yml
learns to build it.
The AV130's ISP, encoder, audio, Ethernet and SD drivers exist only as the prebuilt modules of the AnyCloud39AV130 SDK (github.com/Link-WQS/ANYKA_130L_SDK, os/driver_normal.tar.gz), built for 4.4.302-cip94. The family's kernel imports the AV130 machine from the same SDK and lays out the structures those modules share the vendor's way, and ak3918av130's config sets the -cip94 release string so their vermagic matches; every symbol they import resolves against it. load_anyka brings the modules up after the SDK's own scripts, picking the sensor from the sensor variable or ipcinfo. ak_eth and ak_mci go in /etc/modules from a post-build hook, because S70vendor runs after S40network. Not run on a camera. The package waits in NOT_BUILT with its family.
PR Summary by QodoUnify AK39 boards on Linux 4.4 and add AK3918AV130 drivers
AI Description
Diagram
High-Level Assessment
Files changed (42)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Comment on lines
+27
to
+29
| define ANYKA_OSDRV_AK3918AV130_INSTALL_TARGET_CMDS | ||
| $(INSTALL) -m 755 -d $(TARGET_DIR)/lib/modules/$(ANYKA_OSDRV_AK3918AV130_KVER)/anyka | ||
| $(INSTALL) -m 644 -t $(TARGET_DIR)/lib/modules/$(ANYKA_OSDRV_AK3918AV130_KVER)/anyka $(ANYKA_OSDRV_AK3918AV130_PKGDIR)/files/kmod/*.ko |
There was a problem hiding this comment.
2. Av130 drivers cannot be rebuilt 📘 Rule violation ⚙ Maintainability
ANYKA_OSDRV_AK3918AV130_INSTALL_TARGET_CMDS copies prebuilt SDK kernel modules into the image, while the package provides no source site or version and documents that source is unavailable for the ISP, encoder, audio, Ethernet, and SD drivers. Every AV130 image selecting this package depends on those binaries and their 4.4.302-cip94 kernel ABI, so a kernel or driver change cannot be rebuilt from the sources in this tree.
Agent Prompt
## Issue description
The AV130 package installs opaque, prebuilt SDK modules for core hardware drivers that cannot be rebuilt from the sources in this tree, tying images that select it to one kernel ABI.
## Fix Focus Areas
- general/package/anyka-osdrv-ak3918av130/anyka-osdrv-ak3918av130.mk[7-29]
- general/package/anyka-osdrv-ak3918av130/files/kmod/ak_isp.ko[1-1]
- br-ext-chip-anyka/configs/ak3918av130_lite_defconfig[46-47]
## Recommended Fix
Obtain buildable driver sources from a stable, pinned source location and compile the modules as part of the package build, retaining only artifacts reproducible from documented source. If source for every added binary is unavailable, defer selecting and shipping the AV130 driver package rather than installing opaque modules.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+11
to
+14
| # files/kmod is a subset of driver/external/ from os/driver_normal.tar.gz | ||
| # in the AnyCloud39AV130 SDK, unmodified: | ||
| # https://github.com/Link-WQS/ANYKA_130L_SDK | ||
| # commit 3480d024b682ccb2cf8bcb87dc4d2ac0af4dc49e |
There was a problem hiding this comment.
3. Av130 images ship 18 unrebuildable driver blobs 🐞 Bug ⛨ Security
files/kmod/*.ko adds 18 prebuilt kernel modules (ISP, encoder, PCM, Ethernet, SD, sensors). The diff shows them only as binary files, so their contents can't be reviewed, and they come from github.com/Link-WQS/ANYKA_130L_SDK, a personal GitHub account rather than an OpenIPC repository or a vendor release. Every ak3918av130_lite image installs them unchanged. Ethernet and SD on that board depend on ak_eth and ak_mci, so any kernel change that breaks their ABI leaves the camera with no network, and there is no source to rebuild them from.
Agent Prompt
## Issue description
anyka-osdrv-ak3918av130 ships 18 prebuilt .ko blobs taken from a personal GitHub account's SDK copy. They cannot be reviewed or rebuilt for another kernel.
## Fix Focus Areas
- general/package/anyka-osdrv-ak3918av130/anyka-osdrv-ak3918av130.mk[7-33]
- general/package/anyka-osdrv-ak3918av130/Config.in[1-10]
## Recommended Fix
Mirror the AnyCloud39AV130 SDK snapshot into an OpenIPC-org repository pinned at a full SHA, and fetch the modules through _SITE/_VERSION instead of committing them to this tree. Build the sensor drivers from the SDK's `os/driver_src/sensor` source now rather than later. Keep the remaining blobs explicitly documented as vendor binaries until source is available.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
… was checked The modules went to a literal /lib/modules/4.4.302-cip94. The family's kernel tracks a branch, and if its release string ever moved, ak_eth and ak_mci would sit where modprobe never looks and S35modules, which sends modprobe's output to /dev/null, would leave the camera without network or SD and say nothing. Install under the release the built kernel reports, after linux, and stop the build when that is not the -cip94 the modules were built for. The vermagic match is the only thing checked at load time: the modules carry no __versions, so CONFIG_MODVERSIONS has no CRCs to compare. Write down in the .mk what was checked instead -- symbol resolution against Module.symvers and the struct-layout probe from OpenIPC/linux#106 -- and, in ci-matrix.py, that the board waits for a boot on an AV130 before it joins ALL_BOARDS.
Collaborator
Author
|
Summary finding 6 (AV130 modules miss the kernel after a version bump) is fixed in 4e761fe.
Findings 2, 3 and 5 are left as they are for now. |
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
1 participant
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
The Anyka family covers only the AK3918EV300 and AK3916EV300, on the vendor's 3.4.35 kernel. Even those have no camera drivers, and there is no toolchain for them.
This PR builds every AK39 camera SoC from one kernel and one toolchain, with the media and network drivers from source, plus the AK3918AV130. The kernel is OpenIPC/linux#106, 4.4.302, meant to become
anyka-ak3918ev300.Boards
ak3910_lite,ak3918_liteak3918ev200_liteak3918ev300_liteak3916ev300_liteak3918ev300_liteak3918ev331_liteak3918ev300_liteak3918av130_liteanyka-osdrv-ak3918av130Commits
ipctool: the Anyka boards now build only the Anyka HAL into libipchw.anyka: the family moves to the 4.4 kernel and gains the boards above.anyka-osdrv-ak3918av130: the AV130 modules andload_anyka.Hardware tested on
None. Nothing here has booted on a camera, so this is a draft.
Evidence
No camera evidence, as above.
Local builds of all seven boards against the kernel branch, with a locally built
toolchain.anyka-ak3918ev300:In the
ak3918av130_liteimage:/lib/modules/4.4.302-cip94/anyka.Module.symvers./etc/modulesgainsak_ethandak_mci.check_target_modules.shpasses.Checks run locally:
Notes for review
os/driver_normal.tar.gz). The SDK has no source for the ISP, encoder, audio, Ethernet or SD drivers. It does have source for the sensors, so those could become a from-source package later.toolchain.anyka-ak3918ev300is published, andmake toolchaintakes its kernel headers from the family's kernel branch. The family therefore stays inUNBUILT_FAMILIES, andanyka-osdrv-ak3918av130inNOT_BUILT.anyka-ak3918ev300at it.toolchain.ymlforak3918ev300_lite.ALL_BOARDS..configBuildroot produced from the branch.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