Posts by chewitt

  • S802/S812-Libreelec images for 7/8/9

    You'll probably find the vendor u-boot forces the partitions to a read-only state so the pre-mount fsck our init script fails and we abort. You can probably fiddle your way around that with a custom image (that changes init) or custom autoscripts. You'll need to hook a UART cable to the board and see if you can interrupt u-boot to see/dump the environment (which contains all the boot config and scripts) to figure out what's being done and how to work with or around them. The challenge with older boards is that u-boot is often home-grown and quite restrictive and there's less consistency among devices. In later generations most vendors typically follow the prescribed config from Amlogic which despite some fugly hackery is reasonably simple and open to work with.

  • IPSEC VPN

    You would need to recompile the LE distro image with the required kernel config options needed for IPSeC support and the connman build options needed for userspace configuration of IPSeC tunnels via connman vpn plugins (have a look at our past support for PPTP for ideas). There are no HOWTO guides for this and IPSeC is not something we're interested in supporting in our default images so you will need to take the initiative.

  • Choosing a S905 / S905X / S905D / S905W / S912 box guide

    Amlogic releases their BSP codebase which is the same awful code from 3.10 ported to 3.14 ported to 4.9 ported to 4.19 (in process) where each iteration focusses only on supporting their latest/greatest chipsets. Their technical focus on new devices frequently stomps on support for older devices so it's a long-term nightmare to support a wide range of devices with and you cannot take the latest buildroot release and use it with Meson 8. It's also fragile code which is a pain in the arse to maintain; fixing one problem constantly breaks something else. LE's strategy is to move all of our target hardware platforms onto mainline kernel to solve these issues; mainline provides a maintainable codebase that supports a broad range of hardware using well written drivers using modern kernel API frameworks. The root of the problems with the BSP drivers is they were written long before many of the upstream frameworks existed (or matured) so Amlogic evolved their own proprietary ones (with no external scrutiny, hence the many architectural and code quality issues). This means the BSP drivers don't fit modern kernels and writing from scratch is cleaner and usually easier than attempting to adapt them. The solution for Meson 8 is someone (Martin B unless anyone else starts contributing) writing a new HDMI driver that fits into the current kernel DRM (direct rendering manager) framework. There's been a lot of work in the last 18m on the dw-hdmi IP Amlogic used with GXBB and up (and common with Allwinner/Rockchip). Meson 8 uses different IP so it needs a different driver, but dw-hdmi provides strong guidance on what the structure of the missing driver needs to be like. I'm confident it will happen, but HDMI drivers are complex, there is limited documentation on the IP used (and the in-use BSP drivers frequently disagree with Amlogic's internal documentation) so it's a reverse engineering effort. Martin has been experimenting with HDMI code for a while now, but it's only quite recently that surrounding core board support was really in a stable enough or complete enough state to start making a serious effort. And I'm sure he has a life outside of poking Meson 8 code, so it won't be quick.

  • Virtual LibreELEC

    I'm not sure who added KVM to the OVA description but AFAIK no staff members run it on KVM and we've never formally supported "user" use on any form of virtual platform (we create it as a staff userspace development/testing tool) so the description should be corrected to remove the reference.

  • request ZFS

    LE has a long history of encouraging community created images that prove the relevance of features to our userbase and you are welcome to release images with ZFS support via our forums. If we see broad use (we track stats from named builders so we can see exact numbers) we would be happy to "adopt" the capability and make it more generally available. Historicially most storage related things (encryption, RAID, etc.) remain niche but we keep an open mind.

  • Kodi 18.0 Update for Slice.

    The original SliceOS update function is based on noobs and points to files that probably don't exist anymore (as 5Ninjas are no longer around). I would clean install the current LE image (re-flash the eMMC storage) .. Kodi v15 (SliceOS) to Kodi v18.5 is a large jump.

  • Can't get 5Ghz AP to work (Raspberry Pi 3+ and Pi4)

    The connman tethered AP feature "is what it is" unless someone submits code to connman to add features and we (LE staff) have no plans to start writing connman features. It's probably not impossible to add packages for host_apd and more fucntions, but we have no desire to be a router OS so there are no plans to do that either - but we're open source so you're welcome to experiment on your own. The practical solution to "I want a cheap wireless router" is to get a cheap (hardware) router. Or you can switch distro to something with package management that allows configurability. LE is by deliberate design a locked-down and fixed medicentre purpose (not router or general purpose) distro.