Posts by chewitt

We bumped the add-on version due to Kodi API changes in K19 RC1 so you'll need to wait until the add-ons have finished rebuilding and been published to our repo. Build runs are in-progress and should be done sometime later today depending on where in the world you are.

jkbadouvas Oleg's images are K19 only.

Start by answering the question: does the wlan0 MAC address change on each reboot?

lsusb blindly shows whatever is attached to the USB bus, it has nothing to do with the kernel loading drivers or usability of the hardware

I won't bother making any futher effort then. G'night.

Quote from Biomecanoid

So to sum up add on cards like the Broadcom Crystal HD Mini-PCIe are no longer supported and the only offloading the CPU can do is to a real not onboard Nvidia/AMD GPU. Correct ?

Preference for GPU vendor is #1 Intel > #2 AMD > #3 nVidia .. because nVidia does not support GBM (only their proprietary alernative, EGL streams) and Kodi does not support EGL Streams; so when we drop X11 support and use GBM/V4L2 on everything (hopefully for LE11) an nVidia card will not work with LE anymore. You'd still have the option to use Kodi under another distro, but not LE.

Historically "wifi doesn't remember the passphrase" frequently traces back to wifi cards with a MAC address that changes on each boot. As the MAC is used in the connman service identifier, format "wps_macinbase64_ssidinbase64" each time you reboot there is no matching stored service and you are (correctly) required to configure the network again. You can diagnose this by checking the MAC listed for the WLAN interface in "ifconfig" over a couple of reboots. If yes, knaerzche might want to investigate adding RK details to the "ethmactool" script I wrote for Amlogic which basically sets the MAC from the CPU serial from userspace (regardless of what comes from u-boot/kernel) to ensure the MAC is unique and persistent.

These days there is nothing "add-on" like the broadcom card (which had horrible drivers btw) so it's more economical and sensible to change the whole device. The eco-friendly negative of "dumping" the old box is somewhat offset by switching to something that uses considerably less power to run.

K18 is closed to fixes as there will be no more K18 releases made. K19 does not currently support the 3D stuff but I'd expect the Pi Foundation folks to work on that at some point (don't hold breath tho).

I'd guess you need to compile a custom LE image with whatever nftables module changes you need in the project/device kernel defconfig.

I removed the original posts because they are full of product links and read like advertorials. In response to the initial question: these devices have tiny screens which are not suited to Kodi use and I'm not aware of any interest in supporting them with LE images. Lakka and Batocera will be much better suited to them.

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.