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.

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).

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.

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.

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.