@balbes150 LE images with Kodi-19 for S9xxx

    hi balbes150,

    Currently using LibreELEC-ARMv8.arm-9.80-devel-20201005141105-8945356-amlgx.img.gz for my Fiberhome HG680P

    There's a problem while connecting into wifi AP, when I tried to select Connect, it's just return into network AP list, it won't connect.

    Pls look into it, it uses rtl8188fu/rtl8189fs wifi module, thanx in advance.

    Recently I found out that HEVC does not work (I'm not 100% sure when did it stop, or was it working previously at all). The following is observable on

    • LibreELEC-ARMv8.aarch64-9.80-devel-20201006082248-fe4b097-amlgx.img
    • LibreELEC-ARMv8.aarch64-9.80-devel-20200923122613-36bc7e3-amlgx.img

    using s905w HW:

    Found out these related issues:

    popcornmix/gbm branch unable to playback 4k HEVC 10-bit video but LE can

    kodi-git build script for mainline hwaccel media decoding

    Does anyone else experience this ?

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

    Got a new Ugoos AM6 box;

    tried the 20.10 aarch64 g12; kodi segfaults;

    I am able to start the box using the aarch64 g12 build from 12.10. There I get occasional system freezes after a period of time (depending on my interaction with the UI).

    On both releases I get buggy u-boot.ext HDMI attempts (vertical random color lines) and no kernel issues in dmesg.

    Anyone else have these issues or I'm doing something wrong?

    Quote from phlp11

    Got a new Ugoos AM6 box;

    tried the 20.10 aarch64 g12; kodi segfaults;

    I am able to start the box using the aarch64 g12 build from 12.10. There I get occasional system freezes after a period of time (depending on my interaction with the UI).

    On both releases I get buggy u-boot.ext HDMI attempts (vertical random color lines) and no kernel issues in dmesg.

    Anyone else have these issues or I'm doing something wrong?

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

    • Official Post

    GT-King/Pro/GS-King-X all have an issue with deadlocks under load that hasn't been figured out. I don't do code so have no clue where the problem really lies but suspicions are on the block subsystem - or in regulators - beelink wouldn't be the first vendor to share schematics that don't match the boards they produced. I've reported the problem upstream without much success (will redo on 5.10-rc1 shortly). FWIW, I don't see deadlock issues on other devices (VIMs, etc.) and overall I consider the mainline kernel to be very stable (not feature compelte, but stable within the features present. I only see deadlocks when experimenting with things that I expect to cause deadlocks.

    Quote from darkstar

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

    For aarch64 release from 19.10, when I add "textmode ssh" as kernel boot parameters, I'm able to login remotely and observe:

    The corresponding logs/coredump is attached.

    The kernel behaves relatively okay, but I noticed rc_khadas to bring NULL pointer derefence from time to time. I found stable behaviour when the following kernel parameters are added in extlinux.conf

    Code
    module_blacklist=rc_khadas,ir_nec_decoder,ipv6,rc_core,ir_rc6_decoder,meson_ir ipv6_disable=1

    I personally don't use ipv6, hence its presence.

    Quote from darkstar

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

    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

    Quote from spikerguy

    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.

    • Official Post

    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.

    Quote from chewitt

    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,