After Googling the box it looks like the M8S-Pro-L has only 10/100 Ethernet. If true, use the Q201 dtb. Hardware decode was working until a big batch of changes landed recently and I didn't figure out what the breaking change is yet. I don't have much time right now (new year, back to work) but it will get spotted eventually.
Posts by chewitt
-
-
-
Create a new SD card using the AMLGX "box" image from https://test.libreelec.tv/ then set the dtb name to use in uEnv.ini and boot/see what works. I'd start with the mecool kiii-pro dtb as most of their boxes seem to be similar hardware.
There is currently an issue with hardware decode in nightlies so you will need to disable it in Kodi playback settings (but leave DRMPRIME enabled) to get video output. Software decoded output should be broadly on-par with the performance of S912 legacy images that had no proper GPU drivers though (good for anything @ 1080p).
NB: You cannot "update" an existing install, the boot process is different with upstream images so it needs to be a clean install.
-
Odd, it probes the BT modeul but doesn't load. I'll have a poke around in the dts bits. I suspect the GXL box devices in the upstream kernel are a little unloved as the focus has mostly been on SBC board devices.
-
hieppo It's the dtb. I can see there is no Broadcom WiFi device in the dtsi under the &sd_emmc_a; node:
linux/meson-gxl-s905x-p212.dts at master · torvalds/linuxLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.github.comlinux/meson-gxl-s905x-p212.dtsi at master · torvalds/linuxLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.github.comSo assuming the box has a Broadcom WiFi chip? it should be trivial to add. If you use the p212 dtb it should have working BT? - share the URL generated by "dmesg | paste" when using the p212 dtb and I can see.
-
-
If it works, that's fine
-
Alternative (earlier) fix for the same issue RE: Cannot Install/Update Addons
-
I'm told device wake over CEC would need some changes in the driver. I'll add it to the long list of undone things, but It's not something I can do myself - to set expectations.
-
It's possible to replace /etc/connman/main.conf at boot time using /storage/.config/connman_main.conf but the same is not implemented for the Bluez main.conf file. You should attempt the bind mount mglae suggested. If that doesn't work you need to self-compile an image with the changes made at build time (or implementing a similar override method to ConnMan.
-
Thanks for info. Is it chance that the Patch will be implementet (somehow) in Libreelec (Your) Distribution ?
If/when there is a patch, I will test it in my branch and then push it to LE. This has been ongoing for several years though so I wouldn't hold breath for a speedy resolution - although more progress/understanding on it has been reached in the last year than the previous 3-4.
-
HDR to SDR tonemapping is not currently implemented, so nothing to enable. It's something in the to-do list for the future.
-
If it's not merged upstream, it's not in the Kodi we're using.
-
LE11 nightlies are the only images that will run on RPi02W hardware (without a lot of jumping through unsupported hoops) .. but you'll likely run into a bug that will stop Kodi from running in the latest nightlies. The issue is known, but needs some dev attention to fix, and the devs in question (from RPi Foundation) are on PTO at the moment. So be patient and wait a week and it should be resolved. NB: RPi02W only has 512MB RAM so while it can/will boot LE11 nightlies we have no plans to formally support it (or any other 512MB devices) as Kodi Matrix/Nexus really need 1GB.
-
ConnMan has no method for chosing which WLAN card the tether should run on, so you may need to blacklist driver modules to disable the internal card. Once that's done, it should work, as long as the driver for the USB card supports AP modes; most do, but not all <insert usual statement about garbage realtek drivers>.
-
If you spend $$ on faster SD cards you may be able to empirically measure a minor speed bump and it might boot marginally quicker, but in practical terms you will not notice any real-world difference in performance. Save goes for USB3 SSD drives; they are quicker in certain tests but you're unlikely to notice much difference (and you need to hang the drive out the back of the board, which is ugly).
-
SSH in and "journalctl | paste" after a clean boot, and share the URL so we can see what's not right. No logs = No problem
-