I don't see a specific board image for that iteration of RockPi so you'll probably need to frankenstein or self-build something.
Posts by chewitt
-
-
You should think about using an external USB SSD instead of the SD card.
I don't find an SD card slow (with an above average sized media library) or unreliable, and the less stuff dangled off cables the better IMHO.
-
Feel free to submit changes on GitHub .. it's open source like the rest of our codebase.
GitHub - LibreELEC/documentation: The LibreELEC wiki on GitBooks https://libreelec.wikiThe LibreELEC wiki on GitBooks https://libreelec.wiki - GitHub - LibreELEC/documentation: The LibreELEC wiki on GitBooks https://libreelec.wikigithub.com -
IIRC the "toothpick" method should drop you into an Android restore GUI, but I'm fuzzy about it since it's years since I used it.
-
NB: If you install the board image you are overwriting vendor u-boot with vanilla upstream u-boot; which a) has no "hold the power key to switch OS" mode, and b) there is now a single OS installed so nothing to switch between anyway. If you want that functionality you need to use the "box" image and configure it for the WP2 (or Hub, as appropriate) so that you retain vendor u-boot.
https://www.dropbox.com/s/tw6bg3kipc8t…wp2.img.gz?dl=0 <= dd backup of the WP2 factory image
-
-
One more question. S905X4 – Is there TBS support? It's clear to me that it's a little different hardware than with and so on.
There is some early/basic activity to upstream core board support for S905X4, but I'd guess another year before there's a useable usptream kernel for devices (and longer before LE support). Your only option will be the vendor kernel, or maybe CE but no ideas whether TBS HW can be supported on their codebase (and this is the wrong forum for that Q).
-
The last kernel patchset I personally tested was merged for 11.0.1 so I can't speak for what issues may have been introduced with bumps others have done to newer kernels for 11.0.3 .. but historically the only issue I've seen on a Hub that caused boot issues is the UART noise problem I've flagged above (which the logs shared seem to point to). I'm not sure why newer u-boot is super-sensitive on the serial line or if anything can be done in u-boot device-tree to workaround that (my u-boot knowledge isn't awesome). I did previously experiment with a tweaked u-boot that basically disables the UART keyboard and (as expected) this sidesteps the problem. That proved the theory; but as the u-boot sources we build from are used with all AMLGX boards it's not possible to patch only the Hub at bulk-compile time.
The following may be useful:
https://www.dropbox.com/s/7wi5vhrgqsle6ug/dtb.img?dl=0 <= ^ these three can be copied to a FAT formatted SD to use with vendor u-boot recovery mode to restore the original factory image.
https://www.dropbox.com/s/v46jogn3rk4i…hub.tar.gz?dl=0 <= this is a dd backup of the factory image on emmc.
-
No idea what the problem is but the long-standing advise for most DVB hardware is to separate the card/server end from the client so that the client device (RPi #1) can use the latest and greatest LE version, and the TVH/card are connected to another device (RPi #2) that runs whatever distro (with kernel and drivers) that runs reliably. TBS sadly have rather poor upstream kernel support for their devices (and I believe have moved their driver sources to a closed-source model again) so hitting the magic combo that runs right on recent or bleeding-edge LE kernels can be challenging.
-
can I use the one from coreelec that works?
No, as the file is kernel-version specific. You'll have to experiement with other g12a device-tree files.
-
My understanding has always been that ConnMan has conflict avoidance logic and should enable the tether using an alternative subnet class, e.g. if Ethernet uses 192.168.x.x then it would pick 10.x.x.x or 172.16.x.x instead. Not something I ever needed to test though. Regardless, the logic is automagic and the wireless configuration is not something you can directly control. The functionality in ConnMan is for providing a hotspot on mobile phone or tablet device and so has on/off level controls; it is intentionally simple and not a router. And, if WireGuard works with the move-before logic, you need the move-before logic.
-
I'm noticing that your compose file has "- PUID= 0" not "- PUID=0" .. notice the space after the = .. Yaml files are sensitive to formatting.
I'd also recommend switching the drive to ext4 as exFAT does not support unix permissions (hence everything is 777)
-
[ 10.369177] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
The broadcom driver supports loading a board/implementation-specific (not chipset-specific) tuning firmware (clm_blob) but very few boards have them and thus there is no blob to load in our image and the driver reports this. It should really be a warning not an error, but ISTR the driver uses the generic kernel firmware loading helpers so it's not possible to alter how that's reported without impacting the reporting of all kernel firmware loading which would not be desirable. In short, it's harmless. You might need to configure the wireless regdomain in the LE settings add-on for all channels to be available.
-
As a general rule you don't need to directly install Widevine. If you install add-ons that require it they will use inputstream.adaptive to handle the playback of media streams and this add-on will initiate the installation of Widevine libs. All you see is an on-screen prompt to agree to the download of them.
-
-
How are you starting the nextcloud container? .. and which container?
-
-
Put the file in /storage/.update or do a manual update in the settings add-on.