Problems configuring X96 Air Q1000 VFD display #8
Comments
|
The first major hurdle I've encountered in trying to configure my X96 Air LED display is setting Could you please help me configure my display for use with openvfd? Android's dmesg output tells me it is a sm1628/TM1623. I have decompiled the dtb and the relevant dts code is: Here is a photo of my X96 Air Q1000's LED:
I'm only actually bothered about using the 7-segment display bit. I don't need to the other bits to work. It would be cool to get the IR to work too, if that is supported by this driver? Thanks Arthur! |
|
I see the TM1618 controller is supported but openvfd doesn't yet seem to support the sm1628 or TM1623. Might I be able to use one of the existing controller types? I can open a separate ticket for sm1628/TM1623 support if you want? This is no longer just about docs. |
|
|
|
Based upon a closed issue, it seems I need to add something like this to my dts: This is another thing I'd like to see added to the docs that is also missing from the LE docs. In this example, the user has used gpio refs for the first values of the three gpio variables, whereas in my Android dts I have three hex values. How do I convert between the two, or how do I discover the correct gpio values? |
danboid
changed the title
|
You can ignore my request re copying the LE docs as I have found the same docs in this repo, they were just in a different dir to the LE fork for some reason so I thought they were missing. After looking through the available config files in the vfd-configurations, my guess would be that the t95-max-plus config would be the most likely to work: https://github.com/arthur-liberman/vfd-configurations/blob/master/t95-max-plus-s905x3-vfd.conf So I added these lines into my .dts: Unfortunately this config, like all the others I've tried so far (such as the X96 Max config), always results in these errors appearing in I got the same error when using the gpio values from my Android dts. |
|
What is the full error message? |
|
Hi @arthur-liberman ! My latest hacky attempt in the dts looks like this, a mish mash of configs so unlikely to work: dmesg: |
|
The rest of my dts: |
|
You cannot use the same phandle values you have in the original Android DTB. You need to find what the handle addresses are for the aobus-banks and periphs-banks, and use them in your overlay. You may or may not have to adjust the pin numbers as well, depending on the base addresses for the IO pins. |
|
|
Try |
|
Using that config gives: |
|
I'm not sure, maybe will work. If it doesn't, then it's something about the DTB, I'm no expert on that. |
|
|
|
I tried turning on and off various leds with commands like: but nothing lit up. So now that dmesg isn't complaining about GPIO configs is it safe to say we have found the correct GPIO settings and that the controller is supported and I just need to work out the correct display config or is it possible that the controller isn't actually supported despite dmesg not complaining? |
|
Did you check what chip you have on your board? SM1628 may not be the same as a TM1623. |
|
I'm pretty sure it is a TM1623. Here are some screenshots of the relevant bits of my Android's dmesg:
If that doesn't tell you what we need to know, might there be any commands I could run under Android to tell us more? Good to hear the TM1623 should be compatible with the FD628 command set, I do have a chance of getting this to work with the existing code then. |
|
That sort of output doesn't necessarily mean that you have a TM1623 or SM1628 controller. The only way to tell is to take the board out of the case and look. |
|
I've already posted a pic of my box with the case removed. Does it not show what you want? |
|
No, the chip must be on the other side of the board. It should be close to the display, with traces going between them. |
|
Looks like it uses a TM1628A |
|
TM1628A uses the same commands as FD628, so it should work. I'm pretty sure that I don't even have a datasheet for a FD628, only for a TM1628, and the code is based on it. |
|
That config isn't working for me unfortunately, despite no openvfd related errors in dmesg. |
|
Try it with CoreELEC and x96-max-1gbit-vfd.conf |
|
I tried to boot CoreELEC a few days ago specifically to see if it supported my LED with no success. I've just tried again with no luck. Apparently you need to copy the correct dtb to the root dir as dtb.img but neither sm1_s905x3_4g_1gbit.dtb , sm1_s905x3_4g.dtb (both included with coreelec) nor my own dtb make it boot. LibreELEC does boot but they don't support openvfd any more. |
|
You may have a "fake RAM" device. Try sm1_s905x3_2g.dtb or sm1_s905x3_2g_1gbit.dtb. |
|
I have got coreelec to boot and the VFD is working using x96-max-1gbit-vfd.conf |
|
I've not checked (via SSH) but I think CE is using Linux 4.9 whilst I'm trying to use openvfd with Linux 5.12 under Manjaro. Have you heard of people using openvfd successfully with recent mainline kernels such as 5.12? Have you tested openvfd on a recent kernel? |
|
I have not tested it, personally. But I'm pretty sure some people used it and it worked for them. |
|
My LED works under CE 19.2-Matrix_rc2, in fact it looks like all my hardware is working under CE (ethernet, wifi and BT) which is nice. CE 19.2 is using kernel 4.9.113. |
|
There is an annoying issue with my TV box and CE. After booting CE once, I can no longer boot any other OS via USB nor SD card so I have to reflash Android to restore my bootloader so I can boot Manjaro again. I am still able to boot Android on the eMMC. This is what happened last time I tried CE. |
|
You can post about it on the CE forum, but I don't think there's much we can do about it. |
|
I know, I'm just mentioning that for completeness sake, for those following along from home etc. |
|
Now we know that openvfd works with my hardware using the x96-max-1gbit-vfd.conf under the CE Linux 4.9.113 kernel, I adapted my dts code to supposedly be exactly like but my display still fails to show anything when I've loaded the openvfd kernel module and run If others have got openvfd to work under recent kernels then I can only presume there is something not quite right with my kernel config. What kernel features does openvfd depend upon? Might any of them not be enabled (as a module) by default? https://github.com/danboid/linux-aml-vfd My current |
|
aaaaand here's the money shot ie what it looks like on CE when working: |
|
After inspecting the two dmesg's, what stands out to me is that under CE dmesg prints: Whereas under Linux 5.12 we only see: and there is no info regarding periphs-banks and aobus-banks following that message as under the CE kernel. |
|
Both dmesg outputs indicate that You may want to try and change |
|
I'd prefer to use the dts to configure openvfd like all my other hardware but if it only works via a separate config file then so be it. If I put my openvfd config file under It would be good if openvfd also looked under |
|
As for kernel options, maybe openvfd depends upon some GPIO kernel option that I'm not building? I presume you must enable GPIO support in the kernel to use openvfd. Would it error if the kernel was missing GPIO support when starting? My kernel has the generic GPIO support/lib enabled but there are several GPIO kernel config options. |
|
You can check the CoreELEC repository to understand how the driver is loaded. |
|
I'm on the same situation with failure trying to port openvfd to kernel 5.12 while CoreElec conf is confirmed working perfectly. |
|
Well, according to #12, the pin mappings in the mainline kernel is not the same as in the amlogic vendor kernel. |
|
@arthur-liberman @danboid @tritu But mainline has no virtual pin So to get working linux_openvfd on mainline kernel you need 'vfd_gpio_clk' and 'vfd_gpio_dat' decrease by 1, 'vfd_gpio_stb' leave unchanged. Example for X96 Max+ |
Hi Arthur
Thanks for writing openvfd! I built your repo yesterday with Linux 5.12 under Manjaro ARM and I'm in the process of configuring it now.
There doesn't seem to be any docs for openvfd in your repo but I would presume that most if not all of what can be read in the README at https://github.com/LibreELEC/linux_openvfd also applies to your upstream code?
I tried to report a bug to the LE fork yesterday but I was told by one of the LE devs that their fork is dead so I think it would be a good idea to borrow and update (if required) their docs for your repo.
The text was updated successfully, but these errors were encountered: