Posts by chewitt

The image you downloaded is for eMMC install. It will not boot from an SD card unless the eMMC has been wiped. If you want to keep Android or some other Linux on the eMMC you can use the "box" image, edit the dtb name in uEnv.ini first. Once booted from SD, you can use "emmctool" to write the other emmc image to the internal storage.

GItHub can sometimes redo githashes .. it happens. You'll need too edit the package.mk and correct (or null) the SHA256 hash.

It's not possible to build from local source folders, it's just not how the build-system was designed to work. I use the following script to automate the process of generating a patch-set from the committed changes beyond a specific githash that typically corresponds to a release tag. This way I can tweak things like device-trees in a kernel branch, commit the changes, then swap to another terminal window where I run the script to update the patches, and then I respin the image with changes. This is probably as-fast as fidddling with sources, and forces me to commit/squash and rebase changes in a more structured way. See:

#!/bin/bash

# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2018-present Team LibreELEC (https://libreelec.tv)

AHASH="750a3d9fd8811c2fbbd58df1e08075c8255ca40b" # alsa-lib
FHASH="e64a745eca6b7ad87b64b493a771003ae7f67c70" # FFmpeg 4.2.2-kodi
UHASH="36fec02b1f90b92cf51ec531564f9284eae27ab4" # U-boot 2020.04
KHASH="2ef96a5bb12be62ef75b5828c0aab838ebb29cb8" # Linux 5.7-rc5

if [ -f .git/config ]; then
  DIR=$(pwd)
else
  echo "not in git root folder, exiting.."
  exit 1
fi

do_patchset(){
  rm $PATCHES/$PPREFIX*.patch 2&>/dev/null
  cd ~/$SOURCES
  rm *.patch 2&>/dev/null
  git format-patch --start-number 0001 $GITHASH
  for filename in *.patch; do mv "$filename" "$PPREFIX-$filename"; done;
  mv *.patch $DIR/$PATCHES/
  cd $DIR
}

case $1 in
  allwinner|all)
    PATCHES="packages/linux/patches/allwinner"
    SOURCES="linux.chewitt"
    GITHASH="$KHASH"
    PPREFIX="allwinner"
    ;;
  amlogic|aml)
    PATCHES="packages/linux/patches/amlogic"
    SOURCES="linux.chewitt"
    GITHASH="$KHASH"
    PPREFIX="amlogic"
    ;;
  rockchip|rk)
    PATCHES="packages/linux/patches/rockchip"
    SOURCES="linux.chewitt"
    GITHASH="$KHASH"
    PPREFIX="rockchip"
    ;;
  samsung|exynos|ex)
    PATCHES="packages/linux/patches/samsung"
    SOURCES="linux.chewitt"
    GITHASH="$KHASH"
    PPREFIX="samsung"
    ;;
  alsa)
    PATCHES="packages/audio/alsa-lib/patches"
    SOURCES="alsa-lib.chewitt"
    GITHASH="$AHASH"
    PPREFIX="amlogic"
    ;;
  ffmpeg|ff)
    PATCHES="packages/multimedia/ffmpeg/patches/amlogic"
    SOURCES="ffmpeg.chewitt"
    GITHASH="$FHASH"
    PPREFIX="ffmpeg"
    ;;
  u-boot|uboot|ub)
    PATCHES="packages/tools/u-boot/patches/amlogic"
    SOURCES="u-boot.chewitt"
    GITHASH="$UHASH"
    PPREFIX="u-boot"
    ;;
  *)
    echo "error, nothing selected!"
    exit 1
    ;;
esac

do_patchset

exit

The LE settings add-on checks for updates against update.libreelec.tv which is on 46.101.13.226 which also hosts our main website, and PTR records for that server are probably wrong or out of date. Kodi uses add-ons (so you're using some, even if you don't use add-ons) and Kodi will redirect checks all over the place based on mirrorbits redirection so you will always see some "random" connections.

You can probably bump to the newest Leia version, but I don't know about dependencies between Kodi and the kernel as I never took a deep interest in the legacy Amlogic codebase.

You can change/overwrite it in the LE settings add-on.

Core boxes are long out of stock but vendors normally have some support spares and I made it clear anything they unearth in the back of a cupboard will be fine for my/our needs. Hardkernel also posted a C1+ when they shipped a C4 sample so now I have a couple of Meson 8 things to play with over the summer.

u-boot/firefly-rk3399_defconfig at master · u-boot/u-boot · GitHub

^ find the correct defconfig for ROC-RK3399-PC and check CONFIG_DEFAULT_FDT_FILE

Connection configuration data is stored in /storage/.cache/connman/ but you should change configs through connman (connmanctl) as it manages those files and will probably overwrite any changes that you make. If you do want to manually edit, stop connman.service first, edit, then restart. You'll discover that SSID and passphrase data are base64 encoded so you cannot simply type new details in.

WeTek posted me a Core box the other day and have share their u-boot sources so I can start to look at what might be required to support the boxes again in the future. There's still a lot of work to be done for Meson8 support though, so it will be a lower priority thing to track.

Possibly an issue with newer GCC host binaries. I'd suggest building 9.0 images on Ubuntu 16.04 or 18.04 (looks like 20.04 in the screenshot).

The skin creator would need to add our icon and conditional shortcut the same way that it's done for the default Estuary skin (not hard to do) but the add-on can also be accessed from Add-ons > Program Add-ons on the Home screen menu.

1. Correct, it changes the behaviour of firmware which results in more power draw (which increases heat).

3. "mount -o remount/rw /flash" will remove the ro block on the boot partition. It and /storage are the only persistent writeable areas of the filesystem, as everything is inside a squashfs compressed file SYSTEM that's expanded on each boot, or the KERNEL file.

We don't use /etc/fstab which is why it's blank and you cannot edit or override the file. It only exists because some other Linux plumbing looks for it and craps out when it doesn't (even if the file is blank). We use udevil for mounting and it's possible to override our default udev rules if you want to (use a file with the same name in /storage/udev.rules.d). I guess when all the upstream sources adopt noatime we'll acquire the same change. Until then, we'll stick to the accepted defaults.

LE currently implements exFAT via FUSE which runs in userspace and so is rather slow. In the near-term future LE10 will probably bump to newer kernels which now have the new/official Microsoft exFAT driver implemented (Linux 5.7 IIRC) so the driver runs in-kernel and should be an order of magnitude faster to use; performance should be on-par with other in-kernel drivers like the VFAT drivers we use for FAT16/FAT32.

ConnMan checks ipv4.connman.net on boot to see if it's online or not. If the network is online Kodi will then start and numerous Kodi add-ons will check for updates by making a request to a Kodi URL which will redirect to a mirror hosted by one of 30+ independent mirror sites. Kodi uses mirrorbits which will geolocate your IP and recommend a server near to you, but you have no control over which one. The LE settings add-on will also start and check our infra for updates. This request is fulfilled by our infrastructure but if you choose to update the request will be redirected to one of our mirror sites and mirrorbrain will redirect you - and you have no control over which one. Individual add-ons that you install may also check for stuff.

Both LE and Kodi devs are quite security conscious, but we're also a simple client OS designed for watching TV so security is a deliberate and measured compromise around ease-of-use and we're not attempting to be the most seure device possible (as that OS is a pain in the arse for noob users to work with). TL/DR; If you don't trust LE/Kodi .. place it in a separate VLAN on youor network and implement firewall rules to prevent it reaching other devices.

Martin's branches are here: Branches · xdarklight/linux · GitHub .. note the amount of "WIP" items and don't get too excited

Put the device on a static DHCP reservation so you can SSH in after booting and share logs to see why the screen is black.