Posts by chewitt

  • Vontar H618 tv box with Libreelec 12.0

    I'm no expert on Allwinner hardware, but I had a quick look at the device-trees in the Linux 6.17 kernel source, our current Allwinner patchset, and kernel mailing lists (for new patches) and I see no evidence of HDMI support for the H616 or H618 chips existing. This means you will see boot screens due to framebuffer support in the kernel, but there's no HDMI (DRM) driver, so Kodi cannot run.

    If you add 'ssh' to boot params in extlinux.conf the SSH daemon is forced to start and you can login, but you'll only see kodi.log messages about there being no DRM surface or gem object to render to.

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

    Quote from Yasai-san

    Just report only, I don't make pull request for this.

    The current AIC8800 driver will not be accepted into our codebase. The driver code is poor quality and needs a ground-up rewrite and Radxa has no plan for that. We would be stuck with a bad out-of-tree driver. Our instruction will be for users to vote with their wallets and not-purchase any boards using that chip; unless WiFi is not a requirement.

  • Questions

    a) This is an English language forum. If you want to post in your own language; also provide an English version of text.

    b) We don't support Kodi on Windows; use the Kodi forum for that.

    c) We don't make recommendations on hardware we don't have/use - but LibreELEC is $0 so it costs you nothing to experiment and find out what works best for you.

  • Most optimized hardware for LibreELEC Generic

    Quote from tokul

    NAS setup would also depend if user wants to run network media server on libreelec or on nas.

    Nope, the NAS can be just a dumb storage device in the network. You can push the local media DB there too (MariaDB, etc.) if you have more than one client, but Kodi is not a true 'server' app that supports 'client' devices. If you want to run alternate non-Kodi server apps that's a different topic, but displacing Kodi wasn't in the original question.

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