Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from tomaszc

    Some time ago, there was a post on LibreElec and Collabora Twitter about work on a driver for Mali T760 and newer. If the driver is created and working, will it be possible to hardware decode without HEVC, just using this driver ( something like hwdec=auto in mpv) and solve the video rewind issues? - I don't quite understand how currently HEVC uses GPU hardware decoding if we don't have drivers.

    No. In the x86 world the "Graphics Card" sort of combines everything into one device. In the ARM world GPU and VDEC are totally separate things. In an Amlogic box the Mali GPU (Panfrost or Lima drivers which are upstream and work great) accelerates rendering of the Kodi GUI via OpenGLES (squares and triangles are being drawn on the screen via maths) and an IP block on the core SoC (S905 etc.) decodes video frames for rasterising to a DRM (digital rendering manager) device like an HDMI tranceiver.

    Fixing HEVC is going to be a lot of work as the older and newer hardware generations are quite different. I'm not going to go into too many details just yet, but there is a plan of sorts forming on how to get some of the outstandinig issues resolved (and who will do the work). It's unlikely to be quick though, so we have to be a little patient.

    The progress so far is pretty impressive, haven't done extensive testing. But it appears GXL S905D is working well, I'll have to give it a bit more of a go next week and see what shakes loose (other than the "shimmer" issue, playback of h264/hevc samples indicated DRMPRIME and nothing was noticeable). RPi4 is my daily driver, but I have a Vero 4K+ in my home office for background noise while working.

    Is Amlogic actually upstreaming any of their newer devices? Or are they going the Realtek route?

    Quote from frakkin64

    Is Amlogic actually upstreaming any of their newer devices? Or are they going the Realtek route?

    Amlogic recently started upstreaming support for S805X2 which is one of their latest budget chips, but it's a cut-down version of S905X4 so in theory that should be useful - they are still making the decision about whether to upstream S905X4 too, but the differences shouldn't be too significant so I hope they do. Regarless, it will be a slow process as their downstream code style is often old/outdated and overal quality is low so it takes many iterations of patches to raise standards to the point where the kernel maintainers will accept things. I'm also expecting them to focus on support for the core board systems only and make no attempt to upstream the media parts. That's a good/bad thing; it's it's the thing we need most, but their downstream drivers are extremely complicated with lots of features and the lack of anything upstream creates the opportunity to apply the "less is more" principle and implement only the capbilities we actually need. Anyway, it's early days and I don't expect to boot LE images on latest generation hardware anytime soon.

    Quote from chewitt

    That's a good/bad thing; it's it's the thing we need most, but their downstream drivers are extremely complicated with lots of features and the lack of anything upstream creates the opportunity to apply the "less is more" principle and implement only the capbilities we actually need.

    Yes, that is good news indeed. I wonder if the work already done has forced their hand or maybe Google did. I would think some of the mainline work would complicate porting forward their code base.

    A few things I noticed so far are:

    - Wireless seems to runs at maybe 1/3 speed, 80~96Mbit/s on a 5GHz channel @ 80 Mhz, should be around ~225 with CE. Wondering if the SDIO bus is driven at a lower clock frequency and maybe DTB tweaking would solve it? Running with the p231 DTB for the Vero 4K+. There are complaints about the CLM blob & firmware files, not sure if that is relevant or not, it is a Broadcom 43455 according to the drivers on both CE & LE. But it does work.

    - MPEG2 HW decoding doesn't display anything (maybe not implemented?), but H264 & H265 seemed to be fine.

    Edit:

    Wireless slowness is probably related to this:

    [ 16.337223] meson-gx-mmc d0070000.mmc: unaligned sg len 304 blksize 512, disabling descriptor DMA for transfer

    kworker is running 8% CPU, sounds like it is bit-banging the SDIO bus. I did get the SDIO bus (mmc2) into SDR104 @ 200MHz, it was HS @ 50MHz with the p231 DTB.

    Edited once, last by frakkin64 (January 17, 2022 at 2:12 PM).

    Quote from chewitt

    No. In the x86 world the "Graphics Card" sort of combines everything into one device. In the ARM world GPU and VDEC are totally separate things. In an Amlogic box the Mali GPU (Panfrost or Lima drivers which are upstream and work great) accelerates rendering of the Kodi GUI via OpenGLES (squares and triangles are being drawn on the screen via maths) and an IP block on the core SoC (S905 etc.) decodes video frames for rasterising to a DRM (digital rendering manager) device like an HDMI tranceiver.

    So since we have Mali GPU drivers (Panfrost or Lima) as I understand open source from Amlogic, what is Collabora working on? To fix HEVC?

    frakkin64 Amlogic's codebase of forward-ported stuff started to mingle with the upstream codebase in their latest BSP release based on Linux 5.4, but for now they only adopted some things like crypto acceleration drivers which are quite simple. Otherwise it's simple, their kernel defconfg compiles their drivers, not the upstream ones, and everything remains separate. Over time I'd expect to see them align on core board support (which their developers are upstreaming) but they will keep all the media bits separate.

    The clm blobs allow a board manufactuer to tune the wireless card for their specific implementation so they are board (not card) specific and thus not appropriate to use generically in "distro supports many boards" scenarios. It's a little different with e.g. RPi4 where we pull the firmware blobs from a repo dedicated to RPi firmware and we know they are only used with the correct board hardware. Lack of clm blobs is not the issue and the 'error' is harmless.

    See https://github.com/torvalds/linux…a3c0cb287f6e223 for some history on the alignment message. I think it needs to be solved in brcmfmac? - I'll ask maintainers again. The p231 dts inherits 50MHz from https://github.com/torvalds/linux…-q20x.dtsi#L262 as most of the reference boards have slow speeds set. The solution for that might be to create an upstream board dts for Vero4+ that sets higher SDIO clock. Can you share "dmesg | paste" please.

    MPEG2 should be supported (the codec is upstream) but no idea what state it's in - I'll have to go create media to test it.

    tomaszc Collabora work on open-source Mali GPU support and also media codecs in Rockchip hardware which are derived from the same Hantro G1/G2 IP blocks that are also used in Allwinner SoC devices (so the upstream code overlaps and supports both vendors). They are not working on anything for Amlogic that I'm aware of, but we collaborate with them on other hardware.

    Quote from chewitt

    See https://github.com/torvalds/linux…a3c0cb287f6e223 for some history on the alignment message. I think it needs to be solved in brcmfmac? - I'll ask maintainers again. The p231 dts inherits 50MHz from https://github.com/torvalds/linux…-q20x.dtsi#L262 as most of the reference boards have slow speeds set. The solution for that might be to create an upstream board dts for Vero4+ that sets higher SDIO clock. Can you share "dmesg | paste" please.

    I bumped the SDIO clock to 200MHz and SDR104 timing spec. It's pushing about 125Mbit/s now. This is dmesg running on vanilla p231 without the dts changes:

    http://ix.io/3MEm

    Quote from chewitt

    MPEG2 should be supported (the codec is upstream) but no idea what state it's in - I'll have to go create media to test it.

    I can capture a Kodi debug log, but the audio decoding is running but the video just shows the media library (no playback is shown). But as it is without MPEG2 it is reasonably usable.

    frakkin64 interesting. I've submitted this series https://patchwork.kernel.org/project/linux-…/?series=605072 and in patch 3 one of the maintainers has reminded me that this change deliberately dropped SDIO speed to 50MHz:

    [4/6] arm64: dts: meson: fix mmc v2 chips max frequencies - Patchwork

    After that change (some time after) these changes were upstreamed by Khadas:

    [1/2] arm64: dts: meson: improve gxl-s905x-khadas-vim wifi - Patchwork

    [2/2] arm64: dts: meson: improve gxm-khadas-vim2 wifi - Patchwork

    And I also note that all the p212 and p231 dts files in the 4.9 vendor kernels set 100MHz (3.14 sets 200MHz) so I reckon the GXL/GXM datasheets could be wrong (have checked and it does state 50MHz).

    Can I ask you to run some proper before/after iperf tests with the 50MHz > 100MHz change (only), then a test with any other changes (and share the dts diff) and then start a new thread with the results in a post that I can link to. I'll run some smoke tests here too, and if all good I will include a bump to 100MHz (at least) and refer to the post when I resend the current p212 cleanup series.

    Quote from chewitt

    Can I ask you to run some proper before/after iperf tests with the 50MHz > 100MHz change (only), then a test with any other changes (and share the dts diff) and then start a new thread with the results in a post that I can link to.

    CE w/ 4.9 vendor kernel reports 200MHz, wonder if it is overclocked. Looked at the DTS there and it seems the MMC is using 100MHz. But I wouldn't put it past that Amlogic code to ignore the DT and just use hardcoded values. The other thing is the capabilities suggest HS200 even though sdio debug reports SDR104. In any case, I posted it over at:

    Thread

    Vero 4K+ board bring-up and testing

    @chewitt

    Comparing wireless performance between CE 19's vendor kernel (4.9) & LE 11 mainline noticing wireless performance drop-off of at least 1/. I am using a tweaked DTS based on the p231 one for testing.

    Here is dmesg, iperf3 results, and /sys/kernel/debug/{mmc2,sdio}/ios.

    LE 11 - 5.16.1 - MMC @ 50Mhz (same as p231, except for capabilities):

    http://ix.io/3MGY

    LE11 - 5.16.1 - MMC @ 100MHz:

    http://ix.io/3MGZ

    CE 19 - 4.9.113 (vendor kernel) - MMC @ 100MHz (in DT, but debug says 200MHz):

    …
    frakkin64
    January 18, 2022 at 5:11 PM

    100Mhz vs 200Mhz on 5.16 performs the same.

    Recently, my device (U2C Z SUPER, S912, meson-gxm-q200.dtb) crashes frequently.

    After testing, I found a way to trigger this.

    You will need at least these three files:

    https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_20MB.mp4

    https://test-videos.co.uk/vids/bigbuckbunny/mp4/h265/1080/Big_Buck_Bunny_1080_10s_20MB.mp4

    https://test-videos.co.uk/vids/bigbuckbunny/webm/vp9/1080/Big_Buck_Bunny_1080_10s_20MB.webm

    Next:

    - play the h264.mp4 file followed by h265.mp4

    - or play the h264.mp4 file followed by vp9.webm

    this causes my system to crash. Interestingly after reboot both h265 and vp9 played first work correctly.

    I've tested on the newest versions of LibreElec:

    LibreELEC-AMLGX.arm-11.0-nightly-20220121-224be67.tar

    LibreELEC-AMLGX.arm-10.85.0.tar (2022-Jan-21 15:02)

    Unfortunately I can't tell from which version this started happening.

    Could someone please test this, so I can know if the problem only affects my device?

    Thank you in advance.

    Funny, I was just about to post the exact same finding. I have a s912 box too and it shows the exact issue. You can play either x264 or x265 just fine but as soon as you switch the different encoder. The player would hang and crash. My box does not reboot automatically, I have to unplug and plug it back in to boot back. I don't think it is specific files but if it is encoded with x264 or x265.

    Another odd finding was what I mentioned previously about HEVC/x265 seek feature. I thought it does not work which is correct only for short videos like TV shows under 1 hour I guess. But if I play a full length movie over 90 minutes long, I am able to seek. However, seeking is still kind of flakey for some files since it will caused artifacts in playing after the seeking and would not go away until you restart the file. An update with seeking, it turns out not the duration but the resolution of x265. You can only seek with 4k resolution. If it's 720 or 1080 then it will pause.

    I notice the s912 box seems to get quite hot even if it is using HW decoding. I saw temp reaching 90C. I don't think I ever saw these AMLogic box go past 80C. If it is hitting this hot, I may have to put in a fan since the stock heatsink is not really doing that much.

    Forgot to mention but I am using 10.85

    Edited 2 times, last by hieppo (January 22, 2022 at 12:28 AM).

    The HEVC decoder has poor memory and buffer management which impacts resource usage and seeking; the legacy of it never being finished by its original developer (and beyond making the unfinished code run, nobody really touched it since). My semi-educated guess is that HEVC doesn't release CMA memory correctly and then when you play media requring a different codec the new codec can't reserve enough CMA and things start to fall (and hence a clean boot works around the issue). It all buckets under "HEVC needs work" and I also confirm MPEG2 is not working right now (packets go into the driver, nothing comes out).

    S912's have always run hot so a good heatsink is never a bad thing. I've a VIM2 + heatsink which runs around 60-65ºC so I'd be wondering what add-ons you're using that chew CPU in the background (some do) to keep cores busy.

    HEVC is the future. Actually, it is whatever newer than HEVC. But currently HEVC would be best bet most are using to encode videos. It would be nice to have it working properly than say MPEG2. I guess that is my opinion anyway, I am sure there are others that need MPEG2 over the others.

    Quote from hieppo

    HEVC is the future. Actually, it is whatever newer than HEVC. But currently HEVC would be best bet most are using to encode videos. It would be nice to have it working properly than say MPEG2. I guess that is my opinion anyway, I am sure there are others that need MPEG2 over the others.

    It would be nice to have every HW decoder working, but all we can do is wait and eventually it'll get there, I don't think anyone is setting their priorities other than folks that are paying, the rest is perhaps in their free time based on what they feel is a priority. I think the priority list is probably long, and now that a big chunk is usable we might see some community patches rolling in to close the gap.

    It pretty much is going to depend on people & manufacturers who want to run mainline, rather than the vendor kernel. CE was running 4.9.113 for few years, and just recent it seems like they managed to get a vendor kernel bump to 4.9.269 which is amazing get for those guys and probably closes the door on quite a few unpatched kernel security vulnerabilities.

    BTW, ATSC 2.0 still uses MPEG2 for OTA Broadcasts, probably looking at another 10 years until ATSC 3.0 rolls out and it will be obsolete by then.

    Do these types of bugs need to be reported somewhere or assume that the developers know about them?

    Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?

    Quote from tomaszc

    Do these types of bugs need to be reported somewhere or assume that the developers know about them?

    Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?

    Hardware decoding is handled in the kernel, so it would be a mainline kernel issue. Kodi will use hardware decoding first if it is available for the video codec, and fall back to software decoding.

    This is the site that communicates out items that are being worked on, including their WIP and TODO items:

    Kernel mainlining progress — Linux for Amlogic Meson https://gitlab.com/pages/sphinx documentation

    Everything you need to know is there on that website. You will see near the bottom:

    Quote

    Stalled WiP

    • HEVC HW Video Decoder (elyotna / narmstrong)
    • Meson GX System Suspend / Power Management (Neil Armstrong / narmstrong) (last patches)
    • convert existing devices to use the PWM LED driver to allow dimming the LEDs (Martin Blumenstingl / xdarklight) (last patches)
    Quote from tomaszc

    Do these types of bugs need to be reported somewhere or assume that the developers know about them?

    Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?

    If you've anything insightful about codecs to share, please share it. If you've just got a "this doesn't work" to report, we already know it.

    The code is in the upstream Linux kernel staging area: drivers/staging/media/meson/vdec

    Nobody is currently developing this code. That should change soon, but we have to be patient.