Official LE12 Test Images for Amlogic (Kodi-21)

  • First post in this thread, so excuse any mistakes. I have the annoying mxq pro 4k box with s905 and use/update it with chewitt's image from the testing page. I try not to miss any upgrades, so all I can remember is that I went from the one from Dec 11th to the one from Dec 13th and to the one from Dec 19th (yesterday).

    Before making today's upgrade, I noticed that it was too slow to connect to the wifi and some errors in dmesg. After making it, the issue remains, so here is what dmesg outputs.

    https://paste.libreelec.tv/assuring-possum.log

    I have no big plans for it anymore, I just want to use it as an iptv device for the rainy days that the tv signal is bad.

  • The RTL8189ES driver only exists in my private image (which is why you are stuck with them) so nightly changelogs are irrelevant. I checked the upstream repo that I get the driver from an I'm using the latest versions. Ping CGarces for input ^

  • I know that the driver is only at your image, that is why I use it.

    Today's update to "b5823b71dbb8163bf73b03a9873674e292be23df" broke wifi a bit more. It simply does connect or at least not get an ip at launch. I connect to it via ethernet, remove the relevant folder under ~/.cache/connman and then, though connman (instructions at the arch wiki) I connect to it again. The problem is when it is supposed to ask for a password, it simply does not. However it does connect, but it stays like so until the reboot.

  • Are there builds for S912 gxm_q200_3g

    H96 PRO+ 3GB 32GB
    PCB CZ-S32-v2.2 20161012(A15)
    QL 1730
    JOB20170808 3+32/9377

    1 x amlogic S912 OCTA-CORE BODGHN01404 J-TNA346.00
    1 x 32GB Toshiba 19nm THGBMBG8D4KBAIR 170821AE EMMC HS400 V5.0 Read 270MB Write 90MB
    1 x Fn-Link 8223A-SR COB009 1732 (QCA9377 433Mbps 1T1R 802.11a/b/g/n/ac BTLE 4.1)
    1 x RTL8211F H6120H4 GH25 Gigabit Ethernet Transceiver
    1 x GL850G HH4JB05Y22 713SGF9891 Genesys Logic 4 Port USB 2.0 Hub
    2 x 1GB SpecTek 512X16DDR3 HL - FC4F 1708 / DY6L 1704 (SpecTek State 1600MHZ DDR3 1.5v) (rebadged Micron 512x16 DDR3L 1866 CL13)
    2 x 512MB Micron 6EN77 D9SDD 3ZRJ (256X16 DDR3L 1866 CL13) D9SDD full PN=MT41K256M16LY-107:N

  • Are there builds for S912 gxm_q200_3g

    Use the AMLGX "box" image and pick the Q200 device-tree. Read https://wiki.libreelec.tv/hardware/amlogic because the install process is different from legacy images and other distros. WiFi will probably work as the SDIO bus supports discovery. BT will not work as it's a serial UART device and the Q200 device-tree assumes a Broadcom module. Read the current LE release notes to understand the general state of Amlogic support.

  • is gxm_q200_3g my best dtb? I have always used that in the past but dont know which one i should actually use

    It will probably work (other than BT). If it doesn't you'll (emphasis on the you) will need to experiment, but if chasing BT support you can skip the effort as I looked and there are no GXM device-tree files with support for QCA9377 modules in the upstream kernel so you won't find one. Running some fdtput commands from userspace can probably temp-fix the Q200 dtb file.

  • And people wonder why we loathe Realtek vendor drivers so much /shrug

    I agree on that. However, I have to point out 2 things

    - 90%+ of the usb adapters out there are using realtek chips. When they do not work on linux, it is a pita to make them work. But on windows, they are almost plug n play, and even on old windows like w7.
    - When I first tried the original s905 image for le 11, I also tried my precious wn722n v1 that has an atheros chipset. It did not work back then, although its atheros driver is included in the kernel for 10+ years now. I keep it in my drawer for such occasions that I desperately need a linux compatible wifi adapter.

    Moving on to more important and ontopic stuff. Yesterday I noticed the fresh image from Dec 24th, so I wanted to upgrade to it. This time, it did not connect even via ethernet! I gave up after a couple of tries and tried it again today. It connected with no issues via ethernet, so I did the update. After the update, wifi connected like it used to, so I assume that the issue with the previous image was fixed. The same messages appear on dmesg though.

    One thing that does not work, and I do not know if it is because of le 12 or something else is its remote control. It was the first time I connected it to a tv that is not hdmi cec capable, so I could not use the tv's remote to control the tvbox. I can not recall if it was working with le 11, but it was definitely working with ce 9.

  • Hi all

    From two years I have a cheap fake TV box Q96 4K Ultra HD 5G (1+8GB instead 2+16GB) with unknown SOC S905? (probably S905L), WiFi/BT Mediatek 7668, w/o SD slot with Android 10.

    When trying to boot Libreelec (10, 11, 12 or Coreelec...) from USB using device tree meson-gxl-s905x-p212.dtb (I tried many others but only gxl works on this box), it only reaches to kernel panic. I am attaching the UART Log of the working Android, Android DTB partition, photos of the box and Libreelec boot process.

    In the log file it is seen that the platform is p271 ?! Is there any chance that this TV box will boot Libreelec.


    EDIT: After I deleted SYSTEM file, I was able to get to the console and run dmesg. Now I also attached dmesg.log

  • According to past Googling on the topic, S905L is the same as S905X except for no VP9 support. I did create a device-tree for a "Venz V10" S905L box before but the user disappeared without providing feedback so I've dropped that from my kernels.

    The only odd thing in dmesg (other than references to missing SYSTEM file) is there's no sign of the GPU driver (lima) loading, but how that might factor into anything is anyone's guess. I don't see anything particularly odd from the vendor logs. I'm not much of an expert on them though and they're so full of verbose messaging it's hard to see much.

    If you can't get the box to boot with Legacy LE or CE images then there might be something hooey going on at a low level (u-boot) which then upsets or interferes with Linux. It's hard to comment further from the info available.

    In short.. /shrug