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?