Jean-Francois Lessard

Those are standard kernel patches. Do you mean Armbian build system does not support multiple patches in a single file? If so, you can download each of the 14 patches individually and then apply them. Or you can try reformatting the combined patch file as a single patch.

@dale I'm happy that it's now working! I'll add the x98h dtso to my devices library when I'll have some time (using the latest dt-bindings syntax). You can download the patch of the latest tm16xx version here: https://github.com/torvalds/linux/compare/master...jefflessard:linux:tm16xx.patch Let me know if the latest version works well for you and the updated x98h dtso (if you happen to do it before I have some time). I'll be glad to add you with Tested-by tag when submitting.

@dale looking at the openvfd_x98h.dtso file you shared, openvfd uses these pins: openvfd_gpio_clk = <&pio 2 7 0>; openvfd_gpio_dat = <&pio 2 2 0>; openvfd_gpio_stb = <&pio 2 12 0>; So you should try with their equivalent: mosi-gpios = <&pio 2 2 GPIO_ACTIVE_HIGH>; /* mosi is the same as openvfd_gpio_dat */ sck-gpios = <&pio 2 7 GPIO_ACTIVE_HIGH>; /* sck is the same as openvfd_gpio_clk */ cs-gpios = <&pio 2 12 GPIO_ACTIVE_LOW>; /* cs is the same as openvfd_gpio_stb */

@dale it seems like vfd-convert has not worked well. Perhaps because of some mix between script version and the template files version. Whatsoever, I've looked closer at the patch link you previously posted, this is the older pre-review dt-bindings syntax. You should be go to start with something like: /dts-v1/; /plugin/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> &{/} { display_client: spi { #address-cells = <1>; #size-cells = <0>; compatible = "spi-gpio"; sck-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; cs-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; num-chipselects = <1>; display@0 { compatible = "fdhisi,fd628"; reg = <0x0>; spi-3wire; spi-lsb-first; spi-rx-delay-us = <1>; spi-max-frequency = <500000>; titanmec,digits = [00 01 02 03]; titanmec,segment-mapping = [03 01 02 06 04 05 00]; #address-cells = <2>; #size-cells = <0>; led@4,0 { reg = <4 0>; function = LED_FUNCTION_ALARM; }; led@4,1 { reg = <4 1>; function = LED_FUNCTION_USB; }; led@4,2 { reg = <4 2>; function = "play"; }; led@4,3 { reg = <4 3>; function = "pause"; }; led@4,4 { reg = <4 4>; function = "colon"; }; led@4,5 { reg = <4 5>; function = LED_FUNCTION_LAN; }; led@4,6 { reg = <4 6>; function = LED_FUNCTION_WLAN; }; }; }; }; Note that I haven't tested it, just made it from some copy-paste. If it doesn't work, even partially, you would most likely need to replace &gpio with the right reference to the gpio controller wired to the display.

To anyone interested, I am seeking help to test the latest tm16xx changes for the (hopefully) final upstreaming submittal. You will find in-tree patches here: https://github.com/torvalds/linux/compare/master...jefflessard:linux:tm16xx, just suffix with ".patch" to get all patches in a single download. You will find out-of-tree version, device-specific dtso and latest display-service in the https://github.com/jefflessard/tm16xx-display/tree/v4-feedback branch. Thanks to all of you for you help so far!

@dale you need a display overlay that is compatible with tm16xx. OpenVFD overlays are NOT supported. You can read README.md and dt-bindings documentation at https://github.com/jefflessard/tm16xx-display But note that there has been many changes recently to the code base since the driver is currently in review process to be upstreamed into mainline kernel (targeting v6.18). So double check which bindings version format has been integrated into Armbian rockchip64. The GitHub repo also contains a vfd-convert utility to automatically convert OpenVFD configuration files to expected tm16xx DTSO. But : 1. It requires OpenVFD conf file, not dtso. 2. You may need to go through file history to get the version matching of what has been integrated into Armbian rockchip64.

Hi @dale What is your DTS node for your display? My first guess is that your DT node is not being picked up/inexistent since the module loads but the display device is not present. You can use dtc /proc/device-tree to see your loaded DT and find your display node, if any. Then, have you checked dmesg for any tm16xx kernel message? Then, you can ls /sys/class/leds to see if any device were created. The display-service/display-utils scripts expect /sys/class/leds/display. That should not be your issue here, but I'm not sure that aip1688 is the same as tm1628 variants. Googling aip1688 list it besides aip1618, so that would be the tm1618 variant. Whatsoever, I think you should have partial working display if using tm1628. To be 100% of which compatible string to use, we would need the aip1688 datasheet but I couldn't find it online. Good luck with your experimentation! Let me know how you results.

That should make it. You can always try to see if it works and search online if not.

Your commands looks ok, but you need to use hk1-x3, not hk1-box Your runtime device-tree do contains the display-controller under /proc/device-tree/i2c-display. So your correctly copying your dtb, but device-tree/i2c-display/sda-gpios and device-tree/i2c-display/scl-gpios shows pin of hk1-box, not hk1-x3. You also need to remove any references to OpenVFD from your device tree. This will create conflicts if you have multiple nodes using the same pins. Your dmesg also has some messages about the i2c bus on which is connected your display controller: [ 3.787786] gpio-576 (sda): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.792897] gpio-577 (scl): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 3.802509] i2c-gpio i2c-display: using lines 576 (SDA) and 577 (SCL) If course, you need to first configure the right pins by using hk1-x3 (and removing openvfd). Then you can investigate remaining i2c issues, if any.

You have checked that neither

@KrzyPacu your Android DTS confirms the pinout of hk1-x3 fd628_dev { compatible = "amlogic,fd628_dev"; fd628_gpio_clk = <0x12 0x41 0x00>; fd628_gpio_dat = <0x12 0x40 0x00>; status = "okay"; }; 0x40 is data pin 64 0x41 is clock pin 65 So there must be something wrong with how you are copying the dtb to boot. Maybe to the wrong location. Ensure you have the proper dtb loaded at runtime by inspecting /proc/device-tree

@KrzyPacu try with hk1-box.dtso instead: make hk1-box.dtb cp release/hk1-box.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot hk1-box.dtso has the same configuration as hk1-x3.dtso but with pins 63/64 instead 64/65. Original OpenVFD specify "Vontar X3" in hk1-box, not hk1-x3. If that still doesn't work, you need to start from a known working configuration, either OpenVFD or original Android firmware dtb. Then you can work backwards to understand your configuration and create the proper dtso.

@KrzyPacu Can you look at your full dmesg output (no filter on tm16xx)? I guess there are some other error messages prior to there filtered output. I don't think that you have a different controller. Maybe rather the pinout: which pins of the SoC of your TV box are wired to the controller and how they are declared in the device tree. Was your display working properly with the OpenVFD driver and the hk1-x3.conf VFD configuration file you posted? If so, the controller is good and it's probably the pin numbers described in the device tree that needs to be adjusted. My hk1-x3.dtso was converted from the OpenVFD configuration file, but the device hasn't been tested yet to my knowledge. So it might need some corrections.

No need to disassemble anything. Given your device has the same configuration as hk1-x3, you should rather use the corresponding device tree definition: make hk1-x3.dtb cp release/hk1-x3.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

What is your Android TV device model? What is the led controller model? Then what is your DTS configuration for the display client?

There should have been an exception on first load that now prevent removing the module. You can force removal of the module but that can create unstable kernel side effects. You are better to reboot the device (you may need to unplug power if kernel refuses to reboot). Then after boot, check dmesg kernel messages (do not clear them first!) something like dmesg | grep tm16xx

Have you looked for dmesg output about tm16xx after probing the driver? dmesg -c # clear kernel messages modprobe -r tm16xx # unload driver modprobe tm16xx # load driver dmesg # check for new kernel messages

Looking back at your previous output, I've just noticed something wrong. I've should have seen it first instead of pointing you to kernel headers issue. Here M should be pointing to your path to the tm16xx-display folder. I think the PWD environment variable is affected by sudo. You can specify the PWD variable explicitly when calling make: sudo make PWD=$(pwd) module-install That should make it.

@KrzyPacu it seems there is an issue with your kernel source code (or minimal headers). Ensure to install kernel headers for your distribution/version first If it still doesn't point to your headers/source path, you can pass it as a variable when executing make. Something like: sudo make module-install KDIR=/path/to/your/headers/build

@KrzyPacu Start by copying your original dtb into tm16xx-display folder: cd tm16xx-display cp meson-sm1-x96-air-gbit.dtb original.dtb # or alternatively run: make extract-dtb Then, assuming the corresponding device tree source overlay in the "devices" subfolder is "x96-max-1gbit.dtso", build the updated dtb: make x96-max-1gbit.dtb # <-- same name as the dtso file in devices subfolder but with dtb extension Finally, replace the original dtb of your boot path with the updated one (first keep a copy of your original dtb somewhere else, just in case) and reboot: cp release/x96-max-1gbit.dtb /boot/dtb/{YOUR_DTB_PATH}.dtb reboot

Hi @KrzyPacu I can only provide basic instructions without any support regarding loading overlays. It's not supported on every device (and I personally don't own a device which supports this). You can always search for other posts on device tree overlay for your device if you absolutely want to use overlays. Though, you can easily embed the device tree overlay into your dtb instead. This is what I do personally. You can check instructions of Option 2: Create an updated dtb at : https://github.com/jefflessard/tm16xx-display/blob/main/README.md#configure-the-device-tree

Hi @Mark Waples, first thanks for your detailed question completeness. It helps so much to understand your context! You need to define the other led entries in your device tree, so the tm16xx driver will know about them and it will create a corresponding sysfs led interface (i.e /sys/class/leds/display::lan/ path and alikes). Once the sysfs interface will be created, the LEDs will be controllable from user space, such as display-service does. Since the AIP650E0 controller is most likely tm1650 or fd650 compatible, it can drive a maximum of 4 grids and my guess is that it uses the 8th segment (index 7) of each grid for the LEDs (segments 0 to 6 being used for clock digits - which you reported to work). There should be no additional grid index involved since probing the module turns on all these LEDs. Try something like: ``` led@0,7 { reg = <0 7>; function = "lan"; } led@1,7 { reg = <1 7>; function = "wlan"; } led@2,7 { reg = <2 7>; function = "colon"; } led@3,7 { reg = < 3 7>; function = "usb"; } ``` First try this led device tree nodes to check if you can control these LEDs from sysfs. Then, you may need to change the grid indexes of these led entries to match your actual icons order. If required, "display-utils -c" may be used at that point to check that led name matches the icon (ex: LAN icon is ON while "LAN" text is shown on the digits). Then you should be good to go! Please report success or failure. Thank you.

@SpellKilleR you should see "Operating in transposed mode" in dmesg, if not it's either that the flag is not correctly set or you are running an older version of the code For the flag, it should be in the display controller node such as in this example: https://github.com/jefflessard/tm16xx-display/blob/ecacbdcf7963c7480bf69d1afe0c5c57bff57d46/devices/x96-max.dtso#L26 To get the latest code version either clone or pull https://github.com/jefflessard/tm16xx-display.git

@SpellKilleR it looks like you may need the transposed flag: https://github.com/jefflessard/tm16xx-display/issues/4

I should have specified that it's how to configure kernel command line parameters with the amlogic devices I own. The boot process is slightly different for these devices. I'm glad you found a way to make it work with your device anyway. With amlogic, there is also a '/boot/armbianEnv.txt' file that can be edited but it doesn't pickup command line arguments from there (as opposed to other Armbian versions). Don't you have such a file with your Armbian version? It may be an acceptable solution to edit the file after installation.