Add "debugging" to boot params and the console on CTRL+ALT+F3 will exist.
Posts by chewitt
-
-
I guess you're using the LE 9.0 images? .. the only thing I can suggest is installing the mainline kernel images on Index of / (AMLGX) but while stability in the core OS is overall improved on the legacy kernels they are still "work in progress" for video and the test images are best used with AMLG12 hardware where the devices have enough grunt to disable hardware decoding and still have good 1080p (not 4k) playback.
-
Most NUC devices are technically capable of playing software decoded Netflix streams in 1080p (and in the past this was possible) but in the last year or so Netflix has implemented DRM changes that restrict Kodi (on Linux) to the SD versions of their content. Feel free to show Netflix DRM the middle-finger and use another service.
-
honentan You can either a) provide the information that I asked for (the device-tree filename you are using), or b) provide unrequested info about a Bluetooth node that is present in 99% of Amlogic legacy device-trees that has nothing to do with Ethernet. It's entirely your call what you share (free speech and all that) but only one of the two results in me taking any further interest in the problem.
NB: In legacy Amlogic devices 99.99% use a broadcom chip so we can use upstream and well supported brcmfmac WiFi and brcm BT drivers instead of the out-of-tree hackfest known as "dhd" that provides WiFi/BT in the legacy kernels. The mainline kernel does not use any of the drivers from legacy 3.14/4.9 kernels (which is a good thing).
-
NB: Kodi reports the wrong free-RAM size but this is cosmetic in Kodi and the OS is capable of using more. It's been corrected in Kodi master.
-
There is zero interest to add the bloat from perl to the OS, but I'm sure there are Docker options for doing that.
-
I haven't got a clue about that stuff.. sorry.
-
On a PC there are underlying code mechanisms to verify and play BR media and Kodi will leverage those frameworks. There is no equivalent on Linux (there are no Legal or certified players for Linux) hence libaacs exists and attempts to plug the gap. Unlike Windows where everything just works, libaacs depends on someone making the effort to dump the keys for a disc and submitting them to the database
-
The dtb files from Amlogic legacy/vendor kernels are not compatible with the mainline kernel (there are 3-5 years of evolution between them and many different drivers) .. but if you name the specific dtb that works we can see if anything stands out.
-
I'd guess that the keys for your disc are not in the DB, so it cannot be decrypted.
-
I'm wondering what in the statement "not supported" was unclear?
-
GXM box devices normally come in three configurations with a low-end device having internal PHY ethernet and the mid/high-end device having extneral PHY ethernet. The Q201 device-tree is for internal PHY only so if that doesn't work try the Q200 which has external PHY. If neither of those work you'll need to try other GXM device-trees. TL/DR .. supporting "board" devices is simple, but "box" devices are always a lottery.
NB: If the WiFi works, SSH in and share the URL from "dmesg | paste" .. maybe we can see more.
-
-
In theory the data is sat there on the eMMC storage and could/should be readable to make a backup *but* the data is on an EXT4 partition that cannot be read under Windows and I'm not sure 5Ninja's ever released Linux drivers/tools for mounting the storage.
An old IT saying/proverb states there are only two type of computer users: a) those who back-up their data with religious conviction, b) those who haven't lost all their data in a mishap yet" .. which is kind of true.
I shifted my DB stuff into a central MySQL DB some time ago as I'm hopping between different test devices all the time, but that's also another good way to make endpoint devices a bit more stateless.
-
-
This is only seen when services fail. If nothing fails you only see the LE version info. So fix the network-online check (connect Ethernet or allow calls to ipv4.connman.net or ipv6.connman.net) and all will be good.
-
As the Slice has no USB or SD Card boot and the device is not booting (or booting far enough for SSH to work) the only real option is to reinstall the OS by flashing from a PC over the USB connection.
-
WeTek Core is ARM (32-bit) using Linux 3.10 and Play2 is ARM64 (64-bit) using Linux 3.14 and DVB drivers are compiled using an arse-backwards process for a specific arch and kernel. TL/DR .. you cannot take the CE add-ons from their 3.14 image and use them on an LE 3.10 device.