Panfrost works fine on a mainline kernel, but the drivers use a range of kernel features that simply don't exist in the legacy 4.9 kernel that Amlogic ships and CE depends upon. It's a bit of a "between a rock and a hard place" situation.
Posts by chewitt
-
-
I have 4 HP dual core 1.5g wyze thin clients.
I have a few bulky i7 machines laying around
eBay the lot and divert the proceeds to a couple of RPi4B kits
-
There are significant crypto changes in the kernel around Linux 4.10/4.11 which will require the driver to be substantially reworked. An attempt was made here GitHub - chewitt/ssv6051: ** NOT WORKING / DO NOT FORK! ** iComm / South Silicon Valley SSV6051 driver for LibreELEC but the conclusion of the dev who made the attempt (not me) was that the original driver is architecturally garbage and it would be quicker to rewrite from scratch (but it wasn't worth the effort).
-
No log = No problem
-
The sad state of an RPi4B here is .. 92 days of uptime since a deliberate clean reinstall (moving from 9.2.x to 10.x) and the only reboots have been when updating the OS image (self-builds, but tracking the official releases). No issues with install or boot, same as 9.2.x.
-
Amlogic never licensed the Linux "libmali" libs for the T820 GPU in the S912 boxes and the hack to reuse the Android libs has a perfomance impact that was borderline on older Kodi versions and not really usable with K19 and future K releases. LE avoids that by using the FOSS drivers (which are not compatible with the ancient kernels CE uses) but that's a different can of worms.
Sure. There are lots of people wanting/willing to test but nobody has shown interest in writing a driver. As the FOSS development community around Amlogic chips is miniscule (CE contributing to non-upstream vendor/BSP codebases doesn't really advance FOSS) nothing is moving forwards.
-
If I delete the current page the name is released and someone else can register it, and then we'll have a page that looks official that's spammed by the same shits who want to advertise piracy add-ons and VPN and IPVT services. I would also also refuse to (re)assign admin rights to someone unknown to the project. So, the status quo shall remain.
-
LE runs everything as root and I've known that for more than a decade, so I have never said sudo is required.
-
so what is needed? device drivers source so it could be compiled on new kernel? or?
Someone needs to write a V4L2 compatible demux driver; all the other pieces (tuner drivers, demod drivers, firmware) exist (although not in the upstream kernel). This has been the status-quo for about four years so I wouldn't hold breath on it happening anytime soon.
-
quess i dont fully understand problematic, but is it possible to use work of alf1? GitHub - afl1/dvb-firmware
No, it's entirely based on the legacy kernel, which is the wrong kernel. That repo is also incomplete, buggy and abandoned.
-
The only reason I still technically have a FB account is to cybersquat the LE page, which I marked hidden because there were too many twats determined to talk about piracy add-ons and spam posts for VPN services, and I couldn't be arsed to spend the time moderating the swamp it was turning into (typical for FB). If anyone else on the team ever admits to having an account I'd be happy to transfer it to them .. but so far nobody raised their hand.
-
I pushed my most recent efforts to this branch Commits · chewitt/usb-sd-creator · GitHub .. I was able to pick changes from the UNRAID fork of the creator app heree GitHub - limetech/usb-creator: unRAID USB Flash device creator which allowed it to build/work on Catalina (aside from the usual errors you get from not being a paid-up/registered Apple dev) until a recent macOS security update. It now starts, shows the GUI, then throws an error and exits. I've no idea why or how to proceed further.
-
The moment we provide a "limited" browser there will be a long line of pitch-fork waving villagers whinging that it doesn't support X/Y/Z website they watch videos from. No browser generates fewer support threads than wrong browser (sadly).
-
The rtw88 driver in the upstream kernel is under active development and has been adding support for 8822* chips, but I'm not sure what state things are in with the 5.10 kernel used in LE10, it might need something a bit newer to have things work.
DKMS solves a different problem. It allows you to recompile the driver to match the kernel - but it assumes the driver can be compiled for the kernel in the first place. LE's problem is that we frequently bump to the latest kernel and this results in drivers that simply do not compile on the target kernel version. Over time (and multiple drivers) you get rather bored of reinventing this wheel.
-
See if Dropbox - LibreELEC.USB-SD.Creator.macOS.dmg - Simplify your life works for you. It's a version that I built that worked for me under Catalina until a recent update, and since then it crashes (which is why it's never been shared widely). You might get further on the older OS version though.
Re known status .. I appear to be the only person on the team who gives a fcuk about it, and I don't code so my options for 'fixing' it beyond a bit of patch picking from a downstream fork of the app code is rather limited. I've rather given up on trying to entice/lure others to care about it and I think we'll just have to bin the app completely. That will suck, but .. nobody else is lifting a finger so it will be the inevitable conclusion.
-
You have installed LE via the Pi Foundation NOOBS installer; this installs the NOOBS environment and the files needed to run LE on-top of the NOOBS environment. NOOBS is not required, so all you need to do is download the LE 9.2.6 image for RPi2 and write this directly to the SD card using any SD image writing tool. Then you will boot directly into LE without NOOBS.
-
Hl!
Sorry for offtop.
I looking for dualboot script for amalogic s812 (tronsmart mx iii)
(on 4pda and freaktab exist the links on this file, but they are is the dead )
Big thank for any help
No idea what you're talking about
-
The problem with autostart is, it runs right at the start of userspace boot which is typically before everything else (including your scripts) ever gets touched. Best is to add some "logging" to your scripts (sending to /dev/console as described above) but schedule the scripts via systemd so they are ordered correctly in the startup sequence.
