Add gk7202v300_lite_generic-w7 device profile (GK-W7, GC2053-DVP, SSV6006C Wi-Fi) - #119
Add gk7202v300_lite_generic-w7 device profile (GK-W7, GC2053-DVP, SSV6006C Wi-Fi)#119bneigher wants to merge 2 commits 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.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
|
Thanks. Two findings here — one I would like your call on, one I think should be 1. Device directory naming. The bot is right that I have not renamed it yet for two reasons. @widgetii named this profile The honest problem is that I cannot name the vendor with any confidence. The
2. More to the point, this ini is a verbatim copy of a configuration verified on |
|
Good afternoon. The profile name does not follow the accepted format here, which is: processor_type-profile_vendor-model. Thank you |
|
Sorry — you asked me a direct question on 17 Aug and I left it sitting. Answering it below, but the naming is the smaller of the two things here. The profile is missing
|
Two review items from @widgetii and @flyrouter. 1. The profile never set sensor_mclk. This was a real hole, not a doc mismatch: the PR description claimed sensor_dvp=1 AND sensor_mclk=24, but only the first was in customizer.sh, so a board flashed from this profile would have come up at 27 MHz against 24 MHz init tables — the silent-corruption failure the firmware PR exists to prevent. My bench boards had sensor_mclk set by hand, which is exactly why the gap did not show. Confirmed against hardware rather than re-reading the code: PERI_CRG60 reads 0x00000019 at the moment load_goke writes it, i.e. bits [5:2] = 0x6 = 27 MHz, matching parse_sensor_clock()'s gc2053 -> 0x6 mapping. The ini cannot fix this — MCLK is a CRG clock programmed before majestic reads any ini. 2. Renamed gk7202v300_lite_w7_8m -> gk7202v300_lite_generic-w7, per the documented <soc>_<flavor>_<vendor>-<model> shape. "gk-w7" is dropped: GK is Goke, the SoC vendor, already carried by gk7202v300 — flyrouter's doubt that it names the board vendor was right, it does not. "generic" is the honest token for a board with no identifiable vendor, and is already established here (gk7205v200_otg_generic, ssc30kq_rubyfpv_generic). _8m dropped since flash size is BR2_OPENIPC_FLASH_SIZE. The excludes list stays gk7202v300_lite.list — that name is keyed to <soc>_<flavor>, not to the profile, matching every other profile in the tree. The inert ini Data_seq field is left as-is per review. Refs: OpenIPC/firmware#2276
bneigher
changed the title
|
Both applied in
|
|
Correcting myself on one detail above, because it is checkable and I got it wrong. I said my boards "have had The accurate version is worse for me, not better: my boards run a forked Which makes your suggested test the only one that means anything here, and it now |
|
Checked
I've approved the workflow runs, so Your correction is the more useful version, and it reaches further than you applied itThank you for posting it rather than letting the tidier story stand. It also changes something you said sixteen minutes earlier on the other PR, which I don't think you'd noticed, so I'm joining it up here. On OpenIPC/firmware#2276 you reported flashing a GK7202V300 and getting I'd rather say that plainly than let it sit in the record as end-to-end validation of something already merged. What that does and doesn't changeIt doesn't change the merge. That went in on evidence independent of your bench: the field layout measured on a lab board of the same family, the no-op path proven by execution-trace equivalence against the base script with a negative control that fails 13 checks, and CI green across all seven Goke boards. And your What remains open is what you already named: the merged No rush on it. The opt-in path is inert for every board that doesn't set the vars, so nothing is at risk in the field while this is outstanding — it's this profile's own correctness that's unproven, not the firmware change's safety. |
|
CI is green — and I closed the firmware half of the open question, though not yet The merged
|
|
Your image is built and published — the thing you were waiting on now exists: https://github.com/OpenIPC/builder/releases/tag/nightly-bisect-24da3cd Built from Why you were about to wait foreverThere is no CI artifact on this PR, and there never will be. The publishing steps in - name: Stage artifacts
if: github.event_name != 'pull_request' && (env.NORFW || env.NANDFW)
- name: Upload build artifacts
if: github.event_name != 'pull_request' && (env.NORFW || env.NANDFW)
The route that does work is the Worth knowing for your next profile too — ask a maintainer to dispatch Size, since this is the first build this profile has ever hadIt fits, but 220 KB of rootfs headroom is not much — about 4% of the partition. This family has a history of profiles going over the cliff as majestic grows ( On your hardware testI checked the md5 rather than taking it on trust: That closes the firmware half properly. It was the one case I said neither CI nor I could reach, and you reached it. So the only link left is the one you named: flash the image above onto a board with |
|
Heads-up on the artifact, since it changes what the remaining test needs from you. The run is green and
Three ways forward, and I am happy with any:
Unless you would rather have (2) or (3), I will start on (1), since it needs For the record, the firmware-side result from my last comment is unaffected by |
3 participants
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