Posts by chewitt

Feel free to PR the best working files to the LE repo using device-specific filenames.

If it's a simple "okay" enable I'd do that from userspace using an fdtput command that's executed by a systemd service; as updates will always overwrite the modified dtb with a clean one.

Random guessing: image this to an SD card: https://github.com/LibreELEC/Libr…/bootloader.img

Then write the LE 9.2.8 image to a USB stick, connect both SD and USB devices, boot and see what happens. If you're lucky it will find u-boot on the SD card, boot it, and then u-boot will find the LE 9.2 image on USB and boot the LE kernel.

If that doesn't work, try the process again with https://github.com/LibreELEC/Libr…es/recovery.img written to the SD card instead.

If you can connect the serial UART cable to the board to literally 'see' the boot process it will help you (else you are blind to what actually happens). WeTek did ship one with the box.

The primary challenge you have is that S905 boards look for a signed boot header in different locations on SD/USB and eMMC boot media, hence an image of the factory Android image on eMMC (which we have) will not boot from SD as the SoC cannot find the signature. The LE 9.2.8 image does not include u-boot at all as LE relies on the factory u-boot being installed to eMMC. The LE12 image boots as this does include u-boot and the .img is specially built to have the signed boot header in both eMMC and SD/USB locations; but I doubt modern u-boot can boot the legacy images (have never tried). In theory it's possible to create your own Amlogic u-boot binary then sign it using the FIP sources in https://github.com/LibreELEC/amlo…ter/wetek-play2 .. but there's no guides for that kind of thing.

I've tried really hard, but I'm unable to use mind-reading to understand the problems on your device 12,000Km away. As per post #4, you'll need to share a debug log to get an answer.

It's useful to have a large collection of experimental nightly images on the test server so less technical users can self-triage issues by stepping backwards in time and figuring out when a problem first occurs. Our goal is to store the largest number of files that we can, and that's not going to change, even if it slows the updater a little.

In the absence of a debug log .. we have no idea what the issue is

It probably has something to-do with the media height being outside match parameters in code. The first (working) media is normal 2160p while the second (non-working) is 1592p. I'd expect that if you re-encode the file to a 2160p resolution (adding black bars) the resolution will match whitelist entries and play correctly. I'm not aware of any other remedy..

You cannot store things directly in /var/lib/alsa because /var resides inside a read-only squashfs file that's decompressed on boot to create a non-persistent virtual filesystem.

You can put symlinks inside the read-only squashfs file that relocate the directory to locations like /storage/.cache/alsa which can persist data on a read-write volume. You can have systemd create directories on first-boot as needed; see packages/network/bluez/tmpfiles.d/z_05_bluez.conf for an example.

The boot issue should be resolved in LE12 images; e.g. the C2 image here: https://chewitt.libreelec.tv/testing/

CONFIG_USB_OTG=y is set in the kernel defconfig so it's built-in not a loadable module but dr_mode is set to "host" not "otg" in the upstream C2 device-tree so you'll need to change that; either with a tweaked and recompiled device-tree or with fdtput commands executed from userspace at boot-time.

If it's possible to use a compile time option to change/specify the state location we can modify the relevant alsa package.mk to set that to a /run/alsa/ or /storage/.cache/alsa location at compile time. If there's none in current code we probably need to find where it's defined in code and patch the location (or patch making it configurable and send the patch upstream).

Quote from dpapavas

My only concern is with testing, as LE runs on a lot of disparate setups and I can only test it on one of those.

It would be good to have something submitted that can be smoke-tested and critiqued by staff first, then after LE12 ships (so early in the LE13 cycle) we can merge the change to nightlies. If there are minor problems we work on fixing them, and if there are major ones we can revert the changes and rethink.

In short, as long as you're patient and understanding (this is a large change, we'll be cautious about it) .. all will be fine

On the RPi4:

touch /storage/.update/.nocompat
cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-RPi5.arm-11.0.6.img.gz
reboot

On reboot the RPi4 updates to the RPi5 image, and on completion and second reboot it attempts to boot the RPi5 image. This will either fail or half-work so it's best to pull power on the RPi4 as the second reboot starts. Now transfer the SD card to the RPi5 and things should work.

Or .. do a clean install and manual copy/paste migration of any essential content from the RPi4. The boards use different images so unlike previous RPi2 > RPi3 migrations you cannot simply swap the card.

In 99% of "stuck on boot screen" reports the OS/system is running and can be accessed via SSH. In the case of a VM that won't be simple as the SSH daemon is not enabled by default and you'd need to mount the VM disk from another Linux VM to access the boot partition and edit syslinux.cfg to force it on by adding "ssh" to kernel boot params. However the Samba server should be running so if you find/access the "Logfiles" share the OS will generate a zip file with logs. If you share that file here we can see the boot log and that might give some clues on what's not working. It's most likely an issue with graphics drivers, as no GPU = no GBM surface for Kodi to render a GUI onto, but we'd need to see error messages to understand the problem.

NB: The OVA exists solely to support internal development/testing and sometimes gets broken and isn't updated/fixed until the next time someone on staff needs it to work again. In short, it's not something we formally support or spend much time on.

LE does not support dual-boot and our installer will nuke anything else on the same target disk. Mint installer will be more flexible and should allow install into a specific partition, but if LE was installed first there isn't a spare partition so you may be nuking bits of LE when installing Mint, and Mint probably installs its own bootloader (overwriting ours) and either doesn't support making pretty menus that include existing other OS on the disk or it does a bad job of that.

The LE installer simply creates two partitions; one for boot files (SYSTEM/KERNEL and syslinux.conf) and one for a persistent storage area (/storage) and it installs the syslinux bootloader to the root of the disk. We are not dependent on syslinux; any bootloader will be fine, so it will be best to install Mint with a partition scheme that allows for LE being manually installed (copy boot files over) and with a manually created entry in the Mint-installed bootloader (they probably use grub).

TL/DR: there's a reason why we don't support or provide support on dual/mult-boot arrangements. Good luck

Look for a "portable" win7 or win10 image .. there are lots around, and HDMI/LSPCON firmware updates do solve a lot of problems

chewitt@toolbox:~/LibreELEC.rpi$ git grep HID_PLAYSTATION
...
projects/RPi/devices/RPi/linux/linux.arm.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi2/linux/linux.arm.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi4/linux/linux.aarch64.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi5/linux/linux.aarch64.conf:CONFIG_HID_PLAYSTATION=y

The driver is enabled in our kernel configs ^ and I confirm it works with a PS4 controller via Bluetooth (code for the PS4 controller was ported from CONFIG_HID_SONY after the hid-playstation driver came into existence).

Is anything reported in dmesg? (share a logfile)

Quote from dpapavas

We'll hopefully know in a day or two, or sooner if I'm not lucky.

Fingers crossed .. keep me posted