any idea if it will work on T95Zplus?
Unmodified - no, it uses a different LED display (other icons, perhaps different segments-to-bits map).
Also it is possible it uses a different chip to control the LED display. It is doable, but needs some work from someone with a T95Zplus and kernel programming knowledge at the same time.
Thanks, I missed this message.
Still, can't get - what kind of interface is needed? Maybe I could help somehow, if I would understand what's required.
AMLogic released a new buildroot as of 15 May 2017:
Index of /download/ARM/filesystem/Linux_BSP
What's interesting, the archive is named "..._fbdev_...". I wonder, maybe it contains the /dev/fb support that LibreELEC developers are crying about.
I don't quite get what fbdev support is required? As far as I understand, there's no way to do hardware-accelerated OpenGL via plain /dev/fb interface, am I wrong? So, to get accelerated graphics you anyway will have to use something like X11 drivers or Android drivers. Am I missing something?
Thank you for this! Is your driver something Alex started to integrate? libreelec-8.0-aarch64-vfd
Hmm, nope, this looks like a patch for the vfd driver from stock kernel.
But I don't see the vfd driver here:
linux-amlogic/drivers/amlogic/input at amlogic-3.14.y · LibreELEC/linux-amlogic · GitHub
Is this patch meant to run LibreELEC on top of the stock kernel (for which there are no sources) or what?
Also, what I see as a problem in that patch is that it references the vfd device instance number directly, e.g.:
int vfd = open("/sys/devices/m1-vfd.26/dotled", O_RDWR);
this is bad practice, as instance number may vary depending on the DTS file and is certainly different on different platforms. For example, in stock X92 kernel it's m1-vfd.15, in my kernel it's m1-vfd.14 etc. This should be either autodetected or configurable.
P.S. Here's a link to the most up-to-date original vfd driver I could find on nets:
Firmware / kernel_amlogic_meson-common |
GitLab
P.P.S. I think that patching KODI to drive the LEDs is not the best approach. Launching a small daemon (22k) directly from initramfs (in kernel.img only for supported platforms) is better, it does not impose any additional functionality on the root system.
Hello, kszaq,
I wrote almost from scratch a driver for the LED display of the X92 box. I was planning to adapt the old vfd driver, but ended up with throwing away 99% of the old ugly code.
The driver currently works with the latest (march 2017) 3.14 kernel, but theoretically should work with the older summer-2016 kernel you're using in LibreELEC. It provides 100% access to display functionality via sysfs - 7 levels of brightness, enable/disable, you can directly modify any bit of the display driver RAM, and also there's support for displaying characters on the 7-segment LED cells (X92 has 4 cells).
Also there's a lightweight daemon (named vfdd) which will drive the LED display. The daemon is pretty flexible and extensible. Currently it can display time, date (like [0501]), temperature (like [t43°]), use the available additional indicators to display disk activity ("USB" blinks when USB drive is read and "CARD" blinks when internal drive is read, for writes it blinks "APPS" and "SETUP" respectively).
Would it be possible to include it in LibreELEC? I can help with integration.
The current version is here: GitHub - anpaza/linux_vfd: 7-segment LED display driver for Linux based on PT6964, SM1628, TM1623, FD268 ICs
kszaq, is the dtb file from kernel.img used for something? I can see that the default amlogic u-Boot config is so horribly broken that it tends to use the dtb loaded for u-Boot itself when launching the kernel from emmc/boot... and you had to use the separate dtb.img for that reason, so it seems like the "secondary" thing from boot.img is always ignored?
And one more question, if you don't mind... do you have a fresh copy of drivers/amlogic/input/vfd ? I found some old copies on github but they won't compile with fresh kernels... so, before starting "fixing" three-year-old code I wonder, maybe there's a newer version somewhere?
Drats! How I missed it! Indeed, it's between 6255 and CPU! Thank you alot 
Now it'll go much better!
Update: the TX and RX names must be the other way around (e.g. TX is CPU's RX and RX is CPU's TX); other than that, works fine!
It must be some Chinese tradition to exchange RX and TX markings; I've encountered it in other chinese boards as well...
After booting it drops directly into root shell on the serial console
How you find the UART? Are they subscribed RX,TX? I have a X92, do you have info on that one?
zap Source code is in my repo, you can see my kernel config there: GitHub - kszaq/LibreELEC.tv at 8.0.1b
Thank you very much!
Have you found any means to watcth the kernel log during booting? I'm trying to build a bootable AMLogic kernel (to replace boot.img in my Android firmware in order to add some features), tried both 3.14 and 4.9, but none would boot to the point I could see something on screen. It locks up shortly after u-Boot displays the logo, and I can't understand what's wrong with it. Searched the board but couldn't find anything like UART pins, only JTAG.
kszaq, what config do you use to build the kernel, meson64_defconfig? Or the one from WeTek Play2?
