Posts by chewitt

I'm not the creator of Rockchip images btw .. not that it matters now

It's the correct dtb to use, but it's hard to comment on what's happening without seeing the output from the debug UART connector on the board; this shows the early (u-boot) boot process that we need to manipulate to boot Linux. Note that you can't just put the SD card in and boot, you need to invoke recovery boot so that u-boot searches for (and finds) bootscripts on the SD card. Also note that you must not rename the dtb file as with legacy kernel images: https://wiki.libreelec.tv/hardware/amlogic

cp /etc/connman/main.conf /storage/.config/connman_main.conf
sed -i 's/PreferredTechnologies = ethernet,wifi,cellular/PreferredTechnologies = wifi,ethernet,cellular/g' /storage/.config/connman_main.conf
reboot

^ beware the wrapped line in the sed command. This will tell ConnMan to prefer WiFi over Ethernet resulting in the default route to the internet being assigned to wlan0 when both eth0 and wlan0 interfaces are active.

HDR works fine on RPi4/5 in LE11/12 and has done for ages. Put Kodi in debug mode, reboot, then run "pastekodi" from the console and share the URL so we can see what display capabilities are advertised in the TV's EDID data.

You can use "connmanctl" from the console. Obviously if the IP is changed you'll be immediately disconnected.

<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <loglevel hide="false">1</loglevel>
</advancedsettings>

^ this is my /storage/.kodi/userdata/advancedsettings.xml; reboot to effect the change.

"It depends" on how much customisation you've done as the backup function only back's up the /storage/{.cache|.config|.kodi} folders, so if you dumped other things elsewhere on /storage they will be missed.

If you manually wget the RPi5 update file to /storage/.update and then "touch /storage/.update/.nocompat" to disable the checks we do to prevent wrong-image updates you can reboot to update the RPi4 to the RPi5 image. The first stage of update (changing files) will work. The second stage (booting) will probably fail as the RPi5 kernel will have RPi4 things missing. At that point or when the board shuts down to reboot, pull the power, move the card to the RPi5 and power on. Take a backup first and move it somewhere safe, in case somthing goes wrong.

There is no SSH console config/help tool. There are reset functions and log-generation options in the LE settings add-on (in the GUI).

You can self-build the image with an older kernel and firmware source. I doubt you will find anyone volunteering to build you custom images though. Instructions on self-building images are in the wiki. Start with creating a current image, then modify the package.mk for the linux and related firmware packages.

Your message is "Lost in translation" ..

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

PKG_NAME="drm-vc4-grabber"
PKG_VERSION="a0ed242818109d4d7f8bba4830878ce647b6c878"
PKG_SHA256="f5db271b1ddc3dad40477168c1404bbeb4c29e585aaac785926e49462147c596"
PKG_LICENSE="UNKNOWN"
PKG_SITE="https://github.com/rudihorn/drm-vc4-grabber"
PKG_URL="https://github.com/rudihorn/drm-vc4-grabber/archive/${PKG_VERSION}.tar.gz"
PKG_DEPENDS_TARGET="toolchain cargo:host"
PKG_LONGDESC="Raspberry Pi DRM-VC4 grabber for Hyperion"
PKG_TOOLCHAIN="manual"

make_target(){
  export RUSTC_LINKER=${CC}
  cd src
  cargo build \
    --target ${TARGET_NAME} \
    --release
}

If someone wants to experiment further, create packages/addons/addon-depends/drm-vc4-grabber/package.mk with that ^ and then build the package (only compile tested). You'll need to recreate the systemd service and/or figure out further packaging to get things working. For me the binary ends up in build.LibreELEC-RPi5.aarch64-11.80.0/build/drm-vc4-grabber-a0ed242818109d4d7f8bba4830878ce647b6c878/.aarch64-libreelec-linux-gnu/target/aarch64-libreelec-linux-gnu/release/

The minimal content you need is sources.xml, passwords.xml, and guisettings.xml; the latter will have changes specific to a specific hardware type (as RPi has differences to an Intel GPU device etc.) but things are mostly portable. I have 'master' files and a setup bash script stored on a webserver so I can clean-install something, wget the script and run it to configure a clean device for test in a couple of minutes. You probably don't need to go that far though

Running "PROJECT=Generic DEVICE=gbm ARCH=x86_64 scripts/build qtbase" (or the equivalent for other platforms) will build only that package (and any dependencies needed for the package itself or compiling, i.e. the toochain). The current qtbase package.mk probably doesn't pick any of the binaries or library files into the LE image (looks like it's only a compile dependency for Hyperion, I didn't look hard at how it's used) but adding files would be a simple change to make; most package.mk files in our buildsystem do add files so there's lots of prior art to crib how that's done from.

If the long-term intention is to use skyscraper with LE, it's probably worth investing a little time/effort into creating a skyscraper package for our buildsystem. The workflow for compiling is a little different if you're used to working with a conventional distro; though the underlying cross-compile process is the same. Working with a package within our buildsystem will eliminate compat issues that sometimes arise due to differences between e.g. Ubuntu and LE runtime environments, and will also make long-term maintenance easier. Once the intial work to create the package is done you can simply keep your changes in a topic branch and rebase/bump and rebuild skyscraper against later LE releases as needed. Once you have a stable image a quick respin is often a couple of minutes compile time, not a full multi-hour experience.

I'm honestly not sure how I "play" a png file in Kodi?

EDIT: After enabling photos and using "files" to navigating to the dir with the png file the red and magenta bars are showing fine but the text labels for them are not as sharp as the other colours.

Some of the code snippets in the XDA thread mention "s4" which indicates the box has an S905X4 chip. At the current time there is no upstream kernel support for S4 devices. Amlogic started to usptream patches but their staff are lacking experience with kernel coding standards so the process is glacial because each patchset requires many iterations. You probably want to look at CE not LE as their releases are based on the Android vendor kernels.

There's been a few reports of missing HD audio but I haven't had time to investigate. There are mentions on other hardware too so perhaps something changed on the Kodi side and not the kernel for once.

Quote from MIKMXIII

I don't understand why connected via blouthoot my saundbar has better audio than connected via jac 3.5 with the libreelec box

The analogue output DACs used with the 3.5mm jack on most Android boxes are a cheap afterthought. The DAC in the soundbar simply does a better job with the same digital input.