Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from tavoc

    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

    I believe you need to boot the device with the box img(or any other linux img that you can boot via USB or uSD), then download the kvim1 img to the device and then dd the kvim1 img to the emmc, instead of using the crap AML tools, since the the img is a raw disk img.

    Hello guys.

    I'm using a Beelink MXIII II with S905X chipset.

    Is it possible to run MATRIX on this Box?

    I do have Coreelec installed on the Box (latest nightly build).

    As far as I heard i could use the LibreELEC-AMLGX.arm-9.80.8-box.img.gz file, right?

    But what about the Device tree?

    Is it possible to copy the file in the update folder (like i said i have already coreelec installed) and boot?

    I tried it but it gives me a error message "no kernel" or "no system".

    So if it is possible is there a step by step guide how to install the image onto the S905x Beelink MXIII II device?

    The new LibreELEC img handles the device tree slightly differently then LibreELEC used to, or that CoreELEC currently does.

    Instead of copying and renaming the dtb file you have to edit the uEnv.ini file.

    in your case I believe you want to edit the line

    dtb_name=/dtb/@@DTB_NAME@@

    to look like this

    dtb_name=/dtb/meson-gxl-s905x-p212.dtb

    • Official Post
    Quote from cdu13a

    I believe you need to boot the device with the box img(or any other linux img that you can boot via USB or uSD), then download the kvim1 img to the device and then dd the kvim1 img to the emmc, instead of using the crap AML tools, since the the img is a raw disk img.

    90% correct. Boot from the box image (so you are running from SD card) then transfer the -khadas-vim.img.gz file to /storage. For the last bit you can use "emmctool w /storage/LibreELEC-AMLGX.arm-9.80.8-khadas-vim.img.gz" and the emmctool helper script will handle the uncompress, dd to emmc, then resize and rename partitions so they are ready for use and don't conflict with the partition names used on an SD card.

    NB: As a general comment for users: emmctool works on specific devices that have a -suffix image available. It is not a direct replacement for the older "installtoemmc" scripts and I have no interest in supporting "internal" installs on box devices that we don't have propper boot firmware for. It's not hard to circumvent the restriction but if you do and mess up your box, your should expect no sympathy and no help with recovering the box.

    chewitt thx

    I noticed one bug on the kvim 1.

    If there is no hdmi cable connected, or You use a hdmi switch with a different active input then the kvim1,the device don't boot.

    It hangs on the first line of the Bootlogo saying it's build forever. Even if hdmi is connected again.

    Coreelec 9.2.5 from SD boots fine without display.

    I have checked this with a ping to the machine and on coreelec a vnc plug-in.

    Sadly I have no log from the bootprocess, can't find my serial console cables.

    But I could try, it should write to the tx pins?

    Edited once, last by tavoc (January 8, 2021 at 11:23 PM).

    The kvim1 does not boot without hdmi cable using the box image from a SD card with the vendor u boot.

    Installed to emmc is the latest khadas android build.

    I will try to get a log in the next days

    The system don't even react to a ping. Therefore no SSH connection is possible.

    I will try to install a vnc plug-in as well, and see if I can connect, but I doubt it.

    Quote from chewitt

    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.

    Dear chewitt ,

    @JFL from Beelink's forum found a solution to kernel panic of mainline version.

    With u-boot.ext file linked below gtking pro boots and runs properly from usb on otg port.

    I would like to inform you, but I think you already knew it.

    Did you compiled this u-boot.ext, if yes how can we re-compile it for sdcard boot?

    for_linux-vim-5101.tar — Yandex.Disk

    Kind regards,

    • Official Post

    darkstar Chainloading mainline u-boot is not a "solution" it is a "workaround" and the root cause of the problem is still not known. AFAIK the .ext file should not need to be recompiled for SD card boot because it is the unsigned u-boot.bin binary with no embedded device-tree, and thus to run it you've already booted (via vendor u-boot) past the point where SD/eMMC selection is in play. As there is no device-tree embedded the file should be usable on more than one device, but is probably SoC generation specific, e.g. GXBB, GXL/GXM, G12A/SM1, G12B might need different files. I'm personally not too interested in using this approach although the current LE "box" image will see/use the file if present. NB: I've also upstreamed support for GT-King/Pro allowing people to run mainline u-boot from eMMC on these devices, particularly for Armbian where people are more keen/willing/able to do that. Those patches will be in-tree once the merge window for U-Boot 2021.04 opens, and they are included in my 2021.01 fork. I'm still hopeful that one of the kernel maintainers we shipped hardware too will be able to pinpoint the real problem and solution.