I'd guess that's the performance issue that the pmdomain patch (we dropped) referred to. Was it enough to just add the right kernel options for the regulators to get things booting again or was the patch revert essential?
Posts by chewitt
-
-
Casting features need to be implemented within Kodi not the underlying OS (LibreELEC)
-
rkman Saying "black screen" and then "rendering works fine" sounds contradictory so I'm guessing the Kodi home screen shows up eventually? so the screen is only blank during early boot?. If yes, this is prob. due to the kernel now supporting 4K output and in early boot a 4K mode the TV doesn't quite agree with is used. The workaround is to append video=HDMI-A-1:1920x1080M@60D to the kernel boot params in extlinux.conf so initial output is forced to 1080p instead. As a general rule you want to run Kodi at 1080p and only switch to 4K for playback anyway (see https://wiki.libreelec.tv/configuration/4k-hdr).
NB: If the board is booting from downstream Rockchip u-boot on SPI flash you can probably expect random behaviours. It's best to wipe SPI and allow mainline u-boot (2025.10) on the SD card or eMMC module (wherever LE is flashed) to be used instead.
-
ffmpeg 7.0 was updated to 8.0; the add-on repo version was already bumped and add-ons are already being built. The mpd add-on should update itself in the next 24h.
-
The existing config worked fine at one point but systemd is a continually evolving beast so perhaps something was improved and now needs additional config juju for things to work as before. If something needs fixing .. send a PR with a decent explanation of what is being changed and why, and it will be tested (over a range of build targets) and if good, merged.
-
Moved to off-topic as this has nothing to do with LibreELEC support.
-
orclex I've picked the details into one of my branches, it will be merged next time I push some changes to our main repo.
-
The contents of /storage/.config/system.d are overlaid onto the virtual filesystem after SYSTEM is expanded on boot, so if you want to change config of an embedded .service file just clone the file to that location, make edits, and reboot. The same is true for other special folders under /storage/.config/ .. or you need to start building custom images with your preferred changes baked-in during compile via the buildsystem. The former is fine for quick tweaks and tests. The latter will be easier to sustain over a longer period.
-
Donations to project funds are always welcome but if there's even a hint of an expectation of a donation buying special treatment or custom images; keep your wallet closed to avoid disappointment.
-
I'm wondering if the elfarto VAAPI shim works better: https://github.com/elFarto/nvidia-vaapi-driver/
NB: Our general advice since 2016 is to avoid the purchase of nVidia hardware for LE use due to distro packaging for nVidia support being a clusterfcuk. The nature of the clusterfcuk has changed a few times over the years, but with each improvement nVidia never fails to add some new complication that keeps the status quo intact.
-
If the OS is running but no graphics (and thus no Kodi) I'll make an educated guess the problem is mesa related. See if reverting to the mesa version used with the last known working images restores things? If yes, you can manually bisect between known-good and known-bad mesa versions to find when the breaking version change occurs; then you can look at mesa changelogs/commits to see what commits might be involved.
NB: I'm guessing mesa because the panfrost kernel driver has received little real-world change over time since it was added, but on the userspace side mesa has a high rate of change and mesa automated testing will be done against Bifrost hardware, and perhaps the second generation Midgard T860 used in some Chromebook devices; not the first generation Midgard T628 used with XU4 which has an inconvenient amount of silicon "errata" that often require complex or fugly workarounds.
-
The Lakka folks had images with Mali blobs in the past and I have fuzzy recall of there being some older LE community images from zalaare but our official releases always used upstream kernels and mesa/panfrost.
-
-
If you’re lucky it’s missing firmware. If you’re unlucky it’s the older Broadcom driver that we dropped. Share the URLs generated by “dmesg | paste” and “lspci | paste” and we should be able to see.
-
The first official XU4 image was LE11 (10.95.1 = LE11 beta1) so there is no 9.2 image and CrapGPT is halucinating answers. The last time I dug one out for testing was about 12-months ago and at that time Audio/Video were working fine; albeit XU4 is showing its age and only supports H264 hardware decode. NB: The main reason we still have it in our board line-up (and also the main reason we added support back in 2020) was so that Lakka can use it for retro-gaming.
-
You’re not a normal user though. That’s the point. LE is also no different to RPiOS when it comes to defaults here.
-
Updated images in my test share now run Linux 6.18.2 and after some collaborative VP9 fiddling with the driver author this morning all the YUV420 8-bit/10-bit VP9 test media I have now plays fine on RK3588 (no more green screens) although whether we managed to correctly enable 'Profile 2' support in the driver is anyone's guess. On RK356X I'm seeing some IOMMU page-fault issues with 10-bit HEVC media. There's also an issue on RK356X where fractional rates (23.976/29.97/59.94) are not showing up in the kernel DRM layer. That can be worked-around by disabling adjust-refresh and allowing Kodi to run at 60Hz. Both of those will need some looking into. And i've not tested with RK3576 for a while, something still to find time for.
-
CD/DVD is not supported in our boot media. Have you tried creating a bootable USB stick instead of an SD card?