X96 Max (S905X2): front-panel FD628 display dark — DTB declares the panel but no kernel driver binds; armbian-openvfd can't drive it

[B00StER]

X96 Max (S905X2): front-panel FD628 display stays dark — DTB declares the panel but no kernel driver binds, and armbian-openvfd cannot drive it

Environment

• Box: Vontar X96 Max, Amlogic S905X2 (meson-g12a), 4/64
• Image: ophub Armbian, installed to eMMC
• Kernel: 6.18.33-ophub (aarch64), BRANCH=current
• FDT: /dtb/amlogic/meson-g12a-x96-max.dtb
• Front panel: 4-digit 7-segment VFD with status icons (FD628 controller)

Summary

On a fresh install the front-panel display never lights up. armbian-openvfd 11
(x96max) reports SUCCESS but the panel stays dark. Root cause: the device tree
already describes the panel for the in-kernel tm1628/fd628 driver, but that
driver is not built into the ophub kernel, so the SPI device is created with no
driver bound. The bundled openvfd path cannot fix this on current kernels.

Root cause (with evidence)

The DTB defines the panel as an FD628 on a bit-banged spi-gpio bus, and the SPI
device is instantiated — but nothing drives it:

# the panel device exists on the spi-gpio bus, with NO driver bound:
$ ls -l /sys/bus/spi/devices/spi0.0/driver        # -> (none)
$ cat /sys/bus/spi/devices/spi0.0/of_node/compatible
fdhisi,fd628 titanmec,tm1628
$ cat /sys/bus/spi/devices/spi0.0/modalias
spi:fd628

# the openvfd platform driver loads but has zero bound devices:
$ ls /sys/bus/platform/drivers/openvfd/            # bind/unbind only, no devices

# and the kernel has the auxdisplay *framework* but no tm1628/fd628 driver:
$ grep -E 'TM16|FD628|SEG_LED' /boot/config-6.18.33-ophub
# CONFIG_SEG_LED_GPIO is not set        (no CONFIG_TM16XX / FD628)
$ ls /lib/modules/6.18.33-ophub/kernel/drivers/auxdisplay/
charlcd.ko hd44780.ko ht16k33.ko img-ascii-lcd.ko lcd2s.ko line-display.ko openvfd
# ^ no tm1628/fd628 module; modules.alias has no fd628/tm1628 entry

So spi0.0 (the FD628) sits permanently driverless → the panel is dark.

Why armbian-openvfd does not work here

1. No device is created. armbian-openvfd loads openvfd with module
   parameters (modprobe openvfd vfd_gpio_clk=… vfd_gpio_dat=…). On this kernel
   build that does not spawn a platform device — /sys/class/leds/openvfd
   never appears, so the script's echo … > /sys/class/leds/openvfd/led_on
   writes all fail and vfdservice has nothing to talk to (it still prints
   SUCCESS, which is misleading).
2. GPIO conflict. openvfd's configured pins (clk=64, dat=63, stb=10) are the
   same pins the DTB's spi-gpio node already claims (sck=64, mosi=63, cs=10), so even if openvfd did create a device it would collide with the
   in-DTB panel description.

Working fix

Jeff Lessard's out-of-tree driver jefflessard/tm16xx-display
binds cleanly to the existing DTB node (it supports fdhisi,fd628 /
titanmec,tm1628) — no DTB changes needed:

# after building/loading tm16xx + tm16xx_spi (and jefflessard's exporting line-display):
$ cat /sys/bus/spi/devices/spi0.0/driver | xargs basename   # -> tm16xx-spi
$ ls /sys/class/leds/ | grep display
display  display::apps display::colon display::cvbs display::hd display::sd display::setup display::usb
$ echo -n 1234 > /sys/class/leds/display/message            # panel shows "1234"

Two build notes on the ophub kernel:

• the repo ships the full upstream drivers/auxdisplay/Makefile; since the ophub
  kernel config enables the other auxdisplay drivers (CONFIG_CHARLCD=m, etc.),
  the out-of-tree build tries to compile charlcd.o from sources that aren't
  present — trim the Makefile to the linedisp+tm16xx objects only;
• disable the keypad sub-module to avoid a tm16xx_set_key redefinition.

After building, installing to …/updates/, force-loading tm16xx_spi via
/etc/modules-load.d/, and enabling jefflessard's display-service, the clock
and status icons work and survive reboots.

Suggested resolution

Any of:

1. Enable a tm1628/fd628 driver in the ophub kernel (ophub/kernel) — e.g.
   carry jefflessard/tm16xx-display and set CONFIG_TM16XX=m. This is the
   cleanest fix; the DTB is already correct.
2. Ship it in the image as a DKMS package so it builds per-kernel.
3. Add an armbian-tm16xx helper (sibling to armbian-openvfd) that
   clones, builds, DKMS-installs, and enables the driver — for the many Amlogic
   boxes whose DTB uses the fd628/spi-gpio binding that openvfd can't drive.

I've implemented option 3 in #3566 — it adds an armbian-tm16xx helper
(sibling of armbian-openvfd) that builds + DKMS-installs the driver and enables
the display-service. Verified working on the box described above.

Notes

• This likely affects other S905X2/X3 boxes whose DTB uses the fd628/tm1628
spi-gpio binding rather than the legacy openvfd GPIO scheme.
• armbian-openvfd printing SUCCESS while the panel is dark is itself worth a
  small fix (it should detect that /sys/class/leds/openvfd didn't appear).