Posts by darkstar

    JFL didnt find a solution, he used balbes150 Newer uboot binary from LibreElec image which seem to have fixed the issue.

    It Is your work only, It will be helpfull if you can share the source for it as I was not able to use the newer version on emmc after running the I end up in the Chainloader uboot and it is not able to find the emmc.

    Thank you for all your hard work.

    @jfl tried this new u-boot.ext and found that gt king pro can run without kernel panic with it.

    I didn't said that he solved the problem or he compiled a new u-boot.ext .

    If you want to go further on this and if I'm not wrong balbes150 is not a u-boot developer he is just compiling it for community, thanks to him...

    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.

    Thank you for your reply, we can use it as a workaround till we get a real solution that you mentioned.

    Show the link to the original source, I want to look at the "author". :cool:

    I don't know the sources link. I guessed that it is compiled by chewit or you and just wanted to ask.

    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,

    It's an image for emmc install (overwriting factory u-boot) not an image for SD/USB boot.

    Normally I'd suggest using the "box" image to boot, then erase the emmc or use "emmctool" to write the image to emmc storage. However there's an issue when booting from vendor u-boot and the mainline kernel under high I/O load (e.g. when writing the image) where the kernel deadlocks and this can leave you with broken u-boot. It's not impossible to recover from, but needs Amlogic burning tool or UART cables (the UART port is on the rear of the pro box) and a lot of faffing about to kill vendor u-boot to force boot from SD card. I've not tested it, but a possible workaround is booting from CE (which doesn't have the lockup issue) and using 'dd' to write the image to emmc.

    In general, anything with vendor u-boot should use the box image. I've mostly built the -beelink image to help the Armbian/Manjaro folks boot/run on the box using mainline u-boot to avoid the deadlock problem. LE still has the same issue, but since we are ultra-lightweight seem to mostly-avoid the problem. I had a sample shipped to one of the kernel maintainers to see if they can figure the issue out, it's beyond me, but it's a busy time of year so nothing was looked at yet. The same issue exists on all the Beelink S922X boxes.

    Thank you for kind reply, but I dont want to brake u-boot.

    I don't understand why Beelink doesn't care about this problem, they are aware of it.

    amlogic-boot-fip/gtking at beelink · chewitt/amlogic-boot-fip · GitHub

    ^ These are the FIP files that I am using, which can be used to sign a mainline u-boot image. I built mainline u-boot using the VIM3 defconfig and the signing recipe from the N2. You can use the same process to write u-boot to eMMC as any other Amlogic device.

    Dear chewitt ,

    Please forgive me for asking too much questions,

    I couldn't find bl33.bin file in your beelink/fip branch, am I missing something or should I build it from u-boot mainline repo?

    Thanks again,

    I haven't figured out the root cause and I don't have the code-level skills needed to, but I was able to build and boot mainline u-boot on a GT-King Pro and this works without the lock-ups; which points the finger at something in the vendor u-boot code; which we have incomplete sources and no git history for (to understand how Beelink modified it). The GT-King Pro also has an RS232 port on the rear of the box which makes the UART based processs of disrupting then erasing vendor u-boot less complex, but this is a million miles from a "solution" for users - it's fiddly as hell and GT-King (non-Pro) and GS-King-X need dismantling and soldering of UART pins to their boards to get equivalent access.

    Dear chewitt

    Could you share your mainline u-boot image and information how you run it?

    We can try it too on Debian & Ubuntu images with mainline kernel.

    It will help us to release Debian & Ubuntu images with mainline kernel.

    Thanks a lot,

    Kind Regards,

    This is confirmed to be a android BSP Uboot issue and not linux kernel issue.

    We should hopefully have Mainline uboot images to test which should not cause any kernel panic anymore, but for this to work user's will have to erase android bsp uboot from the emmc.

    Finally chewitt was able to figure out the issue. We will have a working linux OS on GT King & Pro and GS King X

    Goog news, thanks lets see how it will work.

    Same here with GT King Pro, mainline kernel is not stable for GT King Pro too.

    it is still in development stage, this is beta version of Libreelec.

    erbas experiment with the images in Index of / too .. I lost track of what Oleg is doing with boot scripts in his images and it's another point of reference on any issues that you see.

    Eested LibreELEC-AMLG12.arm-9.80-nightly-20200324-aeb6e84-box.img.gz image on my gt king pro.

    Boot Ok

    Sound Ok

    Video ok but Green-Blue Colour Problem still exist.

    Network Ok

    Tested Enigma 2 plugin too and it doesn't worked.

    Followed Erbas's instructions, but new problem erupted. When I insert the microSD card, and depress the "reset" button, my box boots into TWRP. Same thing if I type "reboot update" from a terminal emulator.

    I am using Alvatech's ATV ROM, which has a builtin TWRP. Just did a clean install yesterday.

    [ROM] Beelink GT-King ALVATECH Android TV - ATV (9.0 Pie) S922X - FreakTab

    Dear clarkss12,

    I'm using beelinks official firmware, if it doesn't boot to a sd/usb image just use "switch os" reboot option under android then it works for all third party firmwares.

    I have LE booting on a Khadas VIM3L with 5.4 kernel which is the same S905X3 (SM1) chipset, but the changes needed for that aren't in LE master branch nightly builds yet and due to rework on video decode and my real-world job schedule the master branch won't be usable for a while. I'll send an email to Beelink for the Android dts file and schematics. The dts won't be usable with LE but S905X3 and S922X are pin-compatible and comparing against the GT-King/Pro dts will reveal any changes. I have the GT-King/Pro devices booting the same (not quite functional) LE image. I need to find time to finish checking the schematics before sending the device-tree file upstream to the kernel. The Beelink u-boot is a sh1t to work with though. It's simple to trip into update mode but it doesn't allow enough time to detect alternative media so 9/10 times it won't boot into LE for install. Once it does it's fine, but getting to first boot is unreliable.

    Dear chewitt,

    I'm a GT King Pro user, your work is really important for us.

    Because you are the only one who works with mainstream kernel for it.

    We will patiently wait for your support thank you very much.