Add armbian-tm16xx: front-panel display support for fd628/tm1628 (spi-gpio) boxes#3566
Add armbian-tm16xx: front-panel display support for fd628/tm1628 (spi-gpio) boxes#3566B00StER wants to merge 1 commit into
Conversation
…oxes Boxes whose device tree binds the front panel via the tm1628/fd628 spi-gpio binding (e.g. X96 Max / S905X2) have a dark panel: the DTB instantiates the SPI device but the kernel ships no driver for it, and armbian-openvfd's module-parameter path can't create a device on 6.x kernels (and targets the same GPIOs the spi-gpio node already claims). armbian-tm16xx (sibling of armbian-openvfd) builds and DKMS-installs jefflessard/tm16xx-display, which binds to the existing DTB node with no device-tree changes, then enables the upstream display-service. Provides install/status/remove. Verified on X96 Max (S905X2), kernel 6.18.33-ophub. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Hello, and thank you for sharing your work. Since I don’t have a compatible device, I can’t verify whether the script works correctly. If you have the hardware, could you please help with the following?
I read your description as well as the driver’s repository documentation, but I still couldn’t find an explanation of whether this driver is mutually exclusive with openvfd, or if the two can coexist. You also mentioned that the driver can be added directly to the kernel source tree, allowing it to be built into the kernel for easier use. Have you tested this with the 6.18.y kernel? If you’ve already verified that it works, could you submit a PR with the kernel changes? I’ll test it on my side. Mainline kernel source: |
|
Thanks for taking a look, and for the clear questions. Answers below. 1 and 2 (install process, before/after photos). This is on a Vontar X96 Max (S905X2) running your Armbian image, kernel Full install run (x96-repro.log)3 (openvfd vs tm16xx: they're mutually exclusive). Both drive the same physical panel over the same bit-banged GPIO lines (on the X96 Max, CLK/DAT/STB = GPIO 64/63/10), so only one can be active. tm16xx binds to the 4 (building into the 6.18.y kernel). The driver is jefflessard's tm16xx, currently in mainline review under auxdisplay (series). What this PR ships and what I've tested is the out-of-tree DKMS build against your 6.18.33 headers, verified across a reboot and a kernel-update rebuild. I haven't built it in-tree against |
|
The follow-up with some photos: Dark panel (LEDs off): Active panel (displaying the clock): More panel activity (Clock, along with the "Card" icon indicating activity of the mmc0 device): |
|
According to the Additionally, I would like to understand more about how Finally, to make it easier for users to understand, use, and debug this new LED control panel tool, could you provide a corresponding usage and debugging guide for |
2 participants
Add
armbian-tm16xx: front-panel display support for fd628/tm1628 (spi-gpio) boxesProblem
On Amlogic boxes whose device tree describes the front panel via the
tm1628/fd628spi-gpiobinding (e.g. X96 Max / S905X2,meson-g12a-x96-max.dtb), the panel stays dark out of the box:spi0.0, compatiblefdhisi,fd628/titanmec,tm1628) but the kernel ships no driver that bindsto it (no
CONFIG_TM16XX/FD628, no module);armbian-openvfdpath can't help: itsmodprobe-parameter devicecreation doesn't fire on current (6.x) kernels (so
/sys/class/leds/openvfdnever appears and it prints a misleading
SUCCESS), and it targets the sameGPIOs the DTB's
spi-gpionode already claims.Full diagnosis (evidence + reproduction) is in the companion issue #3567.
Change
Adds
armbian-tm16xx(sibling ofarmbian-openvfd) underbuild-armbian/armbian-files/platform-files/amlogic/rootfs/usr/sbin/.It builds and DKMS-installs Jeff Lessard's maintained out-of-tree driver
jefflessard/tm16xx-display,which binds to the existing DTB node with no device-tree changes, then
enables the upstream clock/status
display-service.Details handled by the script:
git/dkms/build-essential; checks kernel headers are present;/usr/src/tm16xx-1.0) — keypad omitted,and a trimmed Kbuild so the build doesn't pull in the other auxdisplay drivers
the ophub kernel config enables;
…/updates/(so the bundled exportingline-displayoverrides the kernel's stub) and
depmod;tm16xx_spivia/etc/modules-load.d/(the device'sspi:fd628modalias doesn't match the module's
spi:tm1628, so coldplug won't auto-load;it binds via OF-compatible once loaded);
display-servicefor the clock + status icons.Because it's DKMS with
AUTOINSTALL=yes, it rebuilds on kernel changes.Testing
Verified on a Vontar X96 Max (S905X2), ophub Armbian, kernel
6.18.33-ophub:spi0.0driver →tm16xx-spi;/sys/class/leds/display+ icon LEDs present;display.serviceactive, panel shows the clock with blinking colon;dkms status→ installed).Notes / alternatives for maintainers
tm1628/fd628driver inthe ophub kernel (
ophub/kernel, e.g. carry this driver +CONFIG_TM16XX=m)— the DTB is already correct. This PR is the self-contained image-side option
that needs no kernel rebuild and works on existing installs.
armbian-update(not dpkg), so DKMS'sautoinstall hook may not fire on a kernel change; users may need
dkms autoinstall(with the new kernel's headers installed). Could be wiredinto
armbian-updatein a follow-up.fd628/spi-gpiobinding.armbian-openvfdto detect a missing/sys/class/leds/openvfd(instead of printingSUCCESS) would avoid themisleading output.