Posts by chewitt
-
-
What exact LE version did you update from? .. and to?
-
Kernel drivers need to be compiled for the specific kernel version running and 'dkms' drivers automatically rebuild (recompile) when a change in the kernel version (magic) is detected. Compiling requires header files, so that's easily explained.
Logs show the hardware being probed and the wl driver loading. If that doesn't result in a working interface it's probably due to a difference between current kernel APIs and ageing/un-current driver code. The kernel evolves and moves (drifts) forwards while the driver code is static, so at some point the kernel has drfted far enough for things to stop working.
I have a suspicion the driver stopped working (although still compiled) some time ago, but few people use hardware old enough to need 'wl' these days (most people use Ethernet) so the breakage has gone un-reported.
As per earlier comments: a decent USB wifi stick or replacing the PCIe module are probably the best options. The latter is probably cheapest although cracking older 'mini' boxes open is quite a task.
-
But in the case of a Dreambox ONE or TWO, what name should I put?
If you can't figure that out from looking at the list of files in the "amlogic" folder on the SD card, support ends here.
-
All drivers native to the Linux kernel are GPLv2.0 so when an out-of-tree (vendor/proprietary) non-GPLv2.0 driver (or in this case, a mixed license driver) is loaded this "taints" the kernel from a license perspective (it is no longer pure GPLv2.0). This is harmless, it has no functional or performance impact or meaning.
I don't see any errors in the log (nothing about firmware loading etc.) but the driver is old and poorly maintained so there might be errors somewhere else once networks are configured. Have you tried to configure a network in LE settings? What does "journalctl | paste" show?
NB: The BT device is USB connected (Universal Serial Bus)
-
WiFi/BT are in the same chip package but powered and addressed differently (WiFi is a PCI device, BT is a serial UART device) so one working and the other not doesn't prove too much. Please run "dmesg | paste" over SSH once updated to 12.0.1 and share the log URL so we can check the boot log for error messages or other info.
-
I forget the LG setup stuff now as it's several years since I last looked at it, but not all HDMI ports are equal and there are numerous options. I'd suggest using a different HDMI port on the TV and checking the HDMI port config in LG settings to ensure the port is set-up for movies and deep colour and not PC or Game modes and such things.
-
I think I miss-read the original post. LE11/12 already include the "wl" driver for BCM4331 cards, although it has been dropped for LE13 because it no longer compiles. It hasn't been actively maintained for years and the in-kernel but less functional 'b43' driver is not much better. Regardless the install LE11 and update advice should still stand. If you really need WiFi the best option will be an external USB device or if you're brave enough to crack the mini open, it should be trivial to swap the BCM4331 card out for a better supported Intel chip device. It's just a PCIe card so anything with the same form-factor pulled from a laptop will work fine.
-
-
Correct. Dreambox(es) use vendor u-boot and should use the 'box' image with the relevant dtb name configured in uEnv.ini
-
The skin is embedded in /usr/share/kodi/addons/webinterface.default which is inside the SYSTEM file that we decompress into a virtual filesystem on boot. As this location is read-only, to make edits you must clone the skin files to /storage/.kodi/addons then edit addon.xml to rename the skin (else it name-clashes with the embedded one) before enabling the addon and selecting it as the "new" skin in Kodi.
-
-
How is the RPi being powered? .. weak PSU's cause problems
-
We don't store archived versions of the app (and anything before 1.4 is buggy) so that's not possible. You can use other apps like Win32DiskImager or Rufus or Etcher to create install media.
-
Hardware deinterlacing doesn't work even in newer SOCs?
The deinterlace IP block has never been implemented in the upstream kernel for any Amlogic hardware (older or newer). The main difference is that newer SoCs generally have more CPU grunt than the older ones and can cope with software deinterlace on 1080p media. Improvements made in the last year for better software deinterlace mean it's actually quite good.
But what changes were made in LE 9.x, that even software deinterlace got worse?
No idea, it's before my time and the vendor codebase is a crapfest so I have no interest in investigating. Feel free to look in the commit history here to guess the breaking change: https://github.com/LibreELEC/linu…amlogic-3.14.y/
-
To preserve posts/thread integrity we will rename/anonymise the account and remove all identifiable data from the DB.
-
So, may I know why the Official LE does not use a vendor rock chip bootloader?
LE packaging assumes we are the sole OS being installed on a device (so we don't need to consider other OS bootloaders) and we choose to use and champion upstream open-source codebases whenever possible. RK3399 is well supported by current u-boot so there is no need for our releases to use vendor sources.
-
The codebase for those images is long-dead. The developers who might have half a clue about the issue are long-gone. The newer (upstream) codebase used in AMLGX doesn't support hardware deinterlacing.
