@balbes150 LE images with Kodi-19 for S9xxx

  • MikeKL Due to recent changes in LE build system a "box" option was added for a universal build to use on non-SBC targets. balbes150 decided to remove KVIM/KVIM2 specific builds as these SBCs come with a built-in u-boot (on eMMC) and can use "box" images.

    OK So I can just drop tar I proposed into update folder on current running LibreELEC-AMLGX.arm-9.1-devel-20190512121532-df6beb1 install and switch to box image/build, with minimum effort and assume I will I be able to boot between android running on emmc and libreELEC on SD which was case until recently. (Not sure which recent LibreELEC build, boot between SD & EMMC stopped working for me)

    Thanks for explanation about "box" image, will update later this week. (Will make sure to take LibreELEC backup before attempt latest update)

    RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver

  • Which image are users installing for 905x2 devices?

    I am a bit behind in testing but want to do a bit over the weekend.


  • From earlier in the thread "ARM" seems to be the best choice, I have it working on my "X96 Max" although not usable as a media device (I use it as an emby server, given its USB3 port and 1000m ethernet) streams uncompressed 4k m2ts files with no issues. See post #521

    Edited 2 times, last by Mobigeek ().

  • From earlier in the thread "ARM" seems to be the best choice, I have it working on my "X96 Max" although not usable as a media device (I use it as an emby server, given its USB3 port and 1000m ethernet) steams uncompressed 4k m2ts files with no issues

    Thanks for that.

    Tried the Aarch64 image


    but wired NIC not working.

    Will now try the Arm image


    Also an X96 Max box here - 2GB RAM

    Edited once, last by JohnBoyz ().

  • Tried the ARM image but similar results ...... wired NIC does not work.

    I have not had a some way functional wired NIC since the last 'rii' image I tried.

    Seems these images are not compatible with the 2GB X96 Max which has a 100Mb/s NIC.

  • JohnBoyz I don't have any g12 device so I cannot tell for sure but many fixes for ethernet and audio have been upstreamed and you should see some improvement in that regard when they are integrated in the builds.

  • JohnBoyz I don't have any g12 device so I cannot tell for sure but many fixes for ethernet and audio have been upstreamed and you should see some improvement in that regard when they are integrated in the builds.


    I ref this post

    Test LibreELEC images with KODI-18 for S9xxx

    and a previous post also where the wired NIC worked with manual intervention to turn it on.

    I have been unable to test any image since as no connection available in any of them.

  • Hi Balbes150,

    did a quick check for Nanopi-K2:

    booting: ok

    config: ok

    Ethernet: ok; no WiFi (no driver, I assume)

    edit advancedsetting.xml + Passwords.xml; reboot : ok, everything noticed.

    installed pvr.vnsiserver: test HD: ok; SD ok (after setting aspect ratio to 16:9 manually)

    Video H264 1980x1080p: ok

    Video H264 720x576i self-encoded ok, downloaded: for a few seconds picture and sound are far too quick (picture quicker than sound). This leads to Audio/Video async. Another test with h/w acceleration disabled: sound ok, no picture, just plain white screen.

    Video at all times: skipping for- / backwards leads mostly into crash (Kodi.log.old: ERROR: Got MSGQ_ABORT or MSGO_IS_ERROR return true).

    That's for now. If you need futher information, let me know.

    • Official Post

    An update on some status things:

    Baylibre figured out a way to work around the SDIO issues on S905X2 which permits WiFi to work in a "hacky but should be acceptable" way and changes have ben submitted upstream. From initial unscientific testing the maximum throughput numbers are down on the same Broadcom chip on similar hardware, but they are still reasonable and better than having no WiFi at all. S905X3/D3/Y3 chips should be with distributors and manufacturers 'soon' which will kick off lots of "new model!" announcements but there's nothing really new, it's just a bug-fixed version of the S905X2/D2/Y2.

    Changes to better handle Ethernet on cost-engineered S905X2 boxes using the 10/100 internal PHY instead of 10/100/1000 external PHY are going through some iterations and testing. Once merged this should allow a single x96max device tree - the x96max-rmii variant will not be needed. If this works well people will look at porting the approach to gx devices. The mainline kernel already eliminated the 1G/2G/3G device-tree variants that complicate the initial install user experience with the legacy kerrnel. If ethernet-phy device-tree variants can be eliminated too this will be a really nice simplification for users trying to "guess the working device-tree" for their box.

    Hardware decoding on S905X2 and S922X is now working with caveats: HEVC support in g12 decoder firmware appears to be a bit different to gx and some bits need to be rethought - but doesn't make sense to do this until 10-bit HDMI support lands as that will also trigger some HEVC rework. So right now all the expected codecs for g12a/b are working apart from HEVC (and firmware is missing so playback triggers a hard crash). Amlogic's legal team have now provided a redistributable license for their vdec firmware files and they have been submitted to linux-firmware for inclusion in the 5.3 kernel. Until then we'll continue to maintain our own repo.

    Audio is now working on S905X2 with caveats: HDMI has 2.0 output with occasional drop-outs that need to be investigated. S/PDIF is not working and needs to be investigated. S922X still needs the device tree changes for N2 to be figured out, then it can be tested. Multi-channel PCM output will need some additional dw-hdmi changes - work from Kwiboo on that is being cleaned-up and should be submitted upstream soon.

    10-bit video support for dw-hdmi is now being worked on, which will also allow us to piggy-back on upstream HDR development in the kernel and Kodi at the moment. We discovered the main reason HDR changes have not been merged is the kernel maintainers requirement for a working userspace implementation to match them. Intel was using Weston/Wayland for this, but due to slow progress they have now switched their efforts to Kodi. With some LE/Kodi developer help in the last couple of weeks there is now working (still work in progress, but working) HDR support on Intel Gemini Lake hardware. This allows Intel to show a working userspace app and get the changes merged - which will trigger a cascade of HDR support work in many other GPU/SoCs (including Amlogic, Allwinner and Rockchip). One of the many positive outcomes from this collaboration is that there are now several Intel graphics developers with instructions to contribute and allocate some hours to Kodi support each month, which we think is rather fab :)

    We have identified a sponsor for development of audio support on GX hardware, but due to current commitments the sponsor and implementor have the work cannot be scheduled until Q4/19. There is still an opportunity for the Linux community to step up and work on it sooner, but given the length of time this has already gone untouched, that's unlikely to happen. At least we know there's a plan, and it's just a matter of time.

    VIM3 with an S922X chip was announced in the last week and some initial prototypes were posted to selected developers in the last few days. We have already had some "will it be supported?" Q's in the forum and the answer is; all Amlogic hardware that has an upstream device-tree in the kernel or submitted and pending merge will be supported going forwards. I'd make an educated guess VIM3 will have a device-tree fairly soon :)

    NB: Hardware decoding and audio changes will need to land in the amlogic branch in our GH repo before appearing in balbes150 images. All being well that should happen within the next week.

    Enjoy :)

    • Official Post

    Yup, those .. and any more that get added. DVB currently requires a large out-of-tree patch series that's best confined to community images until it's reworked and sent upstream (if that ever happens). General advice - on all ARM platforms - is to use USB tuners or stick a Raspberry Pi on the network (in a cupboard) somewhere as the drivers are overall better quality and you're not dependent on the whims of community development.