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.
Posts by chewitt
-
-
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?
-
The work-in-progress VP9 driver implementation is loosly based on the older 'rkvdec' IP block for RK3399 boards which was limited to 'Profile 0' media (8-bit, YUV420, up-to 1080p). The driver has been extended to work with 4K media, but needs further work to support 'Profile 2' (10-bit) and the DRM layer on RK3588/RK3576 does not support YUV422 yet. The driver author also needs a little coaching on how to run the 'fluster' tests that are used to score conformance and capabilities. It's a promising start though.
-
Thank you, that solved it! I wonder why this is disabled by default and there is no way to enable it through the UI?
Everything requires CPU cycles to exist and only a handful of RPi users require analogue audio so it defaults off. For much the same reason, why go through all the development effort to make overlay application a GUI task when few will ever use it.
-
Perhaps see if a different order of the three shell/console params allows the UART log to capture later boot output. It's a long shot..
-
The console log ends when init is executed and userspace is loaded from the SYSTEM file. I would assume boot continues though, so add "ssh" to kernel boot params in extlinux.conf and boot up. The SSH daemon will be forced to start on boot, allowing you to SSH in and run "journalctl | paste" then share a URL which will hopefully give clues on what's not working from later in the boot process.
-
No log visible. If possible please pastebin the log and share a URL, because after the 5,000th or so time doing it, the novelty of having to download files to read them locally wears off.
-
I've been using el cheapo things from Amazon for years. HK shipped me one of their UART cables alongside some samples at some point a decade ago but it's long lost and not required. I don't know of any ARM SoC hardware that needs the +3.3v pin wiring up.
-
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 GoldenDescription: 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
