One more change: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.2.tar .. the vendor kernel runs the SDIO module at 50MHz but let's see if it's happy to run at 100MHz? .. If it's still connecting please try scp'ing some large files to/from the box to prove the mmc is stable at the higher speed. If it's not I can down-clock back to 50MHz again.
Posts by chewitt
-
-
On the negative: Realtek maintains a driver fork for each chipset variant they shipped despite the differences between variants in the same family often being very minor, and they breed new variants like rabbits so there are probably 30+ drivers in circulation. Realtek only releases their drivers to their paying-for-support customers (end-users are not their customers) so end-users have to rely on board/device vendors sharing them; over time things generally leak to GitHub but it results in 500+ repos with slightly different versions of the same "posted once and never updated again" driver being available to confuse people. There is a large amount of common boilerplate/duplicated code in each vendor driver, and while the vendor drivers generally work okay the overall code quality is low as the drivers have never been subjected to any serious peer review during development. Frequent minor changes to upstream kernel frameworks frequently result in all the drivers breaking and needing to be patched so the drivers are a pain in the arse to maintain over time. The fact the drivers are released with a GPL license is good, but that's about the only good thing to report. Distro maintainers loathe these drivers.
On the positive: Realtek have finally embraced upstreaming their drivers and are now contributing-to and maintaining a single driver per chip family. However their primary interest is in PCI/USB drivers and the SDIO ones are often forgotten, and this is a relatively recent development so they are only investing time/effort into the latest chipsets that nobody is really using yet, not the older chipsets that are endemic. They do comment on patches for older chipsets/drivers when asked, but community developers are the primary source of development for the older chipsets. So future support looks better, but support for everything shipped in the last decade is still a bit sucky.
I'm not sure why the Realtek driver is flagged as staging in Debian (something for Debian maintainers to explain) but I am 100% confident this is the legacy Realtek vendor driver and not the upstream kernel staging driver.
-
Please do "pastekodi" over SSH and share the URL so we can see what's detected/connected.
-
Have you enabled "disable password auth" in SSH options? - this will not stop the box for prompting for a password if you connect, but it will stop passwords from ever being accepted.
Are you using the original remote for the box? .. If yes, can you share the files? - I can see the issue with audio; the required sound-card nodes are missing from meson-gxl-s905-nexbox-a95x.dts. This is simple to fix and I would like to add audio/remote and have you test.
-
I added the driver in the rtl8189fs branch of this repo: https://github.com/jwrdegoede/rtl8189ES_linux/branches
The rtl8189es driver that was already in the image is from the master branch of the same repo (and searches for the 'fs' driver point to that repo). It's common for an RTL driver to support multiple differently-named chips (hence it claims to be RTL8188F in dmesg) .. all part of the garbage and support debt that comes with not-upstream old vendor drivers.
These drivers are not (and will not be) submitted to the main LE repo. I'm going to leave them in my private image for a while; I don't make any guarantee they will remain in my image so at some future point you might need to discover self-building LE images. Historically the RTL vendor drivers break with every kernel major-version bump and we bump kernels frequently so playing "hunt the patch" gets tiresome.
-
You'll need to share UART output from the board.
-
In short, no. You can install another Kodi client configured with the same add-ons/sources of media on the other TV. You cannot stream from one LE instance to another Kodi client; Kodi is not a 'server' application that streams media.
-
-
Any ideas why odroid-c2 can't boot with 11.x versions?
The "odroid-c2" board image has the largest number of active AMLGX installs so I'd guess PEBKAC

Have you read the wiki instructions? https://wiki.libreelec.tv/hardware/amlogic
-
Please redownload/update to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.2.tar (again, it has changes) and change the dtb name in uEnv.ini to "meson-gxbb-nexbox-a95x.dtb" .. I've added something which may or may not work.. we have to see.
-
Interesting, do I get that right that there are two drivers in staging for this USB adapter? A working one from Realtek and a non-working one from Jes Sorensen?
Not correct. Debian is building with the older vendor driver, the staging driver is not enabled in their kernel. LE is building without the vendor driver, and with the staging driver enabled. However, staging = experimental drivers that are still in actively development and/or not feature complete enough to exit staging and be included in the main kernel tree. So the staging driver could be 95% complete or .. 55% with lots still to work on (and I have no idea which).
I'd expect Debian to have a policy of only enabling finished drivers (makes sense for a large distro) and you wouldn't enable both as that will cause conflicts. LE is happy to enable the staging driver(s) as we aren't including the vendor ones (on principle; they break often) so there is no change of conflict .. and if it happens to work that's great.
-
Not yet, I've been tinkering with u-boot 2023.04 and 6.2 kernel on the LE11 codebase. Once I push the next updates to master official nightlies should be created and then I'll switch test/dev work to LE12.
-
Kodi add-ons are "third-party" from LE perspective (not part of our build-system). As add-ons iterate frequently I wouldn't attempt to bundle them into an image as they'll be out of date within a month. It's easier to script-configure things post-install.
-
This is modinfo from the Linux 6.2 staging driver: http://ix.io/4sGP .. so Debian is using the older vendor driver (which is GPL code, but not upstream code). There is probably a way to put the driver into debug to get more info from it.
-
Since today NordVPN stopped working, I reinstalled and correctly filled in my login, but its giving me an message saying it can't connect.
Banned add-ons are installed. No support to be provided.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
I don't think the RHEL article is relevant because the 4.18 kernels are ancient (even though RH backports a ton to them). That also doesn't correlate with the OP who broke his setup by updating the kernel on his OMV install.
You can also look at Kodi changes for NFS and filesystem caching. I have fuzzy recall that there are some between K19 and K20, but as I never use NFS myself (as SMB works fine) I never pay any attention to them. Some differences to an LE9 install would be expected since the entire codebase is different, but we aren't seeing general user whinging about NFS issues with LE11 and that usually means the reported issues are more localised to a specific other software (are you also using the same OMV version?) or something else niche/environmental.
-
NB: I've deleted the other thread you started and moved this one.