We recommend making a buildroot image just to verify the items you need first and then piece by piece moving components of the buildroot to your own stuff.
yep, this is what I'm doing since yesterday (takes long time to compile).
would be easier to pick components from there one by one, especially than finding how to properly place compiled u-boot binary, I cooked separately, to boot sectors...
well, if you're interested, I was able to make buildroot, extract u-boot from it, kernel sources, mali driver sources, mali libraries, basically everything I needed to build stuff on top of vanilla ubuntu.
I was able to image u-boot to sd card, compile 4.9 kernel and make it boot to ubuntu 17.04 (I needed it for Kodi Leia, 16.04 doesn't fit), plus mali kernel module r7p0 and libMali.so r7p0 for fbdev, and it does even started... Unfortunately turns our 4.9 kernel has no amports and no amcodec support, meaning there is no video acceleration at all.
So much effort, based on a pure trust to document that describes both 3.14 and 4.9 kernel, so it's really easy to miss what's available for kernel 3.14 and what for 4.9.
Using kernel 3.14 on the board makes it same as odroid-c2 for me, which has a year of ahead start in terms of software... maybe HDR would make it worth it, except I don't have a TV to show it yet. =D
I really hope VPU is going to have support in any kernel more recent than 3.14, in any way. V4l2, aml_libs, whatever, any kernel interface would do.
@OverSun, I faintly recall decoding working through GST infrastructure with the buildroot. Are you sure there's no video acceleration at all? Amlogic has Android 8.0 already so I would imagine they already have codec acceleration for Linux 4.9. We will see if we can dig up something.
I'm not 100% sure, I've seen gst plugins being compiled during buildroot.
But brief look through kernel sources didn't reveal any kind of amstream code, and either "grep -R h264 *" through coplete amlogic folder returned nothing. I doubt video decoding was done in the kernel using no reference to a word "h264" at all... even in comments...
Or I really missed something, which always can be a case.
oh my god, this is not getting any easier...
I wonder how they did that, since stream layer is tightly connected to osd display layer, and frames fed to decoder are show directly on the screen, which implies that decoder should know what is screen...
I'll have a look at this, thanks, and also what gst plugins are trying to use in buildroot.
pwhoa, they actyally work! And there is video! so cool!
I'll try to assemble things together, kernel, modules, libraries and stuff.
right now something wrong is with sound, something weird is going on, aplay plays fine, but kodi either crashes or screeches to the output.
I have kernel 4.9 from buildroot working. I wouldn't call it legacy. It's not bleeding age, but it's latest LTS, and much better than 3.14 everyone uses.
It does require a lot of tuning still, sound noise, mali is strange sometimes, I didn't try CEC yet... So there are issues.
I seriously hope most of them come from a difference between libre dtb and gxl_p212_buildroot dtb that is shipped with buildroot kernel. Unfortunately I don't have much time to dig into kernel code in case there are things require code changes...
Yeah, I'll provide all the work when it can be called "usable", that's no problem. Not sure about upstreaming, this is buildroot code, not any git, I cannot do a diff to what was in buildroot and what I changed, but I'll provide kernel, mali drivers and codec drivers so they can be compiled by anyone. together with the image most probably.
Now I'm stuck at an interesting place.
I cannot really get hdmi output, which is quite funny. It seems that the only thing missing is the hdmi link description in dtb file for layer0 whatever it is.
If I do "cat /dev/fb0 > screen.raw" and then open it in graph editor - there is a picture, so kodi actually draws EGL accelerated output to /dev/fb0.
If I go to /sys/class/amhdmitx and start looking into files, I can see that the board detected my TV, there is a name of it in edid for example. So there is a link...
But screen is black and there is no output.
If I run really simple program to utilize amstream codec - there is a video on the screen, which hardware decoder produces. So the actual hdmi output workds, and osd layer of video is connected to it.
Any other cool ideas what could be wrong?..
PS: another tip, is that when I load mali module, every mmc io starts producing noise to hdmi output... I think this is the way how hardware connects to each other in dtb, that is more generic for a reference gxl_p212 and there is a difference on AML-S905X-CC
@OverSun, I am currently mostly focused on mainline things and web things. Haven't had time to play with the buildroot 4.9 much recently. If there's a difference in the device tree, maybe looking at a collapsed version of the dts from mainline would help isolate the differences? It would be weird if gxl_p212 Android runs just fine on AML-S905X-CC and there were significant differences.
@loverpi Can you please pack next releases to img.gz format - that way people will be able to burn images to SD card without unpacking them first. This is possible using Rufus on Windows and dd on Linux. Thank you.
I did everything I wanted, unfortunately kernel 4.9 is pretty sluggish compared to 3.14 when using Kodi. I don't know why exactly, but it feels odd. And there is some sound problem, aplay plays perfectly fine, but Kodi chooses such a strange mode for ALSA output that it's only noise. Should be pretty easy fixable, I didn't touch that part.
I'm going to assemble everything I did into one git repo, because more or less everything that is required is kernerl+mali+media_drivers, which all can be unified in one kernel as 3.14 does, plus a mali libMali.so. And put it to github to anyone who want to dig further.
I'll post the link after some time.
This is the one I’ve build exactly.
I did try the one you gave as a link to compare, there are really not much of a difference, and the latest one includes everything that was in previous ones.
Well, you can find my work here: https://github.com/Owersun/linux-libre,
and I'm continuing to improve it where I can, but it seems the whole thing produces really sad fps with EGL performance:
OpenGL Information
GL_VENDOR: ARM
GL_RENDERER: Mali-450 MP
GL_VERSION: OpenGL ES 2.0
[build] use-vbo=false: FPS: 45 FrameTime: 22.222 ms
[build] use-vbo=true: FPS: 41 FrameTime: 24.390 ms
[texture] texture-filter=nearest: FPS: 30 FrameTime: 33.333 ms
[texture] texture-filter=linear: FPS: 30 FrameTime: 33.333 ms
[texture] texture-filter=mipmap: FPS: 30 FrameTime: 33.333 ms
[shading] shading=gouraud: FPS: 44 FrameTime: 22.727 ms
[shading] shading=blinn-phong-inf: FPS: 30 FrameTime: 33.333 ms
[shading] shading=phong: FPS: 29 FrameTime: 34.483 ms
[bump] bump-render=high-poly: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=normals: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=height: FPS: 30 FrameTime: 33.333 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 8 FrameTime: 125.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 44 FrameTime: 22.727 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 29 FrameTime: 34.483 ms
[desktop] effect=shadow:windows=4: FPS: 59 FrameTime: 16.949 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 48 FrameTime: 20.833 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 48 FrameTime: 20.833 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 46 FrameTime: 21.739 ms
[ideas] speed=duration: FPS: 52 FrameTime: 19.231 ms
[jellyfish] : FPS: 30 FrameTime: 33.333 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] : Unsupported
[shadow] : FPS: 40 FrameTime: 25.000 ms
[refract] : FPS: 29 FrameTime: 34.483 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 40 FrameTime: 25.000 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 20 FrameTime: 50.000 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 33 FrameTime: 30.303 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 30 FrameTime: 33.333 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 18 FrameTime: 55.556 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
glmark2 Score: 33
and since this is tightly coupled to libMali.so blob (and also the thing that I'm not really a GPU engineer) I don't think this is going to be any way usable until problems with output are fixed by someone.
Also there is a problem with Kodi playback, video is falling behind audio and real time, but this is definitely can be fixed, this is just some thing inside media modules that is not that complicated to find, I just don't see a reason to do that since Kodi UI is laggy and unenjoyable in the first place.
hah, ok, accidentally listing 3.14 kernel git history for LibreELEC I've found exactly the thing that seriously improves playback.
So after my todays commit playback is smooth as butter. Which is kind of cool, I'm already testing stability of that watching some twitch streams.
If EGL issue could be solved, 4.9 kernel could be potentially used on this board for LibreELEC and other linux stuff.
Everything else seems to be really fine. Ethernet is stable, video playback is awesome, sound is also stable... 1080p60fps of world of warcraft stream for several hours, something my C2 was never able to do for a long time. As Kodi/Retro console this is a very cool machine.
For anyone to try there is only one catch, you need to do
echo 0 > /sys/class/graphics/fb0/blank
on boot to unblank display. For some reason fb0 always starts blanked by default.
And also remove kodi check in AMLUtils for no longer used omx_pts and amlvideo/freerun_mode, but this is probably is going to be merged when 18-BETA is available.
it's 1080p60, vsync is enabled. I would prefer it to stay enabled.
yes, I also noticed that, but it doesn't fit completely, some other results are 45-48 fps, which doesn't fit vsync issue.
But it does seems to be related to output, because with "offscreen" render (I don't remember the command line option name right now, but it renders to a surface that is not on screen) - fps is over 120, around 124-126 for almost all tests.
Also with resolution lowered to 720p60 fps jumps to 55-58.
I have really few understanding of AML output, for me it's really hard to play with it. If I try to disable vsync in the kernel here and there (there are really several places where it is mentioned) - something else fails to compile. AML kernel is a real mess in that matter - everything is connected to everything.
@kszaq - current master. v17 will not be compatible. there are things that are no longer available in 4.9 kernel (and media-modules) and are heavily used in v17.
I've opened one pull request to kodi master already for an obvious thing that can be merged, there is also another thing (amlvideo/parameters/freerun_mode) that is not that obvious. I'm not sure how to approach that, it no longer exists in 4.9 and not needed, but it is in 3.14 and is used...
Everything else is basically vanilla Kodi v18 master with LibreELEC changes for aml sound
@OverSun That's great to hear, perhaps it opens a way to forward-port video driver to mainline kernel until proper V4L2 support is implemented.
About freerun_mode, I think it should be enough to remove the permissions_ok = 0; line from the code. That will allow you to run Kodi on 4.9 kernel with AMLCodec initialized and keep backwards compatibility with 3.10 and 3.14 kernels.
Thanks for great tips from @kszaq I've achieved everything I really wanted from LePotato and have everything working really well for me: Mali, CEC, decoding, everything that makes a good mediacenter.
My changes to the 4.9 kernel to make it all work are in the repo mentioned earlier, I would be glad if anyone else benefit from it.
@OverSun which toolchain did you use to compile the 4.9 kernel? I get a lot of stringop-overflow errors trying to use it, unless I am doing something wrong
Comments
We recommend making a buildroot image just to verify the items you need first and then piece by piece moving components of the buildroot to your own stuff.
yep, this is what I'm doing since yesterday (takes long time to compile).
would be easier to pick components from there one by one, especially than finding how to properly place compiled u-boot binary, I cooked separately, to boot sectors...
well, if you're interested, I was able to make buildroot, extract u-boot from it, kernel sources, mali driver sources, mali libraries, basically everything I needed to build stuff on top of vanilla ubuntu.
I was able to image u-boot to sd card, compile 4.9 kernel and make it boot to ubuntu 17.04 (I needed it for Kodi Leia, 16.04 doesn't fit), plus mali kernel module r7p0 and libMali.so r7p0 for fbdev, and it does even started... Unfortunately turns our 4.9 kernel has no amports and no amcodec support, meaning there is no video acceleration at all.
So much effort, based on a pure trust to document that describes both 3.14 and 4.9 kernel, so it's really easy to miss what's available for kernel 3.14 and what for 4.9.
Using kernel 3.14 on the board makes it same as odroid-c2 for me, which has a year of ahead start in terms of software... maybe HDR would make it worth it, except I don't have a TV to show it yet. =D
I really hope VPU is going to have support in any kernel more recent than 3.14, in any way. V4l2, aml_libs, whatever, any kernel interface would do.
@OverSun, I faintly recall decoding working through GST infrastructure with the buildroot. Are you sure there's no video acceleration at all? Amlogic has Android 8.0 already so I would imagine they already have codec acceleration for Linux 4.9. We will see if we can dig up something.
I'm not 100% sure, I've seen gst plugins being compiled during buildroot.
But brief look through kernel sources didn't reveal any kind of amstream code, and either "grep -R h264 *" through coplete amlogic folder returned nothing. I doubt video decoding was done in the kernel using no reference to a word "h264" at all... even in comments...
Or I really missed something, which always can be a case.
@OverSun It looks like video decoders/encoders code has been moved outside of kernel tree: https://github.com/khadas/android_hardware_amlogic_media_modules
oh my god, this is not getting any easier...
I wonder how they did that, since stream layer is tightly connected to osd display layer, and frames fed to decoder are show directly on the screen, which implies that decoder should know what is screen...
I'll have a look at this, thanks, and also what gst plugins are trying to use in buildroot.
pwhoa, they actyally work! And there is video! so cool!
I'll try to assemble things together, kernel, modules, libraries and stuff.
right now something wrong is with sound, something weird is going on, aplay plays fine, but kodi either crashes or screeches to the output.
@OverSun, If you have the legacy kernel working, have you considered upstreaming it to Armbian? Will probably be super useful for a lot of people.
I have kernel 4.9 from buildroot working. I wouldn't call it legacy. It's not bleeding age, but it's latest LTS, and much better than 3.14 everyone uses.
It does require a lot of tuning still, sound noise, mali is strange sometimes, I didn't try CEC yet... So there are issues.
I seriously hope most of them come from a difference between libre dtb and gxl_p212_buildroot dtb that is shipped with buildroot kernel. Unfortunately I don't have much time to dig into kernel code in case there are things require code changes...
Yeah, I'll provide all the work when it can be called "usable", that's no problem. Not sure about upstreaming, this is buildroot code, not any git, I cannot do a diff to what was in buildroot and what I changed, but I'll provide kernel, mali drivers and codec drivers so they can be compiled by anyone. together with the image most probably.
Now I'm stuck at an interesting place.
I cannot really get hdmi output, which is quite funny. It seems that the only thing missing is the hdmi link description in dtb file for layer0 whatever it is.
If I do "cat /dev/fb0 > screen.raw" and then open it in graph editor - there is a picture, so kodi actually draws EGL accelerated output to /dev/fb0.
If I go to /sys/class/amhdmitx and start looking into files, I can see that the board detected my TV, there is a name of it in edid for example. So there is a link...
But screen is black and there is no output.
If I run really simple program to utilize amstream codec - there is a video on the screen, which hardware decoder produces. So the actual hdmi output workds, and osd layer of video is connected to it.
Any other cool ideas what could be wrong?..
PS: another tip, is that when I load mali module, every mmc io starts producing noise to hdmi output... I think this is the way how hardware connects to each other in dtb, that is more generic for a reference gxl_p212 and there is a difference on AML-S905X-CC
@OverSun, I am currently mostly focused on mainline things and web things. Haven't had time to play with the buildroot 4.9 much recently. If there's a difference in the device tree, maybe looking at a collapsed version of the dts from mainline would help isolate the differences? It would be weird if gxl_p212 Android runs just fine on AML-S905X-CC and there were significant differences.
@loverpi Can you please pack next releases to img.gz format - that way people will be able to burn images to SD card without unpacking them first. This is possible using Rufus on Windows and dd on Linux. Thank you.
I did everything I wanted, unfortunately kernel 4.9 is pretty sluggish compared to 3.14 when using Kodi. I don't know why exactly, but it feels odd. And there is some sound problem, aplay plays perfectly fine, but Kodi chooses such a strange mode for ALSA output that it's only noise. Should be pretty easy fixable, I didn't touch that part.
I'm going to assemble everything I did into one git repo, because more or less everything that is required is kernerl+mali+media_drivers, which all can be unified in one kernel as 3.14 does, plus a mali libMali.so. And put it to github to anyone who want to dig further.
I'll post the link after some time.
@OverSun You may want to try the latest buildroot found here: http://openlinux.amlogic.com/wiki/index.php/Arm/Buildroot/buildroot-2017-12-01/buildroot-openlinux-20171201(kernel_49)
Amlogic S805X is pin to pin compatible with the S905X and S905W except it is limited to 1080P. I would try building the p212 from this release rather than the August release to see if it alleviates some of the issues.
This is the one I’ve build exactly.
I did try the one you gave as a link to compare, there are really not much of a difference, and the latest one includes everything that was in previous ones.
Well, you can find my work here: https://github.com/Owersun/linux-libre,
and I'm continuing to improve it where I can, but it seems the whole thing produces really sad fps with EGL performance:
root@libre:/usr/src/glmark2-es2-fbdev/mali-fbdev# ./build/src/glmark2-es2-fbdev
glmark2 2012.12
GL_VERSION: OpenGL ES 2.0
[build] use-vbo=false: FPS: 45 FrameTime: 22.222 ms
[build] use-vbo=true: FPS: 41 FrameTime: 24.390 ms
[texture] texture-filter=nearest: FPS: 30 FrameTime: 33.333 ms
[texture] texture-filter=linear: FPS: 30 FrameTime: 33.333 ms
[texture] texture-filter=mipmap: FPS: 30 FrameTime: 33.333 ms
[shading] shading=gouraud: FPS: 44 FrameTime: 22.727 ms
[shading] shading=blinn-phong-inf: FPS: 30 FrameTime: 33.333 ms
[shading] shading=phong: FPS: 29 FrameTime: 34.483 ms
[bump] bump-render=high-poly: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=normals: FPS: 30 FrameTime: 33.333 ms
[bump] bump-render=height: FPS: 30 FrameTime: 33.333 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 8 FrameTime: 125.000 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 44 FrameTime: 22.727 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 29 FrameTime: 34.483 ms
[desktop] effect=shadow:windows=4: FPS: 59 FrameTime: 16.949 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 48 FrameTime: 20.833 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 48 FrameTime: 20.833 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 46 FrameTime: 21.739 ms
[ideas] speed=duration: FPS: 52 FrameTime: 19.231 ms
[jellyfish] : FPS: 30 FrameTime: 33.333 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] : Unsupported
[shadow] : FPS: 40 FrameTime: 25.000 ms
[refract] : FPS: 29 FrameTime: 34.483 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 40 FrameTime: 25.000 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 20 FrameTime: 50.000 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 33 FrameTime: 30.303 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 30 FrameTime: 33.333 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 18 FrameTime: 55.556 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 29 FrameTime: 34.483 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
glmark2 Score: 33
and since this is tightly coupled to libMali.so blob (and also the thing that I'm not really a GPU engineer) I don't think this is going to be any way usable until problems with output are fixed by someone.
Also there is a problem with Kodi playback, video is falling behind audio and real time, but this is definitely can be fixed, this is just some thing inside media modules that is not that complicated to find, I just don't see a reason to do that since Kodi UI is laggy and unenjoyable in the first place.
hah, ok, accidentally listing 3.14 kernel git history for LibreELEC I've found exactly the thing that seriously improves playback.
So after my todays commit playback is smooth as butter. Which is kind of cool, I'm already testing stability of that watching some twitch streams.
If EGL issue could be solved, 4.9 kernel could be potentially used on this board for LibreELEC and other linux stuff.
@OverSun, I will give it a go this week and contact the relevant people to see if they can do something about EGL + FBDEV.
Thanx a lot for that!
So far I'm trying CEC to get it working.
Everything else seems to be really fine. Ethernet is stable, video playback is awesome, sound is also stable... 1080p60fps of world of warcraft stream for several hours, something my C2 was never able to do for a long time. As Kodi/Retro console this is a very cool machine.
For anyone to try there is only one catch, you need to do
echo 0 > /sys/class/graphics/fb0/blank
on boot to unblank display. For some reason fb0 always starts blanked by default.
And also remove kodi check in AMLUtils for no longer used omx_pts and amlvideo/freerun_mode, but this is probably is going to be merged when 18-BETA is available.
@OverSun, A lot of your results seem to be clamped at 30FPS. What resolution are you running at? Do you have vsync disabled?
it's 1080p60, vsync is enabled. I would prefer it to stay enabled.
yes, I also noticed that, but it doesn't fit completely, some other results are 45-48 fps, which doesn't fit vsync issue.
But it does seems to be related to output, because with "offscreen" render (I don't remember the command line option name right now, but it renders to a surface that is not on screen) - fps is over 120, around 124-126 for almost all tests.
Also with resolution lowered to 720p60 fps jumps to 55-58.
I have really few understanding of AML output, for me it's really hard to play with it. If I try to disable vsync in the kernel here and there (there are really several places where it is mentioned) - something else fails to compile. AML kernel is a real mess in that matter - everything is connected to everything.
@OverSun Great to see your results. Can you tell me if you're using Kodi v17 or current master?
@kszaq - current master. v17 will not be compatible. there are things that are no longer available in 4.9 kernel (and media-modules) and are heavily used in v17.
I've opened one pull request to kodi master already for an obvious thing that can be merged, there is also another thing (amlvideo/parameters/freerun_mode) that is not that obvious. I'm not sure how to approach that, it no longer exists in 4.9 and not needed, but it is in 3.14 and is used...
Everything else is basically vanilla Kodi v18 master with LibreELEC changes for aml sound
@OverSun That's great to hear, perhaps it opens a way to forward-port video driver to mainline kernel until proper V4L2 support is implemented.
About
freerun_mode, I think it should be enough to remove thepermissions_ok = 0;line from the code. That will allow you to run Kodi on 4.9 kernel with AMLCodec initialized and keep backwards compatibility with 3.10 and 3.14 kernels.Thanks for great tips from @kszaq I've achieved everything I really wanted from LePotato and have everything working really well for me: Mali, CEC, decoding, everything that makes a good mediacenter.
My changes to the 4.9 kernel to make it all work are in the repo mentioned earlier, I would be glad if anyone else benefit from it.
@OverSun which toolchain did you use to compile the 4.9 kernel? I get a lot of stringop-overflow errors trying to use it, unless I am doing something wrong
first I've built it in aml buildroot, afterwards I was just compiling it natively on the board. It's powerful enough to do that.
@adamg Here's quick-and-dirty branch to compile LE using OverSun's kernel: https://github.com/kszaq/LibreELEC.tv/tree/Owersun_kernel_dirty
To make things visible on screen, after booting
echo 1 > /sys/class/amhdmitx/amhdmitx0/phyOh wow, thanks for that @kszaq