Add gk7202v300_lite_w7_8m device profile (GK-W7, GC2053-DVP, SSV6006C Wi-Fi) - #119
Add gk7202v300_lite_w7_8m device profile (GK-W7, GC2053-DVP, SSV6006C Wi-Fi)#119bneigher wants to merge 1 commit into
Conversation
GK7202V300, 8MB NOR, product string ipc533331a-W7-gc2053dvp-f8. Two things differ from the generic gk7202v300_lite target: - GC2053 wired in DVP (parallel) mode with the SID strap HIGH (i2c 0x3f). The generic target assumes MIPI + SID=0, so the i2c controller is muxed to pads that are not connected to the sensor and nothing is ever detected. - iComm/SSV SSV6006C USB Wi-Fi, USB ID 8065:6000. The generic Lite target ships only mt7601u, which is MediaTek silicon and will never bind it. Mirrors gk7202v300_lite_cootli_camv0103 (same SoC, same Wi-Fi family), minus BR2_PACKAGE_MOTORS since W7 is fixed-lens. Depends on OpenIPC/firmware#2276 for the opt-in sensor_dvp gate. Refs: OpenIPC/firmware#2074
PR Summary by QodoAdd GK-W7 (gk7202v300_lite_w7_8m) device profile with DVP GC2053 + SSV6006C Wi‑Fi
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
1. Device dir name uses underscores
|
| @@ -0,0 +1,44 @@ | |||
| #!/bin/sh | |||
There was a problem hiding this comment.
1. Device dir name uses underscores 📘 Rule violation ⚙ Maintainability
The new device directory devices/gk7202v300_lite_w7_8m/ does not follow the required <soc>_<flavor>_<vendor>-<model>[-<version>] format (missing vendor-model hyphenated segment and uses underscore tokens instead). This can break expected device discoverability/mapping conventions for BOARD naming and CI artifact layout.
Agent Prompt
## Issue description
The device directory name `gk7202v300_lite_w7_8m` does not comply with the required `<soc>_<flavor>_<vendor>-<model>[-<version>]` naming convention (vendor/model must be hyphen-separated and present).
## Issue Context
Compliance requires consistent device directory naming under `devices/` so that BOARD naming, CI artifact naming, and repository layout stay predictable.
## Fix Focus Areas
- devices/gk7202v300_lite_w7_8m/general/overlay/usr/share/openipc/customizer.sh[1-1]
- devices/gk7202v300_lite_w7_8m/br-ext-chip-goke/configs/gk7202v300_lite_w7_8m_defconfig[1-1]
- devices/gk7202v300_lite_w7_8m/general/scripts/excludes/gk7202v300_lite.list[1-1]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| Scan_mode = 1;VI_SCAN_INTERLACED = 0 | ||
| ;VI_SCAN_PROGRESSIVE, | ||
| Data_seq = VI_DATA_SEQ_YUYV ;data sequence (ONLY for YUV format) | ||
| ;----2th component U/V sequence in bt1120 |
There was a problem hiding this comment.
2. Data_seq constant mismatch 🐞 Bug ⚙ Maintainability
gc2053_i2c_dc_1080p.ini sets Data_seq = VI_DATA_SEQ_YUYV, but the same file documents VI_INPUT_DATA_* values for Data_seq, making the configuration internally inconsistent. This obscures the intended pixel ordering and makes future adjustments/troubleshooting of VI settings error-prone.
Agent Prompt
### Issue description
`Data_seq` is set to `VI_DATA_SEQ_YUYV`, but the INI’s own inline documentation lists the acceptable symbolic values as `VI_INPUT_DATA_{UYVY,VYUY,YUYV,YVYU}` (and other shipped configs use numeric equivalents). This makes the configuration internally inconsistent and harder to maintain.
### Issue Context
This INI is explicitly pinned by the device’s `customizer.sh`, so it becomes the board’s authoritative VI/sensor configuration.
### Fix Focus Areas
- devices/gk7202v300_lite_w7_8m/general/overlay/etc/sensors/gc2053_i2c_dc_1080p.ini[34-44]
### What to change
- Replace `Data_seq = VI_DATA_SEQ_YUYV` with a documented/consistent value, e.g. `Data_seq = 2` (matching other configs) or `Data_seq = VI_INPUT_DATA_YUYV`.
- Alternatively (if this config path is strictly RAW/RGB), remove `Data_seq` entirely to avoid implying it is relevant here.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Add
gk7202v300_lite_w7_8mdevice profile (GK-W7, GC2053-DVP, SSV6006C Wi-Fi)Adds a device profile for the GK-W7 board — GK7202V300, 8 MB NOR, product string
ipc533331a-W7-gc2053dvp-f8. Answers OpenIPC/firmware#2074, where @widgetii askedfor this as a builder profile rather than a change to the generic targets.
Hardware, and how it differs from the generic
gk7202v300_litetarget:SIDstrapped HIGH (7-bit i2c0x3f).The generic target assumes MIPI +
SID=0, so out of the box the i2c controlleris muxed to pads that are not connected to the sensor: every address NACKs, no
chip ID, no video.
8065:6000. The generic Lite targetships only
mt7601u, which is MediaTek silicon and will never bind this part —ip linkshowsloand nothing else.femac ... connect to PHY failedin dmesg is expected here).What is in the profile
br-ext-chip-goke/configs/gk7202v300_lite_w7_8m_defconfig— mirrorsgk7202v300_lite_cootli_camv0103(same SoC, same Wi-Fi family) withBR2_PACKAGE_SSV635X_OPENIPC=y. DropsBR2_PACKAGE_MOTORS— W7 is fixed-lens.general/overlay/usr/share/openipc/customizer.sh—wlandev ssv6x5x-generic,sensor gc2053, opt-insensor_dvp=1/sensor_mclk=24, and pins.isp.sensorConfigto the DVP ini explicitly rather than relying on ini-globordering.
general/overlay/etc/wireless/usb— thessv6x5x-genericbranch.general/overlay/etc/sensors/gc2053_i2c_dc_1080p.ini— DVP variant(
input_mode=INPUT_MODE_CMOS,Input_mod=VI_MODE_DIGITAL_CAMERA,Isp_Bayer=0RGGB). The shipped
gc2053_i2c_1080p.inideclares MIPI input.Companion PR
The pad-routing selector lives in
load_gokein the firmware tree, so thisprofile depends on OpenIPC/firmware#2276, which adds the
sensor_dvpenv-vargate. Per @widgetii's review note that is opt-in and keyed off an env var, not
off
$CHIP_TYPE— MIPI-wired gk7202v300 boards exist and testing the SoC namewould fix this board by breaking those.
Status: Wi-Fi and video both verified
Verified on three boards:
wlan0up and associating, and 1920x1080 H.264 overRTSP with
FrmErrCnt 0at 25 fps.Two caveats worth stating plainly rather than discovering after merge:
package is necessary but not sufficient — the chip enumerates, but reliable
cold boot and AP mode needed six patches to the SMAC tree (a duplicate
tu_ssv6xxx_init_mac()in probe that forces Jump-to-ROM and breaks RF underOpenIPC's xHCI, plus an EP2 IN drain before the ROM-ready poll). Those belong
in the
ssv6x5xtree and are offered separately; see the issue.galaxycore_gc2053_ForCarinOpenIPC/openhisiliconprograms i2c address0x6e(SID low), so on a SID-high board every register write silentlyno-ops while still reporting
Init_OK; and reg0x3eyields ValidWidth 1244instead of 1920, which VI counts as a frame error, starving VPSS and timing
out VENC. Where those should live — profile-local patch vs upstreamed to
openhisilicon— is the open question in the issue.So: this profile gets the board to a working Wi-Fi and a correctly-routed,
correctly-addressed sensor bus. The two items above are what stand between that
and a stock build producing video unaided.
Refs: OpenIPC/firmware#2074