Posts by chewitt

The XU4 board has UART pins. The connector(s) on the USB UART can be pushed onto said pins. There is 1000% guaranteed no need for a special molex plug. Just connect GND/TX/RX (do not connect +3.3v, it's not needed).

There's nothing special about the Hardkernel kits. Something like this from Amazon will be fine:

https://www.amazon.ae/DTECH-Serial-Adapter-Prolific-Windows/dp/B07R8BQYW1

WANGCL 3.3V / 5V USB to TTL converter CH340G UART Serial Adapter Module Golden

Description: Module size: 4 x 2.2 cm / 1.57 x 0.86 inch Colour: Golden CH340G original chip Switching Output TTL 3.3V / 5V (with bridge) 3.3V and 5V output…

www.amazon.ae

I'd go create an Ubuntu Live USB and see if that boots? If yes, it's not hard to format the internal drive and do a manual install.

See if installing LE10 works. If yes, then update to LE12.2.

I pushed changes to drop the meson-vdec commit. This is in a private repo so you cannot download the source, but it's not required for the normal image (despite the useful sounding name). The AMLGX image doesn't require grub or kmscube either.

NB: The download tool will download all sources for all packages for all hardware targets. The build command I shared will download only the needed sources for the image being built. I never use the download tool.

You don't need to touch u-boot source because I updated the package.mk to use the githash that already contains the changes.

Quote from nosen

If there is a way to enable SSH by configuring the SD card somehow, I'd love to know.

Add "ssh" to boot params in cmdline.txt and the SSH daemon will be forced to start on boot.

I pushed a u-boot branch with slightly reworked u9h commits to my GitHub repo, it's now based on 2025.10. For the next step I use the LE buildsystem and change the u-boot source to the one with the patches, and add a new device to build.

See: https://github.com/chewitt/LibreELEC.tv/commits/minix-u9h

Then PROJECT=Amlogic DEVICE=AMLGX ARCH=aarch64 UBOOT_SYSTEM=minix-u9h make image generates a complete LE image. I have the benefit of a proper build server at home though, so building images isn't a big deal.

If not you need to follow the image flow from scripts/mkimage and then projects/Amlogic/bootloader/mkimage.

The following patch was posted to the ConnMan mailing list a couple of days ago:

wifi: Detect invalid key with auth challenge failed - Patchwork

As the patch author has provided zero information about the problem being solved in the patch description there's no guarantee that this is the same invalid-key problem, or that the patch is the correct fix for that problem.

There's no harm in testing though, so the following LE13 images contain the patch:

• https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz
• https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz

Go forth and test and report back.

2024-02-27 17:26:10.531  info <general>: Found resolution 720x576 with 720x576 @ 50.000000 Hz
2024-02-27 17:26:10.536  info <general>: Found resolution 720x480 with 720x480 @ 59.940063 Hz
2024-02-27 17:26:10.536  info <general>: Found resolution 720x480 with 720x480 @ 60.000000 Hz
2024-02-27 17:26:10.536  info <general>: Found resolution 640x480 with 640x480 @ 60.000000 Hz

That's the full resolution list the kernel can see ^

The log looks clean except for a kernel splat from the broadcom SDIO module, which i'd interpret as a symptom of stability issues on the SDIO bus, which is a general issue with this era of hardware due to Amlogic silicon bugs. The upstream kernel contains general mitigations that work for most GXL/GXM hardware, but not all hardware, and the U9-H seems to be one of the boards with issues.

At some point in the past I did acquire some hardware and build a test image with upstream u-boot (Minix shared some u-boot sources to support the FIP files being extracted). I have fuzzy recall the image worked okay for me and some users, but not for others, and then efforts have fizzled out for various reasons. I also lack the hardware diagnostics skills to do much more than the relatively basic software tinkering that I've already done.

So not sure what to suggest really. To recreate the test image the FIP files are here https://github.com/chewitt/amlogi…x-u9h/minix-u9h and some u-boot work here: https://github.com/chewitt/u-boot/commits/minix-u9h/

NB: The forum is configured with a list of banned words to prevent human 'bots' making spam posts on certain topics, e.g. medical and fit-ness themed ones. It's just a random coincidence the paste URL uses one of the words.

Quote from gardmitriy

Good afternoon, is it possible to use this adapter for TVBOX? rk3576

LE has no support for RK3576 set-top box devices (because the upstream kernel has no support) so: a) no idea, b) even if it does work there is no LE image for you to test with.

Kwiboo has given me (and thus you) some patches to test that fix the glitching/tearing issues introduced with the latest ffmpeg changes so RK356X/RK3576/RK3588 images in my test share have been updated to include them. Go forth and report issues

NB: I've also extended VP9 hardware decode (up to 1080p) to RK356X as the patch was indeed trivial. However i'm not in the same location as an RK3566 or RK3568 board at the moment, so let me know if it works?

Settings > LibreELEC > Services > Enable SSH

For the logging in part, see this:

video=HDMI-A-1:1920x1080M@60D

See if appending ^ to kernel boot params in cmdline.txt does anything? This forces the intial DRM state to a safe 1080@60 value to mitigate the kernel attempting 4K, which requires more HDMI specs to be aligned (e.g. RPi5 does not support YUV 4:2:0 output).

See https://wiki.libreelec.tv/hardware/intel…generic/laptops

systemctl stop kodi
systemctl stop pulseaudio
systemctl disable pulseaudio
systemctl mask pulseaudio
systemctl start kodi

Masking the service ^ is persistent over reboots.

I've pushed updated images with some initial WIP support for VP9 hardware decode on RK3588 (limited to Profile 0 = 1080p). The codec driver has literally been found hiding in plain sight on GitHub earlier today; the work of a Computer Science undergraduate who has been working on Android images for recent RK boards. I am yet to chat with the author about his plans, but there are code and reddit comments about wanting to add 4K support and upstream which sound positive.

NB: If the driver matures a little more it should be reasonably simple to extend support to RK3566 and RK3568, but RK3576 uses a newer IP block that is "similar but different" enough to need a separate driver.

2025-12-15 07:51:37.048 T:1817     info <general>: VAAPI::SupportsFilter vaDeriveImage not supported by driver - ffmpeg postprocessing and CPU-copy rendering will not be available
2025-12-15 07:51:37.048 T:1817    error <general>: VAAPI/vpp vaCreateConfig error: the requested VAProfile is not supported (12)

Your log is not a debug log (which would be useful to see) but this ^ appears to flag an issue with VAAPI, which is kind of 'new' to nVidia hardware since https://github.com/LibreELEC/LibreELEC.tv/pull/10669 which bumped the mesa version to v25.3.0 which notably dropped VDPAU support and switched over to VAAPI. I'd hazard a guess the VDPAU > VAAPI change might require Kodi settings changes as VDPAU and VAAPI have slightly different featuresets.

The other thing I note is that Kodi only detects the BT audio device, which is probably the known alsa regression fixed in https://github.com/LibreELEC/LibreELEC.tv/pull/10785. The regression effectively causes Kodi to have a broken/invalid audio config and this may also cause Kodi to behave badly; although I would expect to see alsa errors in logs not VAAPI errors. The alsa regression has been fixed (with some backported patches) in nightlies from the last 24-48h.

NB: Problems have nothing to do with the waipu add-on, it just happens to play media in a format that requires decoding and thus the VAAPI issue surfaces. The HomeAssistant addon is also nothing to do with LE so you need to direct any questions about it to the Kodi forum or the HA forum (wherever the add-on is normally supported). It's probably a Python issue that might be provoked by LE running a newer Python3 version than the authors have tested with, but that's still a distro packaging issue for the add-on authors to solve not LE maintainers.