Clone woes, TX9-Pro hardware changes, openvfd config question

[rossbcan]

Hi Arthur;

Got a batch of TX9-Pro's with hardware diffs diff 1: Uses internal eth phy (100M), not external phy (1GB) - changed dtb to fix diff 2: "/sys/class/leds/openvfd/" DOES NOT exist for the many config permutations I tried

Here's what the original (extracted from android) dtb states regarding vfd: fd628_dev { compatible = "amlogic,fd628_dev"; status = "okay"; fd628_gpio_clk = <0x27 0x4c 0x00>; fd628_gpio_dat = <0x27 0x4b 0x00>; fd628_gpio_stb = <0x27 0x35 0x00>; };

...and, of course, my dtb includes vfd (and openvfd module loaded): openvfd { compatible = "open,vfd"; dev_name = "openvfd"; status = "okay"; };

On the off chance you know the relationship between android and linux GPIO pin mapping, what should I change 0x27 to? Tried 0 to 9 and 39 (0x27) unsuccessfully. I will share my dtb and config if successful.

Any ideas? Thanks; Bill

[arthur-liberman]

Are you setting the config in the DTB or are you using vfd.conf? If vfd.conf, then the config in tanix-tx9-pro-vfd.conf matches the output from the decompiled DTB.

If you make the configuration in the DTB, then you have to use the &gpio placeholder. There's also a &gpio_ao bank, but the example above is the one I mentioned above.

[rossbcan]

Hi Arthur &thanks;

Using vfd.conf. Made some progress. Dmesg now says: [ 2192.468924] OpenVFD: Version: V1.4.1 [ 2192.468952] OpenVFD: vfd_gpio_clk: #0 = 0x00; #1 = 0x4B; #2 = 0x00; [ 2192.468960] OpenVFD: vfd_gpio_dat: #0 = 0x00; #1 = 0x4A; #2 = 0x00; [ 2192.468967] OpenVFD: vfd_gpio_stb: #0 = 0x00; #1 = 0x35; #2 = 0x00; [ 2192.468975] OpenVFD: vfd_gpio0: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 2192.468983] OpenVFD: vfd_gpio1: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 2192.468990] OpenVFD: vfd_gpio2: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 2192.468997] OpenVFD: vfd_gpio3: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 2192.469004] OpenVFD: vfd_gpio_protocol: #0 = 0x00; #1 = 0x00; [ 2192.469012] OpenVFD: vfd_chars: #0 = 0x04; #1 = 0x00; #2 = 0x01; #3 = 0x02; #4 = 0x03; [ 2192.469024] OpenVFD: vfd_dot_bits: #0 = 0x00; #1 = 0x01; #2 = 0x02; #3 = 0x03; #4 = 0x04; #5 = 0x05; #6 = 0x06; [ 2192.469032] OpenVFD: vfd_display_type: #0 = 0x02; #1 = 0x00; #2 = 0x00; #3 = 0x00; [ 2192.469040] OpenVFD: Detected gpio chips: periphs-banks, aobus-banks. [ 2192.469047] OpenVFD: "periphs-banks" chip found. base = 401, pin count = 100, pin = 75, offset = 476 [ 2192.469056] OpenVFD: "periphs-banks" chip found. base = 401, pin count = 100, pin = 74, offset = 475 [ 2192.469064] OpenVFD: "periphs-banks" chip found. base = 401, pin count = 100, pin = 53, offset = 454 [ 2192.469072] OpenVFD: Skipping vfd_gpio0 evaluation (0xFF) [ 2192.469076] OpenVFD: Skipping vfd_gpio1 evaluation (0xFF) [ 2192.469081] OpenVFD: Skipping vfd_gpio2 evaluation (0xFF) [ 2192.469085] OpenVFD: Skipping vfd_gpio3 evaluation (0xFF) [ 2192.469538] OpenVFD: Select FD628 controller [ 2192.469574] OpenVFD: SW SPI 3-wire interface intialized (LSB mode)

but, display is still "boot". Running with current assumption is that vfd is write only, so no init feedback and chip select (vfd_gpio_stb='0,53,0') is incorrect. Referring to S912 data sheet, SPI CS possibilities are GPIOZ(8:10). Unsure which GPIOZ pin vfd_gpio_stb='0,53,0' relates to. Am running permutation possibilities, unless you know how GPIOZ(8:10) relates to vfd_gpio_stb.

Your feedback that android and linux TX9 Pro conf values match blow this assumption away.

Regards; Bill

[arthur-liberman]

You can't be 100% sure that they're using the hardware SPI, they could be using bit banging, software SPI. In such case they can pick whatever GPIO pin they want.

If you still have the original firmware on the box, boot it up and run cat /sys/kernel/debug/gpio in the terminal app. You can figure out the pins from that.

[rossbcan]

SOLVED. android /sys/kernel/debug/gpio sez: fd628_dev uses gpio 208, 230 and 231(dec) You state (another thread) that there is an offset of 155 tween android and Linux gpios. Where does this come from? So this corresponds to (dec): vfd_gpio_stb:53, vfd_gpio_dat:75, vfd_gpio_clk:76 (standard settings).

FYI: What I had to do to get it working is "rmmod openvfd" prior to calling "armbian-openvfd $boxnum" (ophub's script) to apply config to openvfd driver. This is new (for me) behavior. Failure to do so results in config not being applied and display remaining at "boot", despite dmesg log driver init appearing to succeed.

[arthur-liberman]

Glad to see that you got it working. I have very limited experience with armbian and openvfd, so I couldn't really give you any tips with that. The offset should be listed in the gpio output, so even when it's not 155, it should be listed in the output.