Posts by HarryH

    Hi Ajay,

    Maybe you just overlooked it. If you are not familiar with technical abbreviation like PSU, please ask.
    Da Flex already provided the solution. If you ignore that, you shouldn’t expect additional support.

    Quote

    Thanks for the log. Replace your PSU

    Your Pi doesn‘t get enough energy. The power supply that you currently use seems undersized or defective. That will also trigger other unexpected issues, and could be the reason for the WiFi issues too. So the only solution is to replace the power supply first.

    It’s not impossible, but I currently doesn‘t know about changes in the images, which are related to these scripts.
    If it‘s working now, I‘m happy and will not touch the scripts. :) Perhaps only to add some version comments and replacing the deprecated usleep command, no functional change.

    For documentation purposes, please can you provide the following informations?

    • config.txt
      cat /flash/config.txt
    • kernel log
      dmesg | grep -i uart
    • ls -la /dev/ttyAMA*
    • pinctrl -p get
    • Do you know which version of the RemotePi do you have? I read about, that the pcb has a current limiter to prevent damages at RPi pcb. But this can also restrict the current to much for your RPi5 and you are get in trouble, because not enough power.
    Quote

    I don’t know if it’s due to the board but when I connect the power to the board the pi5 shutdown just after start

    Do you have this strange behavior only since you tried the pinctrl version? Have you updated to the current version?

    The GPIO15 seems to me to be the more important signal for shutting down. It may be triggered the MCU on the RemotePi pcb before the irwitch.sh script was started. These 2 pins (GPIO14/15) are part of UART0. Depending on your bootloader/EEPROM settings and config.txt, conflicts can occur. But this conflict should also exist if you have not installed the script. Can you check without the scripts, if the shutdown also is initiated automatically?

    This information would be important for me to know.

    The original intention was, that you repeat this for every gpiochip.

    • gpiochip512

      Code
      cat /sys/class/gpio/gpiochip512/ngpio
      cat /sys/class/gpio/gpiochip512/label
    • gpiochip544

      Code
      cat /sys/class/gpio/gpiochip544/ngpio
      cat /sys/class/gpio/gpiochip544/label
    • gpiochip548

      Code
      cat /sys/class/gpio/gpiochip548/ngpio
      cat /sys/class/gpio/gpiochip548/label
    • gpiochip565

      Code
      cat /sys/class/gpio/gpiochip565/ngpio
      cat /sys/class/gpio/gpiochip565/label
    • gpiochip571

      Code
      cat /sys/class/gpio/gpiochip571/ngpio
      cat /sys/class/gpio/gpiochip571/label

    But I think, that I know the answer. You can check the gpiochip571 and you should get "54" for ngpio and "pinctrl-rp1" for label as the return values.

    Quote

    I have to do more tests when I get home, but it seems to be ok
    Thanks a lot

    Have you had time to test more? Are there any problems or is it working?

    I was afraid that the pin number was to generic and could be used at the wrong pin. So I have changed the pinctrl script version some minutes ago. Please check the new version.

    Unfortunately, it did not help. Should I comment out "force_turbo=1" also?

    Generated a logfile with that setup, too:

    https://paste.libreelec.tv/driven-macaque.log

    Edit: As I'am was writing HiassofT posted a possible solution. Please try his image first.

    Only for completeness:

    If you comment out the line, you can't make wrong. It's not default in LibreELEC. For troubleshooting purposes you can also comment out this line

    hdmi_enable_4kp60=1

    The first line forces that the ARM cores not going back to a lower frequency and stuck at the highest allowed clock rate. hdmi_enable_4kp60 forces the gpu_clock to 550MHz instead of 500MHz.

    If you doesn't depends on Bluetooth for keyboard/headphones or something like that, can you check with this line added ?:
    dtoverlay=disable-bt

    In the meanwhile I have played a little bit with pinctrl. But it's now your part to test if it works.


    I think it's the same as Rpi4 on libreelec 12 but it doesn't work if i use GPIOpin=527 and GPIOpin1=526

    To make it complete, please check every listed chip:

    Code
    cat /sys/class/gpio/gpiochip512/ngpio
    cat /sys/class/gpio/gpiochip512/label

    The correct one has 58 on the RPi4 (but the pin count could be split/vary on RPi5) as the return value for ngpio and I'm assuming the label is "pinctrl-bcm2712" or something similar.

    EDIT:
    Benoitone I have added pull-down for the input pin, to be ensure the pin isn't floating.

    The root cause of your script is that the usage of sysfs-gpio is deprecated. Now with kernels > 6.5 it was changed. You should first inspect which gpiochips are presented in your case.
    ls -la /sys/class/gpio

    Bash
    # ls -la /sys/class/gpio/
    total 0
    drwxr-xr-x    2 root     root             0 Feb 27 18:26 .
    drwxr-xr-x   50 root     root             0 Jan  1  1970 ..
    --w-------    1 root     root          4096 Apr  9 18:16 export
    lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip512 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip512
    lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip570 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip570
    --w-------    1 root     root          4096 Apr  9 18:17 unexport

    I don't know if it's a fixed value for RPi < RPi5. For the RPi4 gpiochip512 seems to be the right thing. Since it's not 0 like before, you now need to add the offset 512 to your GPIO number:

    GPIOpin=15 -> GPIOpin=527
    GPIOpin1=14 -> GPIOpin1=526

    Edit:
    Calculation is right. Locally tested with GPIO24 and checked with gpioinfo.

    MatteN ,

    if he has a NVMe to USB adapter and the luck, that his Luxar NVMe is supported by the RPi5 bootloader too you are more than right.

    But that the NVMe is detected by the kernel is unfortunately no guarantee that it boots from.

    appliedthinking,

    If have such adapter, that would be the easiest way. Depending on your experience with the Linux CLI and your goals there also other possibilities with dd and so on.

    Do you want remove the SD card and use the NVMe as boot device or only for /storage ?

    Because your kernel was already able to find the NVMe the line dtparam=nvme could be obsolete. The dtparam=pciex1_gen=3 is only to force PCIe bus to higher speed level. This speed is not official supported and can make additional trouble. My recommendation: activate these settings as the last step after all other things are ready and observe your dmesg log for sporadic PCIe error messages, to be safe and prevent data corruption.

    https://wiki.libreelec.tv/configuration/config_txt