Nightly images for A20, A64, H3, H5 and H6 boards

  • jarda9 As lumpi said, it's not supported by SoC. Nevertheless, it should fallback to SW decoding. I'll check that...

    jernej I'd expect that an A20 isn't up to the task of soft decoding h.265? Already h.264 in 720p50 takes 2.5+ cores of my amlogic S912...

  • Probably not but better to have a lot of drops than no image at all. Anyway, this is actually needed functionality because not all socs support all request api ffmpeg codecs (speaking more broadly, not just allwinner but also others, like rockchip).

  • Probably not but better to have a lot of drops than no image at all. Anyway, this is actually needed functionality because not all socs support all request api ffmpeg codecs (speaking more broadly, not just allwinner but also others, like rockchip).

    Well, I would expect at least the sound to be fine, if not the picture.

  • First of all, thanks to everyone who has contributed really impressive work!


    I gave the latest nightly (20200703-74156da) a spin on my OrangePi One Plus (Allwinner H6) and noticed a few issues that weren't mentioned earlier as far as I can tell.


    Cold boots doesn't work if you have ethernet plugged in (freezes before LibreELEC boot splash screen) and NIC leds are behaving weirdly, connecting ethernet once its booted up works fine and most of the time rebooting also works with ethernet still connected.


    H264 10-bit/Hi10P seems broken using the PRIME render and fails falling back to software rendering. It will load and play the file (sound only) but Kodi menu will still be shown and player controls are shown. Disabling PRIME render solves this issue but also disables any kind of hardware acceleration as expected.


    cpufreq doesn't seem to work at all, looking at linux-sunxi.org suggests that support is in 5.8 (5.7 is used) so I guess this will arrive once Libreelec switches to 5.8 and if upstream dts contains required formation for cpufreq to work? Looking at the performance in software mode the cores seem to run at a pretty low frequency by default?

  • Cold boots doesn't work if you have ethernet plugged in (freezes before LibreELEC boot splash screen) and NIC leds are behaving weirdly, connecting ethernet once its booted up works fine and most of the time rebooting also works with ethernet still connected.

    This is first time I hear for such problem. Unfortunately I don't have board in question so hopefully it will be solved in upstream at one point.

    H264 10-bit/Hi10P seems broken using the PRIME render and fails falling back to software rendering. It will load and play the file (sound only) but Kodi menu will still be shown and player controls are shown. Disabling PRIME render solves this issue but also disables any kind of hardware acceleration as expected.

    HW doesn't support 10-bit H264 decoding (confirmed by AW). Kodi doesn't do SW rendering. You probably meant SW decoding but if you don't see any image, it isn't used. Currently driver doesn't report 10-bit as unsupported profile, so it tries and fails to decode it. That's why you don't see any image.

    cpufreq doesn't seem to work at all, looking at linux-sunxi.org suggests that support is in 5.8 (5.7 is used) so I guess this will arrive once Libreelec switches to 5.8 and if upstream dts contains required formation for cpufreq to work? Looking at the performance in software mode the cores seem to run at a pretty low frequency by default?

    I already included all cpufreq related patches from 5.8. However, this functionality is enabled on per-board basis. So, if no one tested it on One Plus board and submitted a patch for it then this feature will not be present in any kernel. cpufreq is one of those things that it's better to be safe than sorry. Patch is probably just one line in dts but as I said, someone must guarantee stability on all devfreq points.


    When using HW decoding and HW rendering through DRM planes (default settings) there is not much need for high CPU performance. Actually, if devfreq would work and proper governor would be set (currently it's set to performance due to shared config with other SoCs and they need it for stable SW CEC implementation), frequency would go much lower.

  • Playback is great most of the time with some green screens here and there but the strangest thing is that video menus disappear on non 16:9 vids after some time. For example, on vids with vertical bars (4:3 ratio) portion of menus that go beyond black bars are not visible but parts of title and menu that runs over area where video is running are still there while on movies which have horizontal bars title and menus are not visible at all. Guess this is issue with lima/mesa.

    This sounds like display driver issue, more specifically DE2 driver. I'm aware of one unfixed issue but it shouldn't be visible like this. I would need to reproduce it to figure it out...

  • Unfortunately I don't have board in question so hopefully it will be solved in upstream at one point.

    Hi Jernej would you mind sharing the relevant boards you are having access to for testing? Just curious which ones we can expect being supported the best.

  • would you mind sharing the relevant boards you are having access to for testing?

    My boards:

    Not all are supported by LE (A83T, R40). While I have few RK boards, I don't use them. I have enough work with AW boards :)

    Just curious which ones we can expect being supported the best.

    To be honest, I usually test only on one board for each SoC. And then, most SoCs have similar peripherals, so I usually develop features only on one SoC and transplant them to others and just do a quick test. I usually pull out other boards just when testing some specifics like wifi, bluetooth or ethernet.

  • Thanks jernej for this insight!


    Seems your strategy works out quite well after all this is probably the best Linux for Allwinners, with the best support by the maintainer by far.


    Sometimes I'd wish you had some clones for RK and AML too ;-)

  • I forgot to list OrangePi 3 board.


    Thanks for nice words! To be fair, RK and AML projects are covered with very good developers too, but they have a bit less time to work on LE. We also work together on common features and one peripheral used on those SoCs is even the same (HDMI encoder), so improvements one make directly benefit others.

  • I forgot to list OrangePi 3 board.


    Thanks for nice words! To be fair, RK and AML projects are covered with very good developers too, but they have a bit less time to work on LE. We also work together on common features and one peripheral used on those SoCs is even the same (HDMI encoder), so improvements one make directly benefit others.

    That's actually the board I'm thinking to buy as an experimenting ground for LE and Manjaro.


    Honestly for me it was always easiest to find a way to communicate with you, very normal.


    Recently I found a second home with the Manjaro ARM community, they are not kernel hackers, but one level more downstream on distribution level, closer to mere mortal linux users, but very nice community open to all aarch64 SOCs with a focus on pine and khadas and odroid ;-)


    That became now quite OT...

  • Add correct lines to scripts/uboot_helper. You have to create H2 section and add your board. Then copy project/Allwinner/devices/H3 to H2. After that, you're on your own :)

  • I wiill try but I think that is a bit 2 much for me let´s see!


    EDIT: I did the build put it ona sd card but it dont boot :( can you help ?

    Edited once, last by marine88 ().