Official LE Test Images for Amlogic (Kodi-19)

    • Official Post

    The Beelink devs have no more/less of a clue what the issue could be as anyone else. I've looked at their boot sources (with git history) and there's no smoking gun; the sources have the same Amlogic BSP baseline that Khadas and Hardkernel use with fairly minimal hacking to account for the normal things that are different between board vendors. I've also had them ship samples to people with the skills to hopefully figure the issue out, but those folks are full-time developers and we're asking them to investigate our weird problem for $free, so we'll have to be patient until they have some time to spare. I see "Beelink doesn't care" as a wrong statement. If they didn't care they wouldn't courier $240 products to people, or provide schematics and sources to developers who haven't signed an NDA, to help customers run an OS they don't ship and don't support.

  • The Beelink devs have no more/less of a clue what the issue could be as anyone else. I've looked at their boot sources (with git history) and there's no smoking gun; the sources have the same Amlogic BSP baseline that Khadas and Hardkernel use with fairly minimal hacking to account for the normal things that are different between board vendors. I've also had them ship samples to people with the skills to hopefully figure the issue out, but those folks are full-time developers and we're asking them to investigate our weird problem for $free, so we'll have to be patient until they have some time to spare. I see "Beelink doesn't care" as a wrong statement. If they didn't care they wouldn't courier $240 products to people, or provide schematics and sources to developers who haven't signed an NDA, to help customers run an OS they don't ship and don't support.

    Great to hear there's support by beelink above any level I'd expect from a TV box manufacturer.


    Thanks chewitt for your great efforts, mainly behind the scenes!

  • Hi there,


    Maybe a stupid question. Is for a s905 the file LibreELEC-AMLGX.arm-9.80.7-box.img.gz correct?


    I would like to try on a gxbb box a matrix build. Only add-ons will be Netflix and tvheadend client. It looks like coreelec will support only s905x up.


    From the meson project it seems like s905 has proper support from upstream, which would be great.

    Or can I build it myself, is there a special build flag needed from


    GitHub - chewitt/LibreELEC.tv at amlogic



    Thanks

  • nothing stupid here just doubts. ;);)

    1- correct: Index of /testing/9.80/


    2- correct:

    Code
    git clone https://github.com/chewitt/LibreELEC.tv.git
    cd LibreELEC.tv
    git checkout amlogic
    PROJECT=Amlogic DEVICE=AMLGX ARCH=arm UBOOT_SYSTEM=box make image

    It is useless knowledge if not shared the world.

    Edited once, last by erbas ().

  • I want to run LibreELEC-AMLGX.arm-9.80.7-box.img.gz via sdcard/usb on a minix neo u1.

    Is this possible?

    Tried everything but it doesnt boot.

    Tried: meson-gxbb-p200.dtb & meson-gxbb-p201.dtb renamed to dtb.img in root dir.

  • I want to run LibreELEC-AMLGX.arm-9.80.7-box.img.gz via sdcard/usb on a minix neo u1.

    Is this possible?

    Tried everything but it doesnt boot.

    Tried: meson-gxbb-p200.dtb & meson-gxbb-p201.dtb renamed to dtb.img in root dir.

    This method of renaming dtb no longer works in LibreELEC, in the new project.


    In the text file uEnv.ini edit the text leaving it like this.

    With the dtb of your choice as in red! meson-gxl-s905d-mecool-ki-pro.dtb

    You only need to edit the first line from the meson with your dtb, as in the model below.

    This is just a model of my box.


    Code
    dtb_name=/dtb/meson-gxl-s905d-mecool-ki-pro.dtb
    bootargs=boot=UUID=1912-1523 disk=UUID=4203177c-0035-4bfc-b7fe-974e2afcf3a3 quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0
    • Official Post

    On GXBB (S905) devices BL1 checks for BL2 in sector 1 of emmc first, then sector 512 of SD and USB media. You can install mainline u-boot to the emmc device but then you cannot partition the emmc storage with MBR/GUID schemes as these store data in sector 1 breaking BL2. You can still partition emmc and run an OS from emmc but the device MUST boot from u-boot on SD card. The Amlogic u-boot works around this stupid stupid design by using a custom partition scheme; MBR with all data structures offset to avoid sector 1. This "works" but the scheme is proprietary and not supported by any normal partitioning or formatting tools. This limitation was removed in Amlogic GXL and newer SoCs which additionally check for BL2 in sector 512 on emmc allowing MBR/GUI structures to reside in sector 1 as normal with BL2 starting from sector 512.


    ^ TL/DR; the Hub/WP2 images in that folder are experimental and created for me to test mainline u-boot. Right now the Hub image doesn't boot (locks up) and I did not test the WP2 image (need to find the box first). The box(es) boot from emmc first allways, so you need to erase vendor u-boot from the emmc first to test these images. Then (and only then) the box will look for BL2 on the SD card and boot mainline u-boot from the SD card. To be clear. Anything you find in that folder is experimental and I provide no support. If you brick your box it's your problem not my problem to figure out how to recover things.

  • Does anyone have the latest on h.265 support for this? CoreElec still cannot play simple 4k60hz video and has completely corrupt output (dusted off my "new" box from February and these basic same issues are present) so I'm totally looking to flip again.


    I also had eMMC corruption the last time I tried the LE image (from Bables) - has this been resolved?

    • Official Post

    I recently dug out the unfinished HEVC work that Maxime Jourdan started in 2019 and managed to tweak a few bits to get it to compile, and 8-bit media playback works quite well, although the decoder predates lots of the compliance work on stateful APIs so probably needs changes before things like seeking will work properly. However 10-bit media deadlocks the box immediately so there is something fundementally broken there and since the 8-bit and 10-bit code paths are firmly entangled I've had to revert the changes to have a usable image. In current state 1080p HEVC works fine on G12A and newer boxes that have the CPU grunt to software decode it, but older GXBB, GXL and GXM devices are too weak. I'm not aware of anyone working on HEVC support so I'm not expecting HEVC to improve anytime soon.


    I've never seen eMMC corruption issues so cannot comment on that.

  • I'm not aware of anyone working on HEVC support so I'm not expecting HEVC to improve anytime soon.

    That's the most sad thing. I always prefer free and open source solutions but I'm forced to use CE for 4K/10-bit content right now.

  • Hello,


    I have another question.

    One a second device (Khadas VIM 1) I want to run this version as well.


    Therefore I downloaded the Kvim1 version (LibreELEC-AMLGX.arm-9.80.8-khadas-vim.img.gz) and put it with rufus on a 128gb SD card.


    On the emmc of the VIM1 is an Android installed (VIM1_Pie_V200317).

    But Libreelec does not boot, it stays on the Khadas Boot image.


    Previously I had Coreelec with a 4.19x Kernel on another SD card, this works.


    Did I something wrong? Or did Coreelec tamper the Uboot, and I need to burn Android again to the vim to boot Libreelec?


    Thanks

    • Official Post

    Images from ~ 5 mins ago have much improved audio on G12A, G12B and SM1 devices. You should be able to play all media without encountering static (all the multi-channel audio files I have work) and multi-channel audio channel mappings are fixed. I have disabled IEC958 devices in the alsa conf as I get static pops that don't sound tweeter friendly when trying to use the "HDMI" device or pass-through; the drivers are not ready for this yet. Select the "Analogue" card listed immediately above pulseaudio.


    The same changes are in the GX device images, but I haven't done any testing to see if the revised alsa conf has a positive effect on the "machine gun noise" (buffer underrun) problem in the AIU driver.


    tavoc The "box" image is for booting devices with vendor u-boot, the "khadas-vim" image has mainlne u-boot and is for writing LE to internal emmc (overwriting the vendor u-boot).

    • Official Post

    In limited testing the revised alsa conf appears to prevent machine gun noise on GX boards. It's a workaround not a fix, but until somene figures out where the buffer underrun is occurring it will save some speakers (MGN is nasty). I'm currently hoping that LibreComputer will fund further work on multi-channel audio in the coming months, but this is still to be confirmed. Martin B is also poking around in the AIU driver to add support to Meson8 hardware, which may also help.

  • chewitt thank you for your explanation.


    The box image runs great for watching TV with tvheadend.


    I just wonder how I write the kvim1 image to the emmc. AML burn tool tells me, that your image is not valid. And it does noch Boot from SD.

    I would like to use mainline uboot as well