Jean-Francois Lessard

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.