RK3326: add the Gusgu H7 subdevice

[pkilar]

Summary

• What is the goal of this PR? Add support for the Gusgu H7, an unbranded RK3326 handheld that ships a vendor EmuELEC 4.7 build.

rk3326-gusgu-h7.dts includes the eeclone base and overrides it. eeclone is the only RK3326 tree here that defines every node the H7 needs (internal_display, joypad, adc_keys, btn_pins), and its serial2 = &uart5 alias puts the H7's UART5 debug port on ttyS2, so the stock console= works unchanged. Everything else came from the device's own stock vendor DTB, with the GPIO assignments verified one at a time against physical button presses.

Three device-specific findings are encoded in the DTS:

• adc_keys is disabled. eeclone samples SARADC ch2 for volume; on the H7 that line is the analog stick's Y axis. A centred stick therefore reads as KEY_VOLUMEDOWN held, and ROCKNIX init drops into USB-MSC recovery on every boot. The H7's real volume buttons are GPIOs, moved to a gpio-keys node.
• joypad switches to rocknix-joypad with abs-left-first. The H7 has one stick wired direct to SARADC ch1/ch2 with no analog mux, which rocknix-singleadc-joypad cannot read. rocknix-joypad maps channels positionally and defaults to right-stick-first, so abs-left-first is what makes the stick report as ABS_X/ABS_Y.
• btn_pins gains pull-ups for the five H7 button lines eeclone does not configure.

The one shared-code change is in mkimage. The H7's vendor U-Boot is a 2017.09 fork that predates FDTOVERLAYS and never reaches boot.scr (it scans extlinux before scripts), so it needs an explicit FDT and literal LABEL= values rather than ${partition_boot} placeholders. Rather than change the shared extlinux.conf, mkimage_extlinux() now prefers extlinux/extlinux.conf.sub-<subdevice> when one is present. No existing subdevice ships such a file, so the -a and -b images are byte-identical.

h7-rgb-leds drives the three WS2812s in the ring around the stick, which hang off spi1 MOSI with no kernel driver in 7.1 (the stock firmware drives them from userspace too). The wire format was recovered by capturing the stock firmware's own ioctl(SPI_IOC_MESSAGE) buffers and is documented at the top of the script. The service is gated on ConditionPathExists=/dev/spidev1.0, which only the H7 DTS enables, so it does not start on any other RK3326 device.

Testing

• How was this tested? Built and run on the physical device. Each subsystem was checked individually rather than assumed from a clean boot.
• Test results: Working — display (1024x768 ST7703), audio, all 17 buttons, the volume keys, the analog stick, and the RGB ring cycling through the stock firmware's mode list from the RGB button. Serial console works with the stock console=ttyS2,1500000 and no cmdline change. The -a and -b images were rebuilt to confirm the mkimage change leaves them unaffected.

Additional Context

• WiFi is not part of this PR. The H7's RK915 chip is handled separately in RK3326: add the RK915 SDIO WiFi driver #3252. The DTS here does carry the rockchip,rk915 SDIO card node, but it simply binds nothing without that driver — the device boots and works fine on this PR alone, just without wireless.
• Related fixes split out so this PR stays device-scoped: alsa-ucm-conf: fix the rk817 playback mixer element #3249 (rk817 volume, which the H7 needs for working audio), rocknix-joypad: ratelimit the saradc read-failure message #3250 (SARADC log flood), RK3326: dw_mmc: survive an SDIO card that stops responding #3251 (dw_mmc SDIO robustness). None of them are prerequisites for this one.
• Not included deliberately: the device's stock vendor DTB. config/stock/ is copied wholesale into /usr/share/bootloader/ in every RK3326 image, and its README says users drop their own stock DTB there — shipping one device's 108KB vendor blob to the whole family seemed wrong on both size and licensing grounds. Everything needed was already extracted into the DTS.
• Panel handling: the 1024x768 ST7703 timings are baked into the DTS as a generic-dsi panel_description read out of the stock DTB, not supplied as an overlay, because this device's u-boot cannot apply overlays.
• I am the only person I know of with this device, so I cannot speak to hardware revision variance. Happy to adjust naming or layout to whatever fits the project's conventions for unbranded clones.

---

AI Usage

Did you use AI tools to help write this code? YES — Claude Code was used extensively: reverse-engineering the stock DTB and the RGB LED SPI protocol, working out the adc_keys/stick channel collision from the boot-into-recovery symptom, writing the DTS and the LED tool, and drafting this description. Every claim in the Testing section was checked on the physical device.

[Jacob-Matthew-Cook]

Nice to see Claude being used to add new devices. It’s fairly decent for this. A few questions, which other reviewers will probably also raise:

1. There are a lot of PRs it seems which have been raised, most of them are related to this device line. I would recommend trying to keep them all in a single PR. If they are all needed at once for the same device, keep them together.
2. A couple of modules seem to have been created and written for this device specifically. How many were written zero-shot by Claude, versus existing in other sources? It’s good if we can just reference and pull in existing code from maintained, upstream sources.
3. Is this AI implementation as “minimal” as possible?ROCKNIX uses quirk files to handle peripherals such as LEDs, which is beneficial as there is minimal extra changes.
4. Try and see if you can get the device folded into either device type a or b (legacy uboot vs. standard uboot)
5. Prompt Claude to be as concise as possible, to trim all comments to be a short as possible, and to make the implementation as trimmed as possible. Any kernel edits and additions must be strictly necessary for the devices to work.

These are just my suggestions, but you will get your PR merged more easily if everything is clear, concise, and organized. I did use Claude for the Pixel 2, but I was in touch with two ROCKNIX devs throughout the process.

[stolen]

Don't do this.
An image needs over 1 GB of artifacts and some compute power to compress.
We definitely don't want any bloat for such a dead platform as RK3326.

Also I added a note about this recently

[stolen]

This ad-hoc script+package is useless for other devices.
Integration with existing infrastructure would be much better.

Maybe this driver will work (or something similar) to expose leds as leds https://github.com/Sakura-Pi/ws2812-vleds
Emulationstation has menu items to configure led color and has an option to display battery level.