Sorry for the late reply but I know people like us tend to store such projects for months, maybe even years waiting to get the knowledge to get further.
So yea, it should be possible. If we look at https://docs.google.com/spreadsheets/d/1U3z0Gb8HUEfCIMkvqzmhMpJfzRqjPXq7mFLC-hvbKlE/ we see that UART_A uses exactly the same pins as the RPI, so you want to connect the module exactly like on your second link with just a small but important difference: You want to connect VCC to a 3.3 V rail as the module is 3.6 V max so 5 V might kill it. On the other hand it’s 2 V min, so 3.3 V is perfectly fine.
The next thing is the hard part: Getting UART_A ready. It seem to be unsused GPIO pins but I’m not sure if you need to remove their GPIO glue from the device tree before enabling UART_A. Also it might be hard to get UART_A working but I’m not that experienced with device trees.
Lastly a question to the devs: Are device tree overlays ( https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt / https://www.kernel.org/doc/html/latest/devicetree/overlay-notes.html ) planned (to be backported) ? That would make such changes much more simple, esp. if you distribute overlays so the users would just have to enable them.
@V10lator thanks for your reply. Yes, i have connected it, but now the question is how to enable it.
is there an option like
Sadly there is no such option. You need to modify the device tree and again: I’m not that experienced there.
And in Armbian I assume it can be enabled by inserting into /boot/armbianEnv.txt:
I hope devs will update kernel and add this feature in the next releases. I am not keen moving to Armbian
Tried to include the libreelec overlay into coreelec: https://github.com/V10lator/linux-amlogic/commit/bf4d73450359f3430b48b5b6fcb48e351d4faad9 - Will need a lot of time to build and chance that it simply works is pretty low as the device tree of CoreELEC differs too much. Anyway, will edit this reply as soon as I have some results.
They won’t update the kernel but maybe backport some features from newer kernels. What we really need is a better device tree and (optional but would be a killer feature) overlay support.
//EDIT: Still compiling. Sorry that it takes so much time but I just have a very slow PC at hand right now.