Posts by HiassofT

  • LE10 network boot (PXE) with Pi4/B 4GB doesn't work

    How did you populate the TFTP directory?

    In general copying all files from the FAT partition of the SD card should just work (after adjusting cmdline.txt). If you populated it from the contents of the tarball you'll need to rename KERNEL to kernel.img.

    Netbooting LE10 on RPi4s is working fine here, I've been doing that for a while now for easy development testing.

    I chose to organize TFTP and NFS directories using the RPi4 serial number at the top level, RPi4 firmware looks there first when TFTP-booting (and then falls back to TFTP root dir). This makes it easy to serve different (LE) versions to different RPis and the LE init script also supports that quite well, it substitutes "@UID@" in boot/disk with the serial - so I can use an identical cmdline.txt for all installations. The relevant part of cmdline.txt looks like this here:

    Code
    ip=dhcp boot=NFS=192.168.1.20:/wd/srv/tftp/@UID@ disk=NFS=192.168.1.20:/wd/srv/le-storage/@UID@

    TFTP root directory (I'm using atftpd here) is /wd/srv/tftp and /wd/srv is exported via NFS, and my DHCP server announces the TFTP server via option 66 (tftp in dnsmasq) in DHCP replies.

    Check your tftp logs, also for missing files. For reference here's the tftp log output from a boot here:

    so long,

    Hias

  • LE10 network boot (PXE) with Pi4/B 4GB doesn't work

    RPi4 doesn't need bootcode.bin or a SD card, everything's in the boot eeprom - just make sure it's up-to-date and network boot is enabled in BOOT_ORDER.

    Copying the contents of the FAT partition on the SD card to a directory served via TFTP and NFS and creating a NFS share for the storage partition is enough - the bootloader in eeprom will fall back to start.elf if start4.elf can't be found.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    Quote from JohnWayne111

    Hias, thanks a lot!

    However im wondering due to experimental status.

    I hope, Beta 5is the last before LE 10 :)

    RPi4 code is still under heavy development, with new features and bugfixes coming in at a quite regular pace, so RPi4 builds should be considered stable-beta even if LE 10.0 final is released (as also announced in the blog posts).

    The recent kernel update was quite a disruptive change, not only adding 4kp60 support but also switching the internal audio driver code, so any feedback on nightly builds is highly welcome. I'd expect future kernel changes to be far less disruptive, more focusing on ironing out remaining bugs.

    so long,

    Hias

  • RPi4 testbuild with HDR support

    4kp60 output isn't supported in any of the current beta versions up to and including beta 5 - enabling 4kp60 in config.txt results in "no signal" issues so you shouldn't do that.

    It took quite a while to get 4kp60 working properly (the kernel driver change was quite involved) so I deliberately waited after the beta 5 release before adding it - there are probably still issues we missed so this needs some time testing in nightly builds.

    So consider this a bit experimental.

    so long,

    Hias

  • Cant play 4K MKV files without crashing

    Keep GPU, CMA and buffer settings as they are, changing those is quite dangerous, rarely helps and most often results in non-working or unstable systems.

    If kodi crashed you should have a kodi_crash.log file in /storage/.kodi/temp/ - please upload that (or just use the crash log upload function in LE settings).

    The "new" log doesn't show you playing a video file, the "old" one shows you played a file with TrueHD audio. There are a couple of known issues with TrueHD in kodi, so try selecting a different audio stream (eg the AC3 one) and see if this works.

    so long,

    Hias

  • Massive performance deterioration after time

    Quote from mglae
    Code
    Feb 02 15:29:47 LibreELEC kernel: scsi host0: uas

    Is STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this - Raspberry Pi Forums still an issue on RPI4?

    Yes, it is, but usually it manifests itself in tons of USB errors, disconnects/reconnects etc in dmesg - which does not seem to be the case here (journal was clean in that respect).

    so long,

    Hias

  • Massive performance deterioration after time

    Thanks for the log! The only suspicious entries are these:

    Code
    Feb 02 15:29:49 LibreELEC udevil[707]: The disk contains an unclean file system (0, 1).
Feb 02 15:29:49 LibreELEC udevil[707]: The file system wasn't safely closed on Windows. Fixing.

    Checking the filesystem of the NTFS drive on Windows might be worth a try - but the log doesn't contain any of the usual USB issues messages so not really sure what's happening there.

    so long,

    Hias