Something have change in the kernel.
LE9 = downstream vendor kernel
LE12 = mainline linux kernel
There is zero kernel code in-common between LE9 images and LE12 images.
Posts by chewitt
-
-
The existing device-tree file for the C4 only describes HDMI output so changes or an overlay file will be required to describe how that's connected, and then you'll need to apply mixer changes at boot time to set the audio routing.
It's possibly something similar to this for the Odroid HiFi-Shield DAC board: https://github.com/tobetter/linux…ifishield2.dtso
It would be useful to know if the DAC works with any of the distro images that HK creates for the C4. If you can get it working with their kernel in e.g. Armbian then we have some prior art that can be replicated in LE.
-
Your nVidia GPU requires the Generic-Legacy image with X11 windowing. Xorg (X11) does not support HDR. There's nothing we can do about that
-
What DAC chip and driver is used?
-
The only major technical difference in wifi connections between LE12 images and LE11 and earlier is the change from wpa_supplicant to iwd. The change has generated a few minor issues but those are largely resolved, and importantly, none have been related to speed of network association. If you wanted to self-build an image with wpa_supplicant to see if that's the problem difference, this is not that hard (a one-line change in distro build options).
NB: I would expect LE12 to boot slower than LE10 as image sizes have increased and load times got slower with time. I wouldn't expect it to be an overly significant difference though; from my own experience with other RPi boards (albeit much faster ones).
There is an obvious long delay as the network comes up, but that's expected given what you've reported. I don't see anything wrong in the log though. You can run systemd-analyse blame but it'll probably look like https://paste.libreelec.tv/decent-ray.log and again, there's nothing unexpected with network start being one of the longest/slowest elements in boot.
For kicks you can disable BT in config.txt by adding dtoverlay=disable-bt and perhaps unplug the USB Gigabit Ethernet adapter that's connected. That's shaving CPU cycles from boot but unlikely to have any major influence.
-
Put Kodi in debug mode, reboot so the logs are clean, then run "pastekodi" and share the URL when things are up/connected.
-
If you use the default PIA config with the problem CRL certs on LE13 and newer (with new OpenSSL) the problems will exist. If you run LE12 the problem should not exist (as older OpenSSL is used). On LE13 and newer if you remove the problem CRL bits from the default PIA config the problem is worked-around and the config will work. On this topic I think we reached the "You can lead a horse to water, but you can't make it drink" point. The workaround requires 30-seconds' worth of effort. It's up to you though.
On a deeper technical level WireGuard is quite different to OpenVPN but from a high-level user perspective they achieve the same thing and most commercial services support both. If you want to explore that there are setup instructions in the wiki. I'm going to pass on the opportunity to spoon-feed instructions or debate that further though.
-
Code
echo 'options usb-storage quirks=152d:0583:u' > /storage/.config/modprobe.d/usb-storage.conf rebootThere are quite a few reports of "device won't mount" on a range of distros for the "JMS583Gen 2 to PCIe Gen3x2 Bridge" adapter so run that ^ over SSH and see if it mounts correctly now?
-
I can run the stable release of 12.02 (non-legacy) and get video and audio just fine over HDMI now.
Some companies ship 'honest' release notes. Others never admit to their mistakes. At least it's fixed and there's an explanation of sorts
-
There is no i965 mesa driver any more in LE
I'm a bit behind on x86 matters (about a decade)
I was thinking to expense an N100 box to attempt tracking down the known audio issue (and to see how things are these days) but there are so many devices to choose from on Amazon I keep deferring the idea. It would be better if someone with a bigger interest in Intel matters would do it.
-
One of them replied .. delayed response due to some public festival/holiday in China. It'll be enough to get things in-motion.
-
Increase the "wait for network" timeout in LE settings to 30-seconds; it will exit the wait loop earlier if the connection is found/active earlier. Then the network is always up before Kodi starts and time (via NTP) will always be correct. There's no way to make drivers load and probe hardware faster.
NB: If you need a static address it usually easier to leave devices on DHCP but add a static reservation against the interface MAC in the router so it's always dynamically assigned the same address.
-
-
LE(13) and RPiOS use the same Linux 6.12.y LTS kernel source so you shouldn't need to touch that. All the mesa patches are long upstreamed by Igalia (on behalf of RPi devs) so just use a recent version. Kodi and ffmpeg still requires downstream patches, as you'll find in our repo. The various build options are in the package.mk files, as you found. Beyond that, I've little experience with compiling Kodi outside our buildsystem so I can't really advise.
popcornmix does RPiOS not have an appropriately patched Kodi (and ffmpeg) version to use out-of-box?
-
Ahh. Sorry to hear that but glad there's a logical explanation for the erratic network behaviour!
-
I can cd /storage but doesn't seem to do anything.
The root user's home folder is /storage so when you login, this is where you are. If you then "cd /storage" you change directory to the same one you are already in. Hence it (correctly) doesn't seem to do anything.
-
I was originally suspecting a power issue; especially if the drive is being powered from the USB bus, but when power draw is the issue I'd expect to see spurious errors in the log; mount failures or USB errors or .. something to indicate the device probed then trying/failing/trying/failing to mount and then eventually succeeding. Instead the log looks clean, as if the device is probed (once) and then mounts cleanly and correctly (once).
If the device is USB bus powered, is it a 'single' USB cable or a 'dual' (Y) cable that takes power from multiple USB ports. SSD drives might be small but that doesn't necessarily mean they use little/less power - they can be hungry devices.
Just for info, please run "lsusb -tv | paste" and "lsmod | paste" when the drive is connected.
-
Benchmarks focus on "Which is fastest?" when the better question(s) are "Which is fast-enough for a good experience?" and "Which is best supported?" so they are not telling the whole story.
e.g. RK3588 wins all current ARM SoC benchmarks but is only borderline usable due to incomplete software, whereas comparatively slow RPi5 is more than fast-enough and exceptionally well supported. Intel based hardware also scores big numbers but has been a lottery in recent years due to the never-ending drama from by LSPCON chips (and firmware) in the display chain.
In short: Speed != Value
