Just got the box and after few hours i read your post again and now i have it working but wifi is not working at all?
jernej and MartinB are in the process of writing support for the SDIO version of RTL8822CS in the rtw88 driver. Once some patches hit the mailing list I will backport them into images. Until then the WiFi is not supported on those boxes.
LE10 uses Linux 5.10 kernel and support for the latest Intel chips/GPUs was still WIP at the time 5.10 shipped. If you update to a current LE11 nightly image from: https://test.libreelec.net the latest kernels (5.15, and we bumped to 5.16 last night) should have support. Nightlies are running pre-Alpha Kodi Nexus but should be fairly stable to use.
LE 9.2.8 exists for Slice3 users with some changes that were needed for widevine support. If you don't use Netflix/Amazon or similar there's no need to update. There are no dedicated Slice3 images for LE10/LE11 but you should be able to cross-grade to RPi2 .. although we have not formally made an RPi2 image yet (maybe soon, for 10.0.2). LE10/LE11 images will be missing support for 3D and software optimised HEVC playback so if you need either of those it'll be best to remain on LE 9.2.x. Anyone with an original CM(1) board will want to remain on the legacy images as those run better on the older/lower spec.
NB: I shipped my Slice3 box to HiassofT last year. I'm not expecting him to do much/anything with it, but at least our primary RPi image maintainer has a sample box. If someone reports breakage at least he'll be able to test it.
Is 4K60 enabled? .. If yes, disable it and try again.
You can try a current nightly to see if improvements fix anything. Plan B would be to re-rip from your original media.
the mainline kernel works thanks to the work of volunteers
Google also bankrolls a lot of effort around the Graphics stack in support of ChromeOS (Chromebooks). Most of the work done by Collabora has its roots in ChromeOS needs. Rockchip staff are also upstreaming a lot of the core drivers and board support. There is still a lot of work done by volunteers, but as vendors go, Rockchip aren't bad (better than most, worse than others).
andrkac if the changes were packaged into a custom LE image; commit the changes and push to a public repo like GitHub and share the link so anyone following in your footsteps can see them.
Right-click, save-as.
I believe the following link is very relevant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766377
If you believe it's relevant have you tried the workarounds it contains? e.g. "ethtool -K eth0 gso off gro off tso off" .. If you shared logs (as asked multiple times) we'd be able to confirm your box produces the same hang messages. No logs = No problem.
NB: LE11 nightlies are here: https://test.libreelec.net/ .. If you want to test safely, stop Kodi, rename /storage/.kodi to .kodi-old and then drop the udpate .tar file in /storage/.update and reboot. You will start with a clean Kodi install - which means we don't "upgrade" all your existing config to LE11 and the downgrade is simply the reverse process; stop Kodi, move folders around so the old folder so the active one and drop the older 'update' file in /storage/.update and reboot again. It's messing .. but low drama.
Any suggestions please?
Share logs else we can only make blind guesses at the problem. We suck at guessing, and it's tiresome.
intelmorino I think you need to trigger "recovery" mode on the box again. This will trigger the factory u-boot to search for boot scripts and read them, and the important bit - store/overwrite the file-search routines. If you've simply switched the SD card the stored config will be set to look for CE/Legacy files, hence LE bootscripts are not automatically found and read. It's also interesting to see the file rename approach, I wouldn't have thought it would work (but then I don't test with Legacy images or CE at all). Also good to hear the A95XF3 dtb is okay.. I've submitted it upstream and it should be merged for Linux 5.18.
If the NUC has LSPCON it makes sense that DP-1 is seen as connected, althoug it's a bit of a mystery why HDMI-1 is not active at the same time since (in theory?) it's the active output. Have you tried an LE11 nightly image? .. newer drivers might give different results (grasping at straws in the dark).
Kodi only searches for the active DRM device at startup, so if you connect (or power on) the monitor afterwards the kernel will detect it and reconfigure itself for the new active connection but Kodi will remain fixed on whatever it saw at boot. And it looks like the DP-1 port is seen to be active when HDMI is not connected.
The getedid script should work, but you will need to ensure HDMI is connected and the monitor powered on before you power on the NUC, else the script will probably find the DP-1 device active and then you get the EDID for the DP-1 port, maybe?
It's also possible to set "video=HDMI-A-1:1920x1080M@60" in kernel boot params, which should force output to the HDMI connector with some standard timings. Other random thoughts are to disable the DP ports in BIOS, if that's possible?
it does not continue loading and the error appears at the top right of the screen as already explained
And what does the error say? (snap a pic on a phone or take a slowmo video it's quick)
Bump to the LE11 nightly, because if anything is fixed that's great, and if not fixed it's a current kernel to investigate from wheras the 5.10.x kernel used in LE10 releases is recent but also ageing .. Linux 5.16 was released last Sunday.
Urgh.. I didn't notice that
