Posts by jernej

    OrangePi 3 is reasonable choice, everything works great except ethernet may from time to time not come up at boot. But this may be fixed by ATF update I should do. This is actually the board I test more often.

    Yes, graphics is the same as on S905X3, but as I said, mesa is just now getting proper support for it. However, there are binary driver available but I always prefer mesa over them. In the past already happen that binary drivers weren't totally compatible with another SoC and SoC designer refused to release appropriate variant due to various reasons.

    My recommendation would be H6, at least from Allwinner. There is still a lot of potential to unlock while already mostly on feature parity with older ones. To be honest, I don't think you need more than 3 GiB of RAM. I'm still working with 2 GiB and even 1 GiB boards and I don't see any downside. Regarding hot cpu - most cheap H6 boxes are crap because they lack precise CPU voltage management. This tends to cause higher temperatures due to higher voltage used. Additionally, in the future, H6 will get its own LE kernel settings (currently shared with other 64-bit Allwinner SoCs), which will also allow lower temperatures (at least in theory).

    Ok, I'll prepare H6 update soon. BTW, H616 can't be supported at the moment. It's pretty different SoC and there is no documentation nor sources available for it. Also it's uses newer GPU which is just now getting support in mesa.

    as far as I understand Allwinner always tries SD first.

    Unless secure boot is enabled. In that case eMMC has higher priority. However, I'm not sure how to check for secure mode. If it is really enabled, I'm not sure if it is possible to run third party images.

    Well, depends on your audio setup. AVR users usually prefer that audio encoded in codecs mentioned in OP are decoded on AVR instead on ARM board. I tested this on my TV where there is no real difference where audio is decoded except that TV tells me which audio codec is used in information panel and in case of Atmos I also get visible notification. However, if there is an issue and passthrough is enabled for unsupported codec on your device, you will probably get "machinegun" noise which can even damage your speakers.

    Finally there was some momentum to crack audio passtrough support on mainline kernel. Thanks to the RPi4 effort, I gained better understanding what needs to be done. I believe that first variant is ready to be tested.

    What works:

    DTS, Dolby, Dolby+, DTS-HD MA, Atmos

    What doesn't work:

    - If screen resolution is set to other than 1080p @ 60 Hz audio dropouts may happen.

    Before you begin:

    - make sure you have selected digital HDMI output in audio settings

    - enable audio passthrough and specific codecs in audio settings

    Test updates for A64, H3 and H6 can be found here (currently based on LE 10.0.1):

    Index of /test/passthrough/

    (other updates can be added on request)

    Source:

    https://github.com/jernejsk/LibreELEC.tv/commits/passthrough-10.0

    Please share your experience, especially if it doesn't work.

    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.

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

    My boards:

    Display Spoiler

    A20:

    OLinuXino-Lime2

    OLinuXino-Micro

    A64:

    OrangePi Win

    Pine64

    Pinebook

    PinePhone

    PineTab

    A83T:

    BananaPi M3

    H2+:

    OrangePi Zero (2x)

    H3:

    BananaPi M2+

    OrangePi 2

    OrangePi One

    OrangePi PC Plus

    OrangePi Plus 2E

    OrangePi Zero Plus 2

    H5:

    NanoPi M1 Plus 2

    OrangePi PC2

    OrangePi Zero

    H6:

    PineH64 Model A 2GB

    PineH64 Model A 4GB

    PineH64 Model B

    OrangePi 3 1 GB

    R40:

    BananaPi M2 Ultra

    RK3288:

    Tinkerboard

    Tinkerboard S

    MiQi

    RK3328:

    Rock64

    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.

    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...

    Well, thing is that there is A13 CVBS driver which might just work on A20, but I'm not sure anyone tested it on A20. U-Boot composite driver can in theory be used by Linux through simplefb mechanism (that framebuffer-lcd-tve0 node you noticed in DT) but it lacks features used by Kodi. Full blown DRM driver is needed for Kodi.

    I suggest you try to copy and fix CVBS pipeline related nodes from one of A13 DTs and see if that works.

    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.