Help wanted to test a new OpenVFD alternative

[Jean-Francois Lessard]

@L Jumadi following your finding on softdep, I've removed the /etc/modprobe.d/tm16xx.conf creation from the service-install and rather modprobe the dependent modules in the display.service as pre exec commands.

 

I think this may be a cleaner solution since there is no real dependencies between the tm16xx module and the ledtrig modules, it's really about the display service which relies on them.

 

Now, your idea of customizing the tm16xx module install to display boot is interesting! It ensure it's executed as soon as the module is loaded instead of waiting for the service to be loaded. On my side, I ended up with:

cat /etc/modprobe.d/tm16xx.conf

install tm16xx /sbin/modprobe --ignore-install tm16xx && \

/bin/echo boot > /sys/class/leds/display/value

 

I won't include this in the code base, since I prefer that full led on to be default for diagnosis purposes. But it's a nice customization worth to be noted.

[dfahren]

@Jean-Francois Lessard: First of all, thanks for your very nice tm16xx driver. I'm using it with my rather new TV box H96 Max V56. I finally managed to get all leds light up during boot. I don't use an overlay like in your source code but an amended dts file. So far so good. Now a couple of questions arose which I hope you can answer

1. I noticed that the heartbeat led starts flashing way earlier than the lights of the blue front display. Is there a way to get this tm16xx driver starting up much earlier in the boot process?
2. The display is rather dull. Is that normal? cat /sys/class/leds/display/brightness says 8
   May be we can change the dts file a bit so that the leds get more amps, is that possible?
3. Kernel messages have the following lines which bother me. Do they point to a problem later on?

   i2c i2c-6: Not I2C compliant: can't read SDA
   Jan 31 17:42:03 h96-tvbox-3566 kernel: i2c i2c-6: Not I2C compliant: can't read SCL
   Jan 31 17:42:03 h96-tvbox-3566 kernel: i2c i2c-6: Bus may be unreliable

4. The most annoying problem though is that I can't do

   didi@h96-tvbox-3566:~$ sudo echo 1 >/sys/class/leds/display::wlan/link
   bash: /sys/class/leds/display::wlan/link: Keine Berechtigung

   which means even as root I don't have permission to change an led from off to on (this is merely an example. All single leds and the 7-segments can't be switched on or off) What might cause this problem?
5. Finally the topmost segment is on when in fact the bottommost segment is supposed to. So there is a mapping problem. By the way I took the overlay dts from your repo. Maybe I can tweak the mapping but I don't know how.
6. Oh, there comes another one to my mind: Do we need pinctrl in dts or will it cause troubles down the road?

Your help is highly appreciated! All the best and

 

Cheers,

Deetsh

 

[Jean-Francois Lessard]

@dfahren thanks for your feedback. I'll try to answer your questions but they are rather broad and not strictly related to the driver itself. Plus, it's difficult to have a clear understanding without knowing your DTS configuration.

 

1. The display device is usable as soon as the tm16xx device driver is loaded by the kernel during boot (which will turn on all display LEDs at this stage, showing 88:88). There is no way to load the driver before that. Some other LEDs might be hardware controlled or configured by u-boot preloader, before the kernel is loaded, so you can't compare against these. Currently display.service loads the driver using ExecStartPre at basic.target, which is somewhat the earliest it can using systemd. There might be other ways to load the driver a couple of milliseconds before but I don't think it worths investigating. Anyway, the display-service won't show the correct local time before network and ntp will have loaded properly (local time is only available from user space, not within kernel space).

 

2. Display brightness is set by using controller specific values, there is no amps to control. You can try setting different `/sys/class/leds/display/brightness` values to see if there's a bug (0 is off and `cat /sys/class/leds/display/max_brightness` being the max value for your configured controller). If brightness is not behaving as expected, it is likely that you have not configured the right controller in your `compatible` string of the display-controller node in your DTS. You can check the controller model by looking at the controller chip on your device main board.

 

3. The display would not work with incorrect I2C SDA and SDL pins configuration. I guess that your i2c-6 is another unrelated device in your DTS. You can check which i2c device is used by your display controller using `ls -l /sys/class/leds/display/device`

 

4. "link" sysfs is not to control a led status but rather to configure some specific led trigger. You need to check specific led trigger module documentation to understand how to use these sysfs attributes. If you want to turn on or off a led without using a led trigger, you can do so:

```

# turn on a specific led/symbol

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

 

# turn off a specific led/symbol

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

```

Please refer to https://github.com/jefflessard/tm16xx-display/blob/main/README.md for tm16xx specific documentation.

 

5. Use `display-utils -a` as documented in

tm16xx documentation at  https://github.com/jefflessard/tm16xx-display/blob/main/README.md then you can update your DTS.

 

6. If using software i2c (i2c-gpio) you should not require pinctrl. If using hardware i2c, it depends on the specific hardware configuration of your device.

Edited February 1 by Jean-Francois Lessard

[dfahren]

@Jean-Francois Lessard
Thanks for your comprehensive answers. They helped me a lot, but as ill luck would have it, new questions arose ...

1. As far as I can tell, the driver is loaded at second 2.7, which is perfectly early enough for me. Once the driver is ready to operate 8888 should be visible. Well, should .. I managed to get it running once and then I changed the config or the board dts or whatever and I never reached this state again, what a sh*t! May be you can spot any error in the dts, but I have the feeling that the error lurks somewhere else.
   You are so right, one can comment accurately on my questions if there is no dts you can look at. This time I attach my full dts to this post, promised.
   BTW, like I said before, I have an H96 Max V56, which has an FD6551 on the board. So there is no confusion.
2. Rest assured, brightness is behaving as expected but is waaay to dark for me. If only those leds had white color ...
   Well I have made the led display "brighter" in a rather unconventional way -> I used a saw and sawed out a little rectangle from the front. Maybe my tv box doesn't look as pleasing as before, but the led display is much brighter now. Form follows function , ya know?! 🤣
3. Since the led display did work once, I think both SDA and SCL are configured correctly. i2c-6 is, in fact, the i2c node the kernel assigned to the tm16xx driver.
   When my tv box starts, somewhere in the kernel log I get
   1. i2c-gpio display-client: using lines 12 (SDA) and 11 (SCL)
   2. ...

   3. tm16xx 6-0024: Failed to set brightness: -6

   4. tm16xx 6-0024: Failed to initialize display: -6   (-6 is ENXIO -> no device)
      The driver simply is unable to talk to the chip and I really don't know why. BTW my kernel has version 6.12.12 and the tm16xx is not built in but is a .ko

4. Understood, I tried them and they worked, but thanks for the explanation (I found them earlier on your Github pages.)

5. Yep, later. Led display isn't working right now ... 🙂

6. I have the feeling that using pinctrl would necessitate a "slight" rewrite of your driver and at the moment my inclination to go down this rabbit hole is, well, limited...
   But the question is,if there is a pinctrl definition regarding these two GPIO lines, will this definition interfere with the definition of the gpio lines in the display-client section?
   When using pinctrl I couldn't find any way to set the baud rate used for the communication. Is it unnecessary or is there some sort of auto-negotiation?

So if you have any idea how I can arrive at a working led display again, please(!) let me know. Currently I'm at my wits end.
All the best,
Deetsh

 

P.S.: oh, there is one thing I need to ask you: Do you know a way to make testing new versions of the dts easier than building an image and downloading in the emmc?

myboard.dts

[dfahren]

@Jean-Francois Lessard
You won't believe it, but I found my error(s) ....
For the solution I had to look at the dts Paolo (https://github.com/paolosabatino/leds-fd6551) suggested in his code. I missed a line that effectively makes SDA really open-drain. However, pinctrl is not relevant in this context.

The fist line is bloody important, the second not so:
 

i2c-gpio,sda-output-only;
i2c-gpio,scl-output-only;

Although they do incur warnings in the kernel log, they are indispensable because without them, i2c signals don't reach the fd6551 controller.

 

Now everything works as expected. It shows (in fact, it showed ...) 88:88 right at the start and after that the actual time. Great!

I'm going to write a pull request for Nicolas' Github repo so that he can integrate it with the Armbian distribution.

I also edited your tm16xx source code to show 'boot' instead of 88:88, which is not my cup of tea.

You also have to make sure you compile the driver als built-in and not as a kernel object. So you get the 'boot' writing roughly around second 2.8 in the boot process when plugging in the mains adapter and this is early enough for me.
I attach all of the sources to this post. I hope you don't mind too much that I messed with your code and I apologize upfront.

 

Best wishes,
Deetsh

tm16xx_boot.c display-client-snippet.dts

Edited Saturday at 10:51 PM by dfahren
Amendments

[jock]

@dfahren

 

tm16xx driver from @Jean-Francois Lessard is already integrated in the armbian rockchip64 family patches, this is a typical device tree overlay configuration you can take as an example that is, by the way, basically similar to my (discontinued) driver

[dfahren]

@jock

Yes indeed, the driver written bei Jean-Francois is already integrated in Armbian by your patch, I know. Yes it works with the correct dts all is good. I struggled quite a bit until I arrived at the solution outlined in my last posting and I also wanted to have the writing 'boot' to show up right at the get-go in the LED line display. So I had to amend his driver a bit. 
One additional thing I could do to the driver is making the writing configurable in the dts, so that you only have to edit the text to show some other writing once the tv box boots up. This might be pretty easy, now I'm looking for some spare time ....

[watou]

@dfahren Thanks for your efforts and reports on getting the tm16xx driver working on the H96 Max V56 TV box.  I'm looking forward to your pull request for the Armbian build, but also wondering if you have step-by-step instructions for integrating the correct DTS, since the tm16xx-display README does not address boxes that are not in the Device Table.  On my 4GB box I'm running the kernel `6.12.11-current-rockchip64` and `modprobe tm16xx` does load the driver but without knowing how to work with this specific box.