Posts by chewitt

Flirc works 100% fine on LE. I use one daily for testing over 4x different SoC platforms and 30+ devices; no need to configure anything (once the initial config is done) .. I just connect it and test.

The upstream kernel now has 10-bit and 12-bit support queued for Linux 5.12 (and backported to the current pi kernel) which is the first step in plumbing in all the fancy stuff that uses it. The number of scenarios needed to properly support HDR, SDR, different types of media and bit-depths (in kernel, ffpmeg, and Kodi) is mind-bendingly complicated, and changes need to choreographed over a number of other SoC platforms. Once you make changes that work on one you also need to prove they work on other platforms too, so it's a slow dance with terrible music.

OpenELEC installs had a 230MB boot partition. Older LE releases are under this size, but around v8.2 we rew larger and the .tar update file is now too large to unpack into the boot partition. To expand the boot partition you need to boot from an Ubuntu or similar Live USB and use Gparted to shrink the storage partition, then move it to the end of the disk to create space af the beginning of the disk, and then the boot partition can be expanded. This is generally very slow and a bit complex for most users, so the alternative is to make a backup, move it off box, then clean install (overwriting the previous install). This will give you a 512MB boot partition. You can then either restore the backup you made, or (often better) redo the box configuration which will clear out years of the cruft that accumulates in Kodi installs.

Check "date" on startup. If the date/time is not being set through NTP the clock be before the start-date validity on most SSL certificates, which means the cert is invalid (from the incorrect perspective of your box) and thus you see connection failures. If that's the case you need to figure out why NTP is failing to reset the clock. In some cases the solution is to add an RTC chip to the Pi so it can persist the date between reboots.

Current "box" images use a "dtb" subfolder when there are a large number of dtb files (Amlogic has 30+ now) but I think when there are smaller numbers of files (cubox/udoo/wandboard are under 10x each) it's okay to keep them in the root folder. This also preserves backwards compat with currnent single-device images as although the content in new extlinux.conf will be difference (using FDTDIR) the file layout didn't change so the same update script we use with Amlogic will work fine for updating dtb (not dtbs).

Overall I prefer to keep the changes within the iMX6 project in the mkimage and release scripts as by-gnome has done. If we want to limit support to specific boards we need to be explicit in picking them by name. Otherwise there is precedent for *cubox* etc. since I do the same with Amlogic to add the dtbs for the SoC families we support only.

darkstar Chainloading mainline u-boot is not a "solution" it is a "workaround" and the root cause of the problem is still not known. AFAIK the .ext file should not need to be recompiled for SD card boot because it is the unsigned u-boot.bin binary with no embedded device-tree, and thus to run it you've already booted (via vendor u-boot) past the point where SD/eMMC selection is in play. As there is no device-tree embedded the file should be usable on more than one device, but is probably SoC generation specific, e.g. GXBB, GXL/GXM, G12A/SM1, G12B might need different files. I'm personally not too interested in using this approach although the current LE "box" image will see/use the file if present. NB: I've also upstreamed support for GT-King/Pro allowing people to run mainline u-boot from eMMC on these devices, particularly for Armbian where people are more keen/willing/able to do that. Those patches will be in-tree once the merge window for U-Boot 2021.04 opens, and they are included in my 2021.01 fork. I'm still hopeful that one of the kernel maintainers we shipped hardware too will be able to pinpoint the real problem and solution.

Hmm.. I wonder what "improvements" have been hacked into the laetst Khadas bootloader. Can you point me towards the name/version of the Android image that you've used. I'm not sure I'm going to understand too much about what the issue could be, but I can try to replicate it.

Not much chance of it being supported under the legacy kernel as AFAICT it was never supported and we've abandoned all work on the 3.14 codebase after LE 9.0 and diverted our attention to modern (5.10+) kernels which while promsing, are still a bit work in progress.

If you can point me to some more recent Linux 5.4-ish (or newer) device tree (overlay) snippets needed to make the shield work, I'd be happy to see if we can get it working on a newer kernel.

tavoc enable SSH and see if you can login to run "dmesg | paste" .. often when users describe "hung" systems it's simply that Kodi doesn't start and thus nothing overwrites the boot splash, but the OS is otherwise running and accessible in the background.

Quote from inertia666

The IP address seems to be on the wrong subnet. My router is set up on 192.168.0.1 and the IP of the Pi is 192.168.0.2.

When I connect to the AP i get an address of 192.168.1.2 and the gateway is 192.168.1.1. So this is wrong for a start.

This is correct because the tether creates a NAT routed (not bridged) connection between the interfaces, so two different subnets will be used. There is no need to set iptables rules or enable forwarding as these are either handled within connman or already enabled in default config.

It would be useful to see "route | paste" before/after the tether is enabled, and "journalctl | paste" after a clean boot, enabling the tether, and connecting a client device. Just share the URLs generated.

Raspberry Pi Imager tool gets the image info direct from LE servers so it used an official release, but we have never embedded cache setting changes in the default images. See:

The default appliance.xml LibreELEC.tv/advancedsettings.xml at libreelec-9.2 · LibreELEC/LibreELEC.tv · GitHub

The extra config applied for RPi LibreELEC.tv/advancedsettings.xml at libreelec-9.2 · LibreELEC/LibreELEC.tv · GitHub

It's not impossible for add-ons to make "helpful" changes that mess up users installs.

tavoc using the box image or the emmc image? (i.e. are you using vendor or mainline u-boot). If you can find the serial cables and capture the boot log it might (or might not) be useful.

Quote from julius

I think this happens after the installation of which I think is the most popular piracy addon (not sure if it is allowed to mention which one), which is working just fine too, but I am not really sure about it.

As long as you have pirate add-on crapware installed, your problem is not our problem.

I do most partitioning work on remote servers via CLI so it's maybe 2.5 years since I last used gparted and I couldn't give you steps without installing a distro to describe it from .. and I'm not interested in that level of spoon-feeding. Just make the SD card again and let the installer expand things on first-boot. I'd guess you can't have installed or done much before running out of space so it's not hard to start over.

I'd say there's huge progress in the drivers all over, but then I find the current GUI performance on RPI4 perfectly fine so I don't know what you see that I don't see etc. .. I'm normally a fairly astute tester (been doing it for a while etc.)

You can instal the Chrome add-on from our repo. Most of the time it works, but sometimes it doesn't .. due to the fun of supporting a constantly iterating moving target piece of software. One of these days Kodi might gain an in-GUI browser, but that's subject to the same issues and is a long-term and slow moving project.

Community created images might have changed something, but LE default images do not contain any embedded advancedsettings changes to cache settings, because if your network is functioning correctly there is no need to ever fiddle with these settings.

I'm sure much was added since, but for reference on FDTDIR [U-Boot] [PATCH] pxe: implement fdtdir extlinux.conf tag