gk7205v500: build the XMedia module set from vendor SDK source - #229
Merged
Merged
Conversation
Adds CHIPARCH=gk7205v500 for the XMedia xm720xxxx dies (GK7205V500/V510/
V530, GK7202V330, GK7201V200), from XMediaIPCLinuxV100R002C00SPC020
(MPP_V1.0.0.0 B00, objects dated Apr 2023).
## What is built from source
osal (with MMZ and the media bus), sys_config, the ISP kernel driver,
sensor_i2c/sensor_spi/pwm/piris/sample_ist, init, wdt and adc -- all of
modules/ in the SDK.
## What is relinked
base, sys, vi, vpss, rgn, vgs, chnl, rc, venc, vedu, h264e, h265e,
jpege, mipi_rx, ive, cipher_drv, tde and audio ship only as objects.
Each SDK .o is already a complete module (init_module, modinfo), so it
is relinked as-is and modpost stamps the target kernel's vermagic.
The objects in obj/gk7205v500/{V200,V500}/ are byte-identical to the
SDK's obj_ko_lib/<set>/linux-4.9.y/obj_dynamic/obj_nolog.
The SDK ships two blob sets that are not interchangeable: V200 for
xm72050200-class dies and V500 for xm72050500-class ones. XM_SET picks
one (default V500); GK7201V200 (chip id 0x72010200) is a V200 die and
needs XM_SET=V200. The source modules get the matching -Dxm7205x0x00.
The objects were compiled against the SDK's xm72050200_tiny_defconfig
and call kernel APIs directly, so the kernel has to keep its struct
layouts: CONFIG_PM off (it moves struct device's fields -- with it on,
the media bus registration dereferences dev->class at the wrong offset)
and CONFIG_MODULE_UNLOAD off.
## sys_config
The only functional change to vendor source. The SDK predates the
GK7201V200 die and only matches xm720xxxxx chip strings; anything else
falls through every strncmp() and silently skips pinmux() and clkcfg().
On GK7201V200 that leaves the sensor i2c pins unmuxed (i2c "wait idle
timeout", no sensor). Now:
- OpenIPC SoC names (what load_goke passes) and xm72010200 are mapped to
the SDK chip whose pinmux/clock setup they share;
- the VI clock tables accept chip id 0x72010200 with the V200 dies;
- mis2008 gets the 27 MHz sensor clock.
## Verification
- Both sets build against openipc/linux 4.9.37 (gk7201v200_lite kernel
with CONFIG_PM and CONFIG_MODULE_UNLOAD off): V200 34 modules, V500
36 (DISABLE_VO=1; gfbg needs fbdev, which OpenIPC leaves out).
- QEMU (qemu-hisilicon -M gk7201v200): the V200 set loads in the stock
firmware's order -- osal, sysconfig chip=gk7201v200 sensors=mis2008,
base, sys, rgn, vgs, vi, isp, vpss, chnl, vedu, rc, venc, h264e,
h265e, jpege, ive, sensor_i2c, audio, mipi_rx -- every module prints
its "load ... OK" and there is no oops.
Firmware integration (package wiring, kernel config) follows separately.
PR Summary by QodoAdd gk7205v500 XMedia kernel module build support
AI Description
Diagram
High-Level Assessment
Files changed (208)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
SPC020's V200 sys gates SYS_ModInit on efuse 0x100a0028 bits [7:4] and accepts only 1..8 and 10..12. GK7201V200 fuses 0xD4 (nibble 13), so sys prints "SDK version do NOT support this chip!!!", its probe fails, and rgn then dereferences the missing sys function table -- the RGN_Init oops reported in OpenIPC/firmware#2428. The vendor's Jan 2024 sys, as shipped on these cameras, accepts 0xD0/0xD4. scripts/xm-sys-fuse-gk7201v200.sh rewrites the last whitelist entry in place, same length: ubfx r3, r3, #4, #4 ; cmp r3, #12 (bits[7:4] == 12) ubfx r3, r3, #5, #3 ; cmp r3, #6 (bits[7:5] == 6: nibble 12 or 13) so every chip accepted before still is. It refuses any input but the SPC020 V200 sys.o (md5-pinned; the V500 object has the same bytes at the same offset) and the committed object stays byte-identical to the SDK. Hardware (GK7201V200 / MIS2008, openipc/linux 4.9.37 with CONFIG_PM and CONFIG_MODULE_UNLOAD off and the devfreq userspace governor on): load_goke detects mis2008, and osal, sysconfig, base, sys, rgn, vgs, vi, isp, vpss, chnl, vedu, rc, venc, h264e, h265e, jpege, ive, sensor_i2c/ spi, audio and mipi_rx all load -- 26 modules, no oops.
… MIS2008 Replaces the sys.o byte patch. Widening sys's start-up whitelist was not enough: vi (145 sites), vpss (107) and venc (54) also key their capabilities on the efuse SKU byte at 0x100a0028, and with GK7201V200's 0xD4 venc refuses every channel (F008FFFF -- the error in OpenIPC/firmware#2464). The vendor's 2024 blobs know 0xD0/0xD4; SPC020 does not. They all read it through the pointer sys hands out, and sys maps it with osal_ioremap. So the V200 sys.o is relinked with osal_ioremap/iounmap redefined (objcopy) to init/gk7205v500/sys_efuse_shadow.c, which serves the efuse block from a RAM copy of its first 0x100 bytes (the modules read 0x10, 0x28, 0x34) with a 0xDx code presented as 0x1x -- the code stock's own vi groups 0xD0 with. Other mappings and codes pass through; efuse_sku= overrides the byte. The committed sys.o stays SDK-identical. libraries/sensor/gk7205v500/imagedesign_mis2008: the hi3516ev200 driver ported to the XMedia API (GK_* -> XMEDIA_*, gk_api_*.h -> xmedia_api_*.h), built against the SDK ISP headers now imported under kernel/isp/gk7205v500/include. The SDK ships no MIS2008 driver; stock links one into its App. Hardware (GK7201V200 / MIS2008, majestic lite with the SDK V200 userspace): "sys: efuse SKU 0xd4 presented as 0x14", MIS2008 initialises at 1080p, VENC channel created, RTSP serves H.264 1920x1080 25 fps. Image quality is not there yet: the picture is washed out and magenta with AE at minimum exposure, while VI/MIPI attributes, Bayer order and black level all match stock -- the sensor init/ISP defaults inherited from the ev200 driver are the next suspect.
Member
Author
|
Correction to the image-quality note in 849837d: the test camera had no lens mounted (so no IR-cut filter and no focus). A bare sensor flooded with unfocused light and IR gives exactly what was seen -- AE at minimum exposure, a flat frame, and a magenta cast with AWB lost (CoTemp 14084 K). VI/MIPI attributes, Bayer order and black level match stock, and AE register writes reach the sensor (0x3100 read back = the AE line count). So there is no evidence against the MIS2008 port; image quality still needs a check with the lens back on. |
Member
Author
|
Lens back on: the GK7201V200 / MIS2008 camera streams a normal image -- H.264 1920x1080 25 fps over RTSP from majestic, correct colours, AE and AWB settled. That closes the image-quality question from 849837d: the magenta frame was the missing lens/IR-cut, and the MIS2008 port (hi3516ev200 driver moved to the XMedia API) works as is. |
Review follow-up (qodo on #229) for the XMedia SDK sources: - osal media: release a minor from the dynamic bitmap only if it is in range; fixed minors (the watchdog's 130) were cleared past its end on every failure/unregister path. - mmz mmap: bound the mapping to the rest of the mmb it starts in; only the start address was checked, so an oversized request mapped whatever physical memory followed. - sys_config: default chip follows XM_SET (xm72050500 for V500 builds, not xm72050200); a register block that cannot be mapped now fails the load and unmaps instead of reporting success with nothing configured. The unmap moved out of the __exit function, which a MODULE_UNLOAD=n kernel discards. - osal_init: propagate media/mmz init failures and unwind. - isp probe: return -ENODEV on a missing IRQ (was XMEDIA_FALSE, i.e. 0) and on ISP_ModInit failure. - wdt: stop the watchdog if its feeder thread cannot be started. - adc probe: stop on an ioremap error instead of using the ERR_PTR. - sample_ist ioctl: copy_from_user the node index and reject negatives. - piris close: do not wait for a move to the current position (the timer never completes it); bound the wait. - drop open_init.ko: xmedia_init.c only does anything built-in (#ifndef MODULE), so the module was empty. Rechecked on the GK7201V200 / MIS2008 camera: 26 modules, no oops, no mmap rejections, majestic streams 1080p25 H.264 with a correct image.
widgetii
added a commit
that referenced
this pull request
Sep 25, 2026
#229 added libraries/sensor/gk7205v500/imagedesign_mis2008, a copy of the hi3516ev200 MIS2008 driver with GK_* renamed to XMEDIA_*. That is the same driver twice: the XMedia SPC020 sensor interface is the V4 one rebranded, the same relationship HiSilicon's and Goke's already have and that include/hicompat.h bridges for the V4 drivers. So the copy goes, and CHIPARCH=gk7205v500 builds sensor/hi3516ev200 like the other V4 targets. sensor/compat/xmedia maps the drivers' Goke names onto the SDK: - xm_gk_compat.h: GK_*/gk_* types and constants onto XMEDIA_*. Force- included: the drivers often get the Goke types only through the SDK headers, and those include their own type.h relative to themselves, so shadowing type.h on the include path cannot reach them; - gk_api_{isp,ae,awb}.h, hicompat.h: GK_API_* onto XMEDIA_API_*, with the SDK's own prototypes. libraries/Makefile puts these and the SDK headers imported under kernel/ ahead of the V4 include/ the per-sensor Makefiles add; no driver or per-sensor Makefile changes. All 30 V4 sensor drivers now build for gk7205v500 (before: only MIS2008, as the copy), with no warning the gk7205v200 build of the same sources does not already have; gk7205v200 still builds all 30. On the GK7201V200 / MIS2008 camera the shared-source libsns_mis2008.so initialises the sensor and majestic streams 1080p25 H.264 with a correct image.
widgetii
added a commit
that referenced
this pull request
Sep 25, 2026
* gk7205v500: build the V4 sensor drivers from their one source #229 added libraries/sensor/gk7205v500/imagedesign_mis2008, a copy of the hi3516ev200 MIS2008 driver with GK_* renamed to XMEDIA_*. That is the same driver twice: the XMedia SPC020 sensor interface is the V4 one rebranded, the same relationship HiSilicon's and Goke's already have and that include/hicompat.h bridges for the V4 drivers. So the copy goes, and CHIPARCH=gk7205v500 builds sensor/hi3516ev200 like the other V4 targets. sensor/compat/xmedia maps the drivers' Goke names onto the SDK: - xm_gk_compat.h: GK_*/gk_* types and constants onto XMEDIA_*. Force- included: the drivers often get the Goke types only through the SDK headers, and those include their own type.h relative to themselves, so shadowing type.h on the include path cannot reach them; - gk_api_{isp,ae,awb}.h, hicompat.h: GK_API_* onto XMEDIA_API_*, with the SDK's own prototypes. libraries/Makefile puts these and the SDK headers imported under kernel/ ahead of the V4 include/ the per-sensor Makefiles add; no driver or per-sensor Makefile changes. All 30 V4 sensor drivers now build for gk7205v500 (before: only MIS2008, as the copy), with no warning the gk7205v200 build of the same sources does not already have; gk7205v200 still builds all 30. On the GK7201V200 / MIS2008 camera the shared-source libsns_mis2008.so initialises the sensor and majestic streams 1080p25 H.264 with a correct image. * mis2008: stop the Dgain lookup reading 15 entries past its table cmos_dgain_calc_table() used a hard-coded size of 255 for Dgain_table[], which has 240 entries, so its saturation check read Dgain_table[254] -- whatever the linker put after the table -- and returned that as the sensor digital gain. What that is depends on the build: an -O0 build happened to get a large value and behaved, the optimised firmware build of the same source gets 0. With a Dgain of 0 the AE's system gain is 0, so it holds exposure short and makes the picture up with ~4x ISP digital gain -- a noisy, yellow-cast image (seen on GK7201V200: Line 64, Again 1x, Dgain 0, IspDg 4176, ISO 0). The size now comes from the table. Same camera, same scene, firmware build: Line 2694, Again 8x, Dgain 1024, IspDg ~1x, ISO 843, clean image. The bug is in the shared V4 driver, so hi3516ev200/gk7205v200 builds had it too.
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.
Adds CHIPARCH=gk7205v500 for the XMedia xm720xxxx dies (GK7205V500/V510/
V530, GK7202V330, GK7201V200), from XMediaIPCLinuxV100R002C00SPC020
(MPP_V1.0.0.0 B00, objects dated Apr 2023).
What is built from source
osal (with MMZ and the media bus), sys_config, the ISP kernel driver,
sensor_i2c/sensor_spi/pwm/piris/sample_ist, init, wdt and adc -- all of
modules/ in the SDK.
What is relinked
base, sys, vi, vpss, rgn, vgs, chnl, rc, venc, vedu, h264e, h265e,
jpege, mipi_rx, ive, cipher_drv, tde and audio ship only as objects.
Each SDK .o is already a complete module (init_module, modinfo), so it
is relinked as-is and modpost stamps the target kernel's vermagic.
The objects in obj/gk7205v500/{V200,V500}/ are byte-identical to the
SDK's obj_ko_lib//linux-4.9.y/obj_dynamic/obj_nolog.
The SDK ships two blob sets that are not interchangeable: V200 for
xm72050200-class dies and V500 for xm72050500-class ones. XM_SET picks
one (default V500); GK7201V200 (chip id 0x72010200) is a V200 die and
needs XM_SET=V200. The source modules get the matching -Dxm7205x0x00.
The objects were compiled against the SDK's xm72050200_tiny_defconfig
and call kernel APIs directly, so the kernel has to keep its struct
layouts: CONFIG_PM off (it moves struct device's fields -- with it on,
the media bus registration dereferences dev->class at the wrong offset)
and CONFIG_MODULE_UNLOAD off.
sys_config
The only functional change to vendor source. The SDK predates the
GK7201V200 die and only matches xm720xxxxx chip strings; anything else
falls through every strncmp() and silently skips pinmux() and clkcfg().
On GK7201V200 that leaves the sensor i2c pins unmuxed (i2c "wait idle
timeout", no sensor). Now:
the SDK chip whose pinmux/clock setup they share;
Verification
with CONFIG_PM and CONFIG_MODULE_UNLOAD off): V200 34 modules, V500
36 (DISABLE_VO=1; gfbg needs fbdev, which OpenIPC leaves out).
firmware's order -- osal, sysconfig chip=gk7201v200 sensors=mis2008,
base, sys, rgn, vgs, vi, isp, vpss, chnl, vedu, rc, venc, h264e,
h265e, jpege, ive, sensor_i2c, audio, mipi_rx -- every module prints
its "load ... OK" and there is no oops.
Firmware integration (package wiring, kernel config) follows separately, after this lands. Not yet hardware-tested; the GK7201V200 run will be posted here before merge.