Have you run "rpi-eeprom-config --edit" ?? .. You need to append BOOT_ORDER=0xf416 to the device to have it boot from NVME.
Posts by chewitt
-
-
Thanks for the feedback (and credit for the change is for MartinB not myself). The next challenge is to explain why this issue appears now (recently) and not years ago. In other words: what other change has someone done in the (u-boot/kernel) codebase to result in this being required?. Once that's been explained the upstream maintainers can think about pushing a global change to e.g. gxbb/gxl platform .dtsi files (not board level files) to fix the issue everywhere.
In the short term I'll include the patch for C2 and see if it also solves a similar (but older) issue report on WeTek Hub.
-
From a coding/development perspective this is a workaround not a fix, but it's interesting. Thanks for sharing.
I have a suspicion the trigger for invalid-key is about signal strength and things on the 'radio' side of WiFi, with the problem being related to how retries are handled. As we know reverting to wpa_supplicant also consistently eliminates the issue; the crack things fall down is probably in iwd, although "it takes two to tango" so interactions between iwd/connman that need examining.
The challenge is/remains: finding people with the code diagnostics skills to triage the issue, who can also replicate the issue.
-
No time to fill the template
Kodi devs normally auto-close tickets that don't follow the template. They read a ton of tickets, and if users make it complicated to find the important info, they often find other tickets that did follow the template and work on those instead.
-
the processor may not be able to handle the UI smoothly at such high resolutions
ARM SoC devices need to use 1080p desktop/GUI resolution. You can use 4K for playback as this is hardware accelerated, but the CPUs are nearly all too weak for 4K resolutions.
-
I've pushed a u-boot 2024.10 bump to images in my test share. It would be nice to hear some test reports with it.
-
Diff
Display More--- a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi +++ b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi @@ -35,6 +35,13 @@ snps,reset-active-low; }; +&uart_ao_a_pins { + mux { + /delete-property/ bias-disable; + bias-pull-up; + }; +}; + &usb0 { status = "disabled"; };ilovebytes Please test https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz. This bumps the u-boot version to 2024.10 and includes the experimental patch above suggested by MartinB. Any difference?
-
I see no Linux version
That because there is no Linux version - as stated on the downloads page (not currently available) and in the v1.5 release notes.
-
And? .. how is this related/relevant to LibreELEC?
-
How is this related/relevant to LibreELEC?
-
If it's not causing an issue, ignore it.
-
If the connected TV supports a range of refresh rates, Kodi will switch from the default desktop (1080p@60) to a resolution/refresh matching the media being played to get the best output, e.g. most movies are [email protected]. So a change is normal and generally desirable. However, if you do this on older GPU hardware or with older TVs the switch can be slower and more noticeable. There's a delay option in Kodi settings that allows you to pause output for e.g. 2 seconds to allow the switch to take place. You can also disable that behaviour completely and force all output to the desktop resolution, but then Kodi needs to rework media to match 1080@60, e.g. to make the 520@25fps video content from a PAL broadcast fit into the 1080@60fps output stream. It will do that by resizing and duplicating some frames. Kodi handles this well, but ultimately there are differences and your eyeballs might detect something.
This is not specifically about that topic but might fill in some background: https://wiki.libreelec.tv/configuration/4k-hdr
-
I don't see anything insightful. Have you experimented with the NFS client caching/chunking options in K21?
-
I would connect the RPi4 directly to the 'server' PC to isolate the problem. If throughput is better, the slowdown is caused by things you connect between them.
-
LE defautls to the "ondemand" governor. You can change that with a command in /storage/.config/autostart.sh if needed.
-
Code
Display More[Unit] Description=OpenVPN Autorun Service After=network-online.target nss-lookup.target time-sync.target Wants=network-online.target nss-lookup.target time-sync.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/openvpn --daemon --config /storage/.config/openvpn.config ExecStart=/usr/bin/sleep 10 [Install] WantedBy=multiuser.targetNo harm in trying .. ^
-
I'll need to dig out the box and test. I'm rather time-poor at the moment though so can't promise that happens quickly.
-
Code
Display More[Unit] Description=OpenVPN Autorun Service After=network-online.target nss-lookup.target time-sync.target Wants=network-online.target nss-lookup.target time-sync.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/openvpn --daemon --config /storage/.config/openvpn.config [Install] WantedBy=multiuser.targetSee how that ^ works?
