Jump to content

Help wanted to test a new OpenVFD alternative

Jean-Francois Lessard
 Share

Recommended Posts

Jean-Francois Lessard

Jean-Francois Lessard

Posted
Posted

Hi

 

I've made a new kernel Auxiliary Display Driver for TM16XX and compatible LED controllers. This driver supports various LED controller chips, including TM16XX family, FD6XX family, PT6964, and HBS658. It provides support for both I2C and SPI interfaces.

 

I wanted it to manage the hardware on the kernel space while having an easy sysfs user space interface. It also aims to reduce the code to maintain by relaying on existing kernel features instead of recoding them. Plus, you can switch to hardware i2c/spi (instead of software gpio) depending on the pins used.

 

You can use "vfdconf-convert" to convert your existing vfd.conf to its device-tree version.  Or you can use the already converted vfd.conf of https://github.com/arthur-liberman/vfd-configurations that are listed in the device table.

 

You don't need to manually edit your device tree, the "make" command will apply the device tree source overlay to your dtb.

 

It comes with a service written as a simple bash script. So it's easily customizable without having to write custom C code.

 

Instructions and source code at https://github.com/jefflessard/tm16xx-display/

 

Could you please give it a try and report your feedback? 

2
Link to comment
Share on other sites
ning

ning

Posted
Posted

it's on i2c4. I don't see I2c error during probe. please let me know what to do next!

  

&i2c4 {
        status = "okay";

        vfd@24 {
                compatible = "fdhisi,fd6551";
                reg = <0x24>;

                tm16xx,digits = [04 03 02 01];
                tm16xx,segment-mapping = [03 01 02 06 04 05 00];

                #address-cells = <2>;
                #size-cells = <0>;

                led@0,0 {
                        reg = <0 0>;
                        function = LED_FUNCTION_ALARM;
                };

                led@0,1 {
                        reg = <0 1>;
                        function = LED_FUNCTION_USB;
                };

                led@0,3 {
                        reg = <0 3>;
                        function = "play";
                };

                led@0,2 {
                        reg = <0 2>;
                        function = "pause";
                };

                led@0,4 {
                        reg = <0 4>;
                        function = "colon";
                };

                led@0,5 {
                        reg = <0 5>;
                        function = LED_FUNCTION_LAN;
                };

                led@0,6 {
                        reg = <0 6>;
                        function = LED_FUNCTION_WLAN;
                };
        };
};

 

0
Link to comment
Share on other sites
Jean-Francois Lessard

Jean-Francois Lessard

Posted
  • Author
Posted

All LEDs should be on when you probe the driver, before writing to sysfs LEDs. You can also enable debug to see what bytes are being written to the controller.

 

```

 

systemctl stop display

 

make debug module-install

rmmod tm16xx

# clear previous kernel logs

dmesg -c > /dev/null

 

modprobe tm16xx

# you should see all LEDs ON

 

# check probe logs 

dmesg -c

 

echo 1 > /sys/class/leds/display\:\:lan/brightness

# you should see only LAN led on

 

# check new logs

dmesg -c

 

```

 

You can paste the probe logs here so I can see what is happening on the wire

 

0
Link to comment
Share on other sites
ning

ning

Posted
Posted

I checked your code, the i2c address is correct, brightness register is correct. dig registers are correct.

 

it should work, but no.

 

I don't know why, let me check fd6551's VDD.

 

if there no power, will it answer I2C command, I2C write should return -1, but no error in dmesg.

0
Link to comment
Share on other sites
Jean-Francois Lessard

Jean-Francois Lessard

Posted
  • Author
Posted

i2c slaves usually responds with ACK. But maybe rockchip hardware i2c doesn't check this. Of course, if there is no VDD to the controller, this would have to be investigated first.

 

Otherwise, just throwing some ideas here:

 

1. It might be a problem with hardware i2c. You could use software i2c to validate this assomption. By keeping i2c4 disabled and configuring i2c-gpio instead (example template here). Using i2c-gpio, you should see if controller doesn't not ACK in dmesg.

 

2. May be an issue with the led controller identification. For example, some magicsee-n5 boards have the fd6551 chip but use brightness commands of the fd655 chip. You could try setting compatible to "fdhisi,fd655".

 

In anyway, it would be easier to start from a known working configuration. Since you don't have an OpenVFD vfd.conf, would you mind sharing the Android dtb from the original firmware?

0
Link to comment
Share on other sites
ning

ning

Posted
Posted

after read spec, 7 SEG pins for 7 LEDs (LAN, WIFI...etc) and 4 DIG pins control 4 digital.

 

5 DIG pins are controlled by 66h~6eh, while 4 digitals

 

how to control seg pins? use 1 DIG pin? I guess Yes. each digital has 7 LEDs, and there also 7 Seg LED.

 

write number to DIG register, at least 1 LED will on.

 

OK. 1 DIG pin controls 1 digtal, and each digital has 7 seg, 1 seg connects to 1 SEG pin.  there are 5 digitals (one virtual), and they share SEG pins.

 

So let me check VDD.

0
Link to comment
Share on other sites
Jean-Francois Lessard

Jean-Francois Lessard

Posted
  • Author
Posted

After reviewing your original dtb I found that i2c4 is disabled (i2c@fe5d0000 uses pinctrl with phandle <0xdd>).

 

But 2 pins are defined on the top level fddis_dev:

```

fddis_dev {

  fddis_gpio_dat = <0x35 0x0c 0x00>;

  fddis_gpio_clk = <0x35 0x0b 0x00>;

  compatible = "fddis_dev"; status = "okay";

};

```

 

This means that original firmware uses software i2c. So start with i2c-gpio first. Once everything works then you could later try moving to hardware i2c if you like.

 

Please try the conf I've created for you. It already has this pin definition: rk3566-h96-max-v56. 

0
Link to comment
Share on other sites
ning

ning

Posted
Posted 
	i2c1 {
		/omit-if-no-ref/
		i2c1_xfer: i2c1-xfer {
			rockchip,pins =
				/* i2c1_scl */
				<0 RK_PB3 1 &pcfg_pull_none_smt>,
				/* i2c1_sda */
				<0 RK_PB4 1 &pcfg_pull_none_smt>;
		};
	};

phandle 0x35  is gpio0

0
Link to comment
Share on other sites
Berserker

Berserker

Posted
Posted (edited)

On step make install error

Скрытый текст

root@rk3318-box:~/tm16xx-display# make install
make EXTRA_CFLAGS="" -C /lib/modules/6.8.11-edge-rockchip64/build M=/root/tm16xx-display modules
make[1]: Entering directory '/usr/src/linux-headers-6.8.11-edge-rockchip64'
make[3]: *** No rule to make target 'scripts/mod/modpost', needed by '/root/tm16xx-display/Module.symvers'.  Stop.
make[2]: *** [/usr/src/linux-headers-6.8.11-edge-rockchip64/Makefile:1873: modpost] Error 2
make[1]: *** [Makefile:240: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.8.11-edge-rockchip64'
make: *** [Makefile:28: module] Error 2
 

sory i have rk3318 4gb ram and fd628, box name t9

Edited by Berserker
0
Link to comment
Share on other sites
L Jumadi

L Jumadi

Posted
Posted

Trying to seek solution it seems it depend very much on overlay which is new implemented in armbian, especially for my TV box chip. I use dtmerge to debug overlay creation and error cant find symbol either gpio or gpiochip1 and get warning overlay map not loaded and no matching platform found.. while trying on arthur-liberman give compilation error also

 

0
Link to comment
Share on other sites
L Jumadi

L Jumadi

Posted
Posted

Im succeed with liberman open_vfd . Im troubled before because my box using chip / bank name different than usual aobank_chip or gpiochip. Still not inspect your code further but if you not using the chip_name config then its not compatible with my box

0
Link to comment
Share on other sites
jock

jock

Posted
Posted

Hello  @Jean-Francois Lessard, congratulations for the excellent driver!

I stumbled here because I started making myself an fd6551 driver , and just after I discovered you already published a fully working product, which is way more polished than mine.

 

Anyway, I did not have yet the chance to tm16xx driver, but will do soon and report here the result. I have a HK1 box with rk3318 and fd6551 chip on board.

 

 

 

 

 

1
Link to comment
Share on other sites
jock

jock

Posted
Posted

In the meantime I integrated the driver into armbian for rockchip64 targets: https://github.com/armbian/build/pull/7338 , so it will be a bit easier to test it out-of-the box and it would also be easier for amlogic people to copy-paste the driver patch and integrate the device trees as well.

 

My tests on hk1 rk3318 tv box (board silkscreen YX_RK3318) worked like a charm and the display is now pleasantly showing up-to-date date and time

 

3
Link to comment
Share on other sites
Jean-Francois Lessard

Jean-Francois Lessard

Posted
  • Author
Posted

@jock Thank you! It's always nice to know that your work is appreciated. Thanks also for the pull request. Since I can't test all configuration combinations myself, the idea was to contribute this driver to mainline Linux once there are sufficient reports of it working properly. Your pull request makes this one step closer ;)

 

@L Jumadi I am less familiar with Allwinner SoCs and it gpio driver. After looking at sun50i-h6-tanix.dtsi (line 34) and sun50i-h6.dtsi (line 352) it looks like its using a multi cell pin controller. This is not about supporting the same chip_name config as OpenVFD but rather configuring the device tree properly. I've updated https://github.com/jefflessard/tm16xx-display/blob/main/devices/tanix-tx6-allwinner-h6.dtso to use the same pin configuration as in sun50i-h6-tanix.dtsi so you can test it. I think it should works now, if not, then someone with more knowledge of Allwinner than I have would need to figure out the appropriate device tree configuration. I'll then be glad to update the device tree configuration on my GitHub to make it easier for next users.

0
Link to comment
Share on other sites
L Jumadi

L Jumadi

Posted
Posted (edited)

@Jean-Francois Lessard thanks, I try make dtb now without error. Make modules ok but when I run sudo make module-install (or make clean?) sometimes it remove build directory. then I try again it create new lib/modules/6.7.12 directory while my original 6.7.12-edge-sunxi64 still there then error but tml16xx.ko already installed on updates directory so I try modprobe it success

make service-install no error but when I check with systemtl status display it error Failed to start Display service

May be its my system that not using standar (armbian unofficial) but for libermann make and modules install all ok

Need to mention in readme.md also statement for make module make module-install make service-install as many newbie confuse

Still dunno where to check which step really make it failed

Edited by L Jumadi
add additional make clean that I also do
0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept