Official LE13 Test Images for Amlogic (Kodi-22)

    Images in my test share are updated to Linux 6.19.y and with a change to the uImage.lzo kernel entry point that's currently needed to get the kernel booting on S4 boards; so I'm interested in reports of boot failures after updating. As part of that work I've added support for the Khadas VIM1S board, although this is not real-world usable at the moment (and thus won't be in official nightlies for a while) due to issues with the S4 DRM driver that result in a flickering screen when Kodi is running, and new alsa incantations being needed for audio routing/mixer settings. Khadas shipped a bunch of VIM1S (S905Y4) samples so there's common hardware among those needing (or wanting) to test the new stateless video codecs and dependencies (DRM, audio, etc.) Amlogic are working on.

    Quote from chewitt

    I'm also interested to hear if WeTek Hub boards are booting fine now? - some folks had an issue we suspected of being noise on the UART that caused it to see a keypress and enter the u-boot console instead of booting. Feedback would be nice.

    As a Wetek Hub owner I can try to test this for you. I have some experience with linux and command-line. Is there a way to verify that the issue is solved? Can one for instance monitor the UART activity once the system has been started? Or do I just need to start the system multiple times and see what happens?

    rawnar You create an SD card using the "box" image then boot from SD card and download or copy the "wetek-hub" board image over to /storage, then write the board image to the internal eMMC storage using emmctool, power off, and then boot. If the issue is fixed, the device boots fine. If it is not fixed, boot will not complete as noise on the UART lines is seen as a keypress and forces you into the u-boot console instead of booting into Linux. To recover from that you will need the 3.5mm to DB9 serial UART adapter WeTek originally shipped with the box, and some kind of DB9 to USB serial UART adapter (as computers don't have DB9 serial ports these days).

    chewitt: I have made the SD card using the "box" image. Where can I find the "wetek-hub" board image? In your testing folder I can find the "wetek-play2" and "wetek-core2" board images, but not the "wetek-hub" one. Can I use the "wetek-play2" board image?

    Did some digging through the boxes and found the original UART to DB9 cable. I assume it uses RS232 levels for the serial communication.

    I've not tried booting Hub/Play2 from each others images so can't guarantee that works. If you erase emmc so the board boots from SD card it's safe to experiment though. If you write the wrong image to emmc and there's an issue, it's not impossible to resolve but hope you like dismantling things and shorting pins on the emmc chips to temp disable them and boot from SD card again; as that's what'll be needed. I'm up to my neck in some Rockchip work at the moment, but test on SD card and if that works and you want the right image to write to emmc, I'll find some time to go build one.

    No idea on UART levels as I have a generic USB to DB9 adapter (cheap on Amazon) for those boxes. The only annoying thing is one of the cables WeTek shipped (can't remember which) is fema1e DB9 not ma1e, but that's solveable with a gender bender.

    Hi , cool to see these old boxes getting delepoment again.

    I have a Mecool M8S PRO L with 3GB ram and 100 Mbit lan. Its working with the meson-gxm-q201.dtb file, but I only seem to have 2GB being used by kodi. Any way to update the dtb file?

    Quote from crazyazz

    I have a Mecool M8S PRO L with 3GB ram and 100 Mbit lan. Its working with the meson-gxm-q201.dtb file, but I only seem to have 2GB being used by kodi. Any way to update the dtb file?

    The upstream kernel doesn't have/need the complication of hardcoded RAM sizes in device-tree; it auto-detects whatever capacity the box has. So either the Amlogic (Android) u-boot code booting the box has been hacked in some way to withhold RAM from the kernel, or the box has 2GB ram and vendor u-boot/kernel code was hacked/hardcoded to show a fake 3GB value. The latter happens quite a bit on Android boxes from the GXM era, so IMHO is the more likely explanation. NB: Kodi runs happily on something with 1GB RAM so 2GB RAM is more than enough unless chasing an exotic configuration with lots of services running in the background.

    Thanks for the info.

    Only issues I have so far are:

    HDR or DV playback has just black screen / green etc

    On playback start / stop audio via analog out pops loudly like its initiating or something.

    Stock remote no function

    Appreciate all your work!

    The HEVC decoder was never really finished so it mostly works, but some media files cause issues and give no output. S912 also has no support for DV so you won't get output unless media contains a normal HDR fallback stream; some does, but most of the content from online streaming sources does not (to save bandwidth). It's also hard to comment on what happened without seeing a debug log. In the current codebase playback is what it is until Amlogic get further along with upstreaming.

    Analogue output is likely a little under-developed given the focus on HDMI so no real comment on that. This wiki article should get the remote working: https://wiki.libreelec.tv/configuration/…ration-advanced - the generic q200/q201 device-tree files intentionally don't contain preconfigured keymaps so you need to define your own.

    Results so far.

    Booting from a SD-Card using the LE 12.90.1 "box" image gives no problem. It boots normally one can watch videos.

    Booting from a SD-Card using the "wetek-play2" image and changing the extlinux.conf to point to the device-tree of the wetek hub did not work. Tried it five times using the toothpick method (reset button pressed for 4-5 seconds), but every time the HDMI output is switched off after the Wetek splash-screen went away. The first time the screen came back showing some kind of boot menu, but the other four times the HDMI output stayed off.

    I managed to get some console output through the serial line using putty. (btw serial setting I used were 115200n8). You can find them in the attached zip-file. I have logged different runs.

    1. dtech image installed on the EMMC.
    2. chewitt box image installed on a SD-Card.
    3. chewitt wetek play2 image installed on a SD-Card (2 times)

    One thing that I see is that for the "wetek play2" image the KERNEL is not loaded as U-Boot can not find it. And therefor it falls back to a Android kernel. The following lines indicate that.

    On the box version U-Boot seems to use the s905_autoscript to find the KERNEL. Do I need to add some files from the "box" image to the "wetek play2"image to load the KERNEL? Or do you now have the information you need?

    Oh and that I do not always get output to the HDMI seems to be related to U-boot finding the wrong hdmi mode. 1080p60hz having output and smpte24hz having no output.

    You cannot boot the "wetek-play2" image from SD card without first erasing emmc (use emmctool from the box image) because if vendor u-boot exists on emmc the box always boots it and not mainline u-boot from the SD card. The boot partition on the SD card contains only extlinux.conf for mainline u-boot and this is not seen/understood by vendor u-boot; hence it cannot find legacy boot files. You can of course copy s905_autoscript etc. over from the box image but this replicates booting the box image from vendor u-boot which doesn't proove the issue with mainline u-boot is resolved.

    So, erase emmc to force mainline boot from SD card. If the noise issue is resolved then it should boot. If it is not resolved, it will drop to the u-boot console where you can type 'boot' to continue booting. If you want/need to revert back to vendor u-boot I have a raw disk (dd) backup that can be downloaded and copied to /storage on the SD card and written back using emmctool again.