Posts by chewitt

    I'm guessing it's an older OE install that was cross-graded to LE at some point. OE used a 235MB boot partition and LE 7.x/8.x are around 230MB so fit within that partition size constraint. The LE 9.0 image has grown a little due to drivers and such and the 235MB boot partition is now too small to host the files so the upgrade aborts. To fix this you have two choices:

    a) Backup the LE 8.2.5 install and move the backup file off-box, then clean install LE 8.2.5 (which gives you a 512MB boot partition) and then restore the backup; then update to LE9.0. This is normally the fastest option as most LE installs only have 1-4GB of actual Kodi data on the /storage partition that needs to be backed-up and moved and the reinstall/restore process is quick.

    b) Boot an Ubuntu (or similar) LiveUSB and use gparted to shrink and then relocate the /storage partition to create space for the boot partition to be size expanded to 512MB or 1GB (whatever you fancy). This is normally the slower of the two options as you end up moving 31GB of data on disk.

    To set expectations on the N2 correctly: the mainline kernel is currently missing essentials like HDMI audio and hardware video decoding (both are active work in progress) and until G12 support reaches parity with existing GX hardware common missing items like 4K/10-bit video, AFBC and HDR won't see development effort. HDR is missing for Linux globally (pending changes from Intel being merged) but I have sub-zero concerns about LE/Kodi support and that topic. Otherwise, we already have the basics of an image working (see below). RIght now it's not much use to anyone without audio but the N2 is fast enough to software decode most 8-bit media that I've played and that's with the kernel still lacking dvfs so the CPUs are clocled to 1.2GHz not 1.8GHz. It runs cool due to the huge passive heatsink that forms part of the casing. The fact that it needs such a huge heatsink proves that some peoples concerns that S922X chips run hot are valid, but HK appear to have thought about that and it's nice to see passive cooling instead of the small heatink and fan arrangements that are being put into "Android box" packaging.

    In case anyone is wondering .. S905X2 is also up/running in the same state as S922X:

    I'm looking forward to a fun summer of mainline kernels and GBM/V4L2 awesomeness :)

    If the WiFi device uses an in-kernel driver it supports the required frameworks for iwd. If it depends on loading an out-of-tree driver it's probably not going to be supported.

    Anyone thinking we're being awkward about these drivers should read Could someone add rtl8811au? And for Raspberry Pi support? · Issue #346 · lwfinger/rtlwifi_new · GitHub which is how the developer responsible for more realtek wifi support in the upstream kernel than anyone else feels about them :)

    Python3 is a Kodi v19 thing. Most of those screensavers are just neglected by their creators. One of the Kodi developers @alwinus has recently done a major overhaul of some (but not all) of the broken ones, and those changes should be picked up in Kodi 18.2.

    If the external USB device was detected the connections tab in LE settings will show "duplicate" wireless networks (as there are two interfaces seeing each network) but each network is tagged with the interface that saw it, i.e. wlan0 or wlan1. The fun part is that with slow loading SSV6051P drivers and normally slow loading USB drivers .. which device is wlan0 and wlan1 is a bit of a gamble; it's determined by module load order in the kernel which is not fixed. Assuming the USB device is detected, the best thing to do is "echo blacklist ssv6051p > /storage/.config/modprobe.d/ssv6051p.conf" and reboot to prevent the driver loading .. which leaves only one interface.

    Connman enables tethering by technology not by interface. It probably prefers tethering on wlan0 but honestly I've never tested that.

    Connman gained the ability to ignore ntp from gateways (e.g. the dns/dhcp service in domestic routers) in these commits which LE includes

    connman/connman.git - Connection Manager

    connman/connman.git - Connection Manager

    connman/connman.git - Connection Manager

    but I recently noticed a typo which means it cannot work:

    connman/connman.git - Connection Manager

    Connman was version bumped to include this and other fixes in our master and 9.0 branches in the last couple of days, so assuming this is related to the issue, it should be resolved [sic] in the next LE update.

    It's worth pointing out that the Linux kernel currently has no HDR support. It is active "work in progress" from Intel, albeit rather slow progress due to the large number of other drivers (and companies with commercial interests) that will consume the same changes once merged (so lots of cooks in the kitchen sharing their opinions). One of the component patch series' is now on it's 17th iteration so things are hopefully nearing a conclusion.

    Kodi GBM/V4L2 support is still in a fluid state as the underlying changes to Linux kernel things aren't cast in stone yet, but at some point they will become a more static target, and from that point forwards change becomes much easier to manage. Support on the Kodi side really comes down to GBM/V4L2 providing a single code-path into FFmpeg which handles a small number of different code-paths (stateless, statefull, vaapi) depending on which SOC or GPU hardware is being used. There are 5-6 developers actively working on that area of code; roughly representing RK, Allwinner (stateless) and Amlogic, Raspberry Pi (statefull) and Intel/AMD (vaapi) interfaces. Once you drop lower in the stack to the kernel driver code things appear to be more of a one-man effort because kernel DRM drivers tend to have a primary maintainer driving things forwards, but in all cases there's a community of other developers actively testing and contributing towards that driver and the surrounding stack. LE tends to have a single developer 'representative' among a group of developers working on code and influencing direction. We actively and successfully position Kodi as a fun and useful test application, and since many of the community developers have competing professional or commercial interests we often fulfil a role as a neutral test-case and it's common to see "good Kodi support" somewhere on the written agenda for V4L2 graphics initiatives.

    Rockchip (and others) are in limbo at the moment while we wait for some upstream kernel changes to land. This is completely out of our control but it will happen (as big companies like Intel need it to) and then we'll start to show progress again. Raspberry Pi and its legion of supporters are ultimately dependent on the same changes and will also be moving wholesale to the Kodi GBM/V4L2 stack for LE10. Many things become interconnected in a way that makes it impossible to promise that Rockchip support will not drop off, but equally these changes makes it fundamentally more improbable this this will occur :)

    Users sometimes mistake LE being a small and efficient Linux distro for it being ideal for using on old hardware, but our focus is on current and recent hardware so we are frequently missing drivers and support for older devices. That said, unless you tell us exactly what the hardware is (and share the dmesg output) all we can do is make broad statements ^ and guess at the issue.

    Your box is from a vendor who saved pennies by not securing a unique MAC address range for their products. As a result the NIC in your box does not have a programmed (fixed) MAC address. Under Android the kernel has been hacked to assign a static MAC address (normally unique to the 20k or so boxes in the production run). Under Linux the kernel hack doesn't exist. If you're lucky you get a different static MAC. If you're less lucky the kernel will generate a random MAC that changes on each boot. If can be "fixed" with a udev rule or systemd service that corrects it during boot. There's some threads on the topic in this forum if you search for them.