Posts by HiassofT

    Display rotation should be possible by using the rotate and/or panel_orientation options of the video kernel command line parameter.


    eg add something like video=DSI-1:[email protected],panel_orientation=left_side_up


    See the kernel documentation for infos about the video parameter: modedb default video mode support — The Linux Kernel documentation


    The RPi forums might be a better place to ask about DSI/DPI panels and KMS details (I never used DSI/DPI displays myself), I found eg this post there rotate display with DPI and vc4-kms-v3d - Raspberry Pi Forums


    so long,


    Hias

    The lockup seems to be HDMI related, it happens both on LE and RPiOS with latest rpi-update kernel/firmware kernel: drm/vc4: More CPU Stall Fixes · Hexxeh/[email protected] · GitHub (LE uses the same fw/kernel version as this rpi-update commit) when booting without a HDMI monitor connected.


    I already chatted with RPi devs, they'll look at it next week (popcornmix and I also confirmed it still happens with current rpi-5.10.y kernel which contains some fixes in that area).


    Concerning LE kernel config changes: it'd be best if you change the panel driver to "y", so it's available right after boot (otherwise you won't get splash and update notifications on screen).


    Also drop the gpu_mem change from config.txt (that's not needed and only wastes memory) and you can also drop the vc4-kms-v3d dtoverlay line (that's already in distroconfig.txt).


    Better wait with further testing until RPi devs have a kernel fix, serial console won't help too much ATM as you'll only see the kernel is locking up before the vc4 hdmi line should appear (other than that a serial console is really helpful).


    so long,


    Hias

    deltasjimmy can you test if the display is working on RPi OS with the latest rpi-update kernel (currently 5.10.46-v7+)?


    I built an LE image with the missing drivers included, but it just locks up on my RPi3B+ when I add the vc4-kms-dsi-lt070me05000 dtoverlay - and the same happens on RPiOS with latest kernel as well. I don't have any DSI displays here so not sure if that's the cause - the DSI driver is still under heavy development so it could be an issue in latest kernel, too.


    so long,


    Hias

    please find the log here: http://ix.io/3sdk

    Please fix your power supply issues first:

    Code
    RPi throttled=0x50000
    ...
    Feb 02 16:29:48.403857 LibreELEC kernel: Under-voltage detected! (0x00050005)
    Jul 07 14:41:09.639718 LibreELEC-rpi kernel: Under-voltage detected! (0x00050000)
    Jul 07 14:45:16.053017 LibreELEC-rpi kernel: Under-voltage detected! (0x00050005)

    so long,


    Hias

    There's not much you can do with edid editing. Your monitor is probably properly announcing support for 1920x1080 etc modes (otherwise you would not be able to select those) but doesn't handle the limited range pixel data - I have an ancient monitor with the same issue here.


    so long,


    Hias

    Thanks for the logs!


    I just noticed our kernel configs don't include CONFIG_DRM_PANEL_JDI_LT070ME05000 - so the dtoverlay can't work.


    I'll have a look at what other options might be needed, this will take a bit (not sure if I find time this week), but I'll get back to you when I have something for you to test.


    so long,


    Hias

    Which tftp server are you using, is it by chance the netkit one ("tftpd" package in debian/raspbian)? If yes, don't use it, it doesn't work (just tested that here locally) and even the package description warns that it has issues:

    Code
    [email protected]:~$ apt-cache show tftpd
    ...
     Warning: Does not support 'tsize', which is required by some tftp clients,
     especially PXE, and various other network boot clients. For those, use atftpd
     or tftpd-hpa.
    ...

    Both atftpd (which I usually use) and tftpd-hpa work fine here.


    so long,


    Hias

    Hmm, I use the same bootloader version but with a flat layout (firmware etc in TFTP root) it looks very different. I see one request to SERIAL/start4.elf and another one to SERIAL/start.elf, then bootloader falls back to root:


    Your log however shows SERIAL/start4.elf requests repeating in 2 second intervals - and tftpd serving it (?)


    Might be worth digging into the tftp config/setup, something seems to be odd there (maybe permissions or timeouts).


    For reference here's my bootloader config (basically default settings, except for boot uart and order)

    so long,


    Hias

    Unfortunately the kodi crash logs are again empty and the other ones don't show you playing a file.


    It looks though that mount.ntfs triggered the OOM killer - which makes me guess you played the video from an NTFS formatted USB drive. Can you try if copying the video to SD card and playing from there works?


    so long,


    Hias

    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 "@[email protected]" 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/@[email protected] disk=NFS=192.168.1.20:/wd/srv/le-storage/@[email protected]

    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

    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