Posts by chewitt

  • Most optimized hardware for LibreELEC Generic

    I would invest in a NAS box that sits in the network with a physical cable connection to the playback device. Then you can keep the current "does everything I need it to do" playback device; and in future change that device without storage features dictating the hardware options. The initial up-front expense is paid back over time in lower effort and cheaper future updates.

  • [RPi5] Weird TV Remote Behavior

    The general advice for HDMI issues is to physically disconnect everything and leave powered off for 10-mins, then reconnect cables and see if anything fixed itself (as it often does).

    The getedid script solves a single and specific problem; the TV not being powered on before the RPi starts. That's the only issue it solves. It does not solve CEC problems. It does not solve any other HDMI problems. Do not use it, unless you have that issue.

  • package.mk for mediatek 7925 PCIe (mt7925e)

    Quote from kai1024

    My understanding is that I just have to add this as package.mk to packages/linux-driver-addons and it will be picked up during make image?

    Not quite. Create the package folder and mt76 package.mk under packages/linux-drivers and test built the driver to ensure it compiles with e.g. PROJECT=Generic ARCH=x86_64 scripts/build mt76 then add the package to ADDITIONAL_PACKAGES in an appropriate 'options' file; either distro, project, or device level and the package will be built as part of a normal image build. Here's an example package.mk (for a realtek wifi driver): https://github.com/chewitt/LibreE…dd77d9cfa1d713e - no idea if that would work as-is or needs changes.

    The easier option would be to enable CONFIG_MT7925E=m in the kernel defconfig, as it's a one-line change and then you're using an upstream supported in-kernel driver. Just edit the relevant defconfig and rebuilt the image; the defconfig change will be detected and the kernel will be rebuilt automatically. NB: I've no idea if the driver needs firmware, but that can be manually added if needed, or you can edit the firmware pick file, either at project level or the x86_64 default one under the kernel-firmware package.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    RK356X images in my share now have a working OSD in Kodi and what appears to be working HEVC support. RK3566/3568 appear to be a bit forgotten; the hardware is largely derivative of RK3588 so e.g. the same vdpu381 decoder can be added easily, but as these chips are not targetted by any funded Collabora development, they aren't being tested (by Collabora) with numerous in-flight patch series. Hopefully LE crowdtesting will fill some gaps. I'm also noticing that MPEG2 support (hantro) has issues with some of the test media that I have, but I haven't been able to spot patterns.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from Yasai-san

    I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.

    RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.

  • [x86-64] "invalid-key" WiFi error with special characters in password

    It's interesting that it reports invalid key, because it should report invalid passphrase. Otherwise it's not the eureka moment we are seeking. The \ character is not an allowed character for passphrases and is thus rejected, end of story.

    The 'invalid-key' other folks are seeing is a crypto key being exchanged between client and access-point, and it's deep in the guts of the negotiations needed for some radio features. Weak signals tend to surface it more, which suggests it's related to error handling (or not-handling) code somewhere in the wireless stack. It also shows up with Broadcom WiFi hardware and WPA3 which is not fully supported in current kernel drivers for that hardware; although we've applied mitigations for that now.

    I've removed "[SOLVED]" from the thread title because I don't want the noise of others pointing out that "there's a solution you're not telling us about" and/or that your solution doesn't work for them.

  • [S905X3] How to correctly compile own DTS

    Amlogic u-boot uses a proprietary partition scheme with Android boxes and this is not supported by any upstream disk/file tools and we aren’t interested in adding the downstream stuff in LE, so you are limited to booting from an SD card or USB and we need to hook the boot process to load the LE kernel etc. SBC boards like the M5 are supported in upstream u-boot so we can support install to eMMC on those via a two step process (boot from SD, then download and write the LE image to eMMC).

    If your box will boot upstream u-boot created from the boot FIP sources of another known (supported) device then you can engineer upstream u-boot support, but this requires experimentation that starts with erasing eMMC so you need to be familiar with Amlogic recovery tools and have the original ROM image and have a serial UART cable wired up to see what’s going on during boot. It’s not something that we support or guide users through because most users don’t have the tools or aptitude for the task. Self-recovery when an incompatible u-boot has been written and you need to short pins on chips to bypass it is not for the faint hearted.