Official LE12 Test Images for Amlogic (Kodi-21)

    Thanks, we need to see if we can discover the right names for the registers we're poking (even the vendor kernel is vague on this) and then we'll send changes upstream.

    • New

    LibreELEC-AMLGX.aarch64-12.0.0-wetek-play2.img inside a Minix Neo U1.

    Set extlinux.conf to: "meson-gxbb-p201.dtb"

    No run.

    Why?

    The Wetek Play 2 dtb also no boot.

    Just stuck at the boot logo:

    EDIT: LibreELEC-AMLGX.aarch64-12.0-nightly-20240406-4b7642d-wetek-play2.img Also ... ... NO ... BOOT :P

    S*** Linux ... :) Minix Neo u1. very rare, unknown box :P ROFL.

    I give it up ... Back to good old super duper 9.0.1 WITH working Sync Playback 2 Display.

    EDIT2:

    One last try ... This time with LibreELEC-AMLGX.aarch64-11.95.1-box.img @ meson-gxbb-p201.dtb

    AAAAAAAAAAAAnd of course ... Computer says ... ... No!

    Edited 5 times, last by wedok (April 11, 2024 at 11:34 PM).

    • New
    Quote from wedok

    LibreELEC-AMLGX.aarch64-12.0.0-wetek-play2.img inside a Minix Neo U1.Set extlinux.conf to: "meson-gxbb-p201.dtb"

    No run. Why?

    This image is design to boot WP2 boxes from emmc (or SD with emmc erased). It will not boot anything else (as you discovered).

    Quote from wedok

    One last try ... This time with LibreELEC-AMLGX.aarch64-11.95.1-box.img @ meson-gxbb-p201.dtb

    This is the correct image to use with devices with vendor u-boot. The initial boot is successful and then when the device reboots after resizing this sometimes happens; and I have no idea why. All you can do is repeat the install process until it works. You might need to check and repair (fsck) the filesystems on the SD card.

    • New

    LibreELEC-AMLGX.aarch64-12.0-nightly-20240412-48fc90e-box.img with "wetek play 2 dtb" works on my u1. (with gxbb-p201 i have no lan and usb storage)


    But with sdcard inside the sdcardslot of the box i always get the "error in mount_flash".

    sdcard inside a sdcard to usb converter works.


    the "FPS_test_1080p23.976_L4.1.mkv" plays some seconds and then hangs with buffer symbol with enabled prime decoder. playing stuff without hardware acceleration us useless.

    some other h264 ran fine AAAAND... "SYNC PLAYBACK 2 DISPLAY" works again.

    23.976p plays at 104.271% to speedup to 25fps

    "Stats" say that "missed" is running up but video runs smooth.


    these are my 1st results. :)

    Edited once, last by wedok (April 12, 2024 at 9:20 PM).

    • New

    I'd guess the SD card is a newer/faster one and doesn't get reset properly after the initial boot and thus can't be read-from. If you find an old/slow SD card without fancy fast modes it will probably work. Using the USB adaptor sidesteps such issues.

    NB: AMLGX is not perfect. If you want to nit-pick on what works/doesn't, you can save fingers from typing forum reports about this/that test file because a) I know there are bugs, b) I know nobody is working to fix them. I'd like to see improvements of course, but until there are some, the reports aren't interesting. Best results come with using the mode whitelist and adjust-refresh. Using "sync playback to display" will probably cause more issues that it might solve. If it works for you, that's nice. If it doesn't, /shrug

    • New

    chewitt Are there any changes in video decoding in your latest compilation with kernel 6.9.0-rc5? It seems to me that it works more stable with hardware decoding enabled for 4K video. Is it better to use Direct to Plane or EGL?

    I am using a Tv Box with Amlogic S912.

    • New

    I usually don't watch 4K and have hardware decoding turned off. But occasionally something will hit, or I test myself short demos in 4K and HDR, or without HDR. These are mostly h246 and h265 but vp9 also happens. It seemed to me that lately the scrolling works a little better with hardware decoding enabled.
    Moments after writing the previous post, unfortunately the whole system crashed. This happens as you switch between videos with different codecs, and as far as I know this is a known problem.

    Is there still any hope that someday it will work better on the S912?
    Of course I don't expect anything, I'm just asking out of curiosity.
    By the way, thank you for your work.

    • New

    There are issues in the codec drivers that cause memory (buffer) starvation. Repeated plays using the same codec eventually hit the problem. Swapping between codecs seems to cause them faster. It's nothing specific to S912 and impacts all chips.

    I'm told LibreComputer plan further work on the codecs (resuming where last years effort/funding stopped) but that all depends on sales revenues to provide funding, info from Amlogic, and availability of commercial developer resources. It's a large piece of work to line up, so no breath holding.