Posts by HarryH

Do we talk about the same thing? I meant, that I have updated the scripts inside of the 2 codeblocks in Post #17

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.

By the way, I think gpiochip571 should be the correct one for RPi5 with the label "pinctrl-rp1".

GPIOpin=586
GPIOpin1=585

Quote from mokkurkalve

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.

#!/bin/bash
# Created on: 2024-04-15 20:00
# Changed on: 2024-04-17 13:30
# Version: 1.2.0
#
# Changelog:
# 1.2.0 2024-04-17
# - version information added
# - migrated from deprecated usleep to sleep command
# 1.1.0 2024-04-16
# - restricted the pinctrl usage to the 40-pin header
# - use a more specific pin naming to prevent usage of the wrong pin
# 1.0.1 2024-04-15
# - pull-up/down setting added
# 1.0.0 2024-04-15
# - migrated to pinctrl
# - code comments added

PINCTRL_BIN="/usr/bin/pinctrl -p"
# this is the GPIO pin receiving the shut-down signal
GPIOpin1=GPIO14
# set GPIO14 to input
$PINCTRL_BIN set $GPIOpin1 ip pd
while true; do
    sleep 1
    # check if GPIO14 is going to high
    power=$($PINCTRL_BIN get $GPIOpin1 | awk '{ print $5 }')
    if [ "$power" = "hi" ]; then
        # change GPIO14 to output and set it to high level
        $PINCTRL_BIN set $GPIOpin1 op dh pn
        sleep 3
        poweroff
    fi
done

#!/bin/bash
# Created on: 2024-04-15 20:00
# Changed on: 2024-04-17 13:30
# Version: 1.2.0
#
# Changelog:
# 1.2.0 2024-04-17
# - version information added
# - migrated from deprecated usleep to sleep command
# 1.1.0 2024-04-16
# - restricted the pinctrl usage to the 40-pin header
# - use a more specific pin naming to prevent usage of the wrong pin
# 1.0.1 2024-04-15
# - pull-up/down setting added
# 1.0.0 2024-04-15
# - migrated to pinctrl
# - code comments added

PINCTRL_BIN="/usr/bin/pinctrl -p"

if [ "$1" != "reboot" ]; then
    GPIOpin=GPIO15
    GPIOpin1=GPIO14
    # execute shutdown sequence on pin
    # set GPIO15 to output and high level for 125ms
    $PINCTRL_BIN set $GPIOpin op dh pn
    sleep 0.125
    # change the output to low level for 200ms
    $PINCTRL_BIN set $GPIOpin dl
    sleep 0.2
    # change the output to high level for 400ms
    $PINCTRL_BIN set $GPIOpin dh
    sleep 0.4
    # change the output to low level
    $PINCTRL_BIN set $GPIOpin dl
    # set GPIO 14 high to feedback shutdown to RemotePi Board
    # because the irswitch.sh has already been terminated
    $PINCTRL_BIN set $GPIOpin1 op dh pn
    sleep 4
fi

Quote from Benoitone

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

Shell session

LibreELEC:~ # ls -la /sys/class/gpio/
total 0
drwxr-xr-x    2 root     root             0 Feb 27 18:26 .
drwxr-xr-x   58 root     root             0 Jan  1  1970 ..
--w-------    1 root     root         16384 Apr 15 20:42 export
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip512 -> ../../devices/platform/soc/107d508500.gpio/gpio/gpiochip512
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip544 -> ../../devices/platform/soc/107d508500.gpio/gpio/gpiochip544
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip548 -> ../../devices/platform/soc/107d517c00.gpio/gpio/gpiochip548
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip565 -> ../../devices/platform/soc/107d517c00.gpio/gpio/gpiochip565
lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip571 -> ../../devices/platform/axi/1000120000.pcie/1f000d0000.gpio/gpio/gpiochip571
--w-------    1 root     root         16384 Apr 15 20:42 unexport

Display More

To make it complete, please check every listed chip:

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.

No, I don't know anything about such an adaptation. So far it was just a thought experiment on my part as to how things could continue to keep the project alive, since I don't have such a board.

What do you get if you look for mapped gpiochips on your RPi5 ?
ls -la /sys/class/gpio/

With your LibreELEC 12 beta 2 installation can you please try if this makes a different?

Place these 2 line as the first 2 lines in your config.txt file:

dtoverlay=
dtoverlay=hifiberry-dacplus-pro

and remove/comment out those lines:

dtoverlay=hifiberry-dacplus
core_freq_min=500

Your are welcome.

Please keep in mind that this option to set the GPIO pins in this simple way may be removed in a future kernel release. If this happens, the scripts will need to be switched to using pinctrl or migrated to Python3 scripts.

Yes, you must only change the value to the new digits.

• Bash: shutdown.sh

  #!/bin/bash
  if [ "$1" != "reboot" ]; then
    GPIOpin=527
    GPIOpin1=526

• Bash: irswitch.sh

  #!/bin/bash
  # this is the GPIO pin receiving the shut-down signal
  GPIOpin1=526

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

# 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

Perhaps the changes regarding Bluetooth in kernel 6.6.21?

Are you able to boot your Mint with an older kernel like 6.5.0-21?

I can confirm, that strange behavior. After some attempts without success, I had let the port assignment in the default position 0. The things like remote control of KODI, TV off/on seems to work most of the time. I hoped that it was fixed with LE12, but I can say „currently no“.
But it seems now a unexpected „feature“ of self sorting and self hiding of entries in the settings menu implemented. So I thought it's currently under construction...

Only to be sure: You doesn‘t use a case like Argon40 One or some like that, which has a separate power on/off switch?

Do you have made some changes at the EEPROM settings? Something like this combination:
POWER_OFF_ON_HALT=1
WAKE_ON_GPIO=0

That prevents the RPi4 from boot, until you shorten GLOBAL_EN to ground - if I understand the documentation right.

Version 0.0.13 released

• added option for displaying temperature in Fahrenheit
• added SSD/NVMe temperature observing option for fan control

Be aware: switching the display units between Celsius and Fahrenheit behaves like 2 different temperature profiles. There is no transfer of the values (no migration) from one profile to the other.

Regarding the SSD/NVMe fan control: The settings are only shown, if the GUI is set to Advanced or Expert ! The temperature profile with the highest required PWM value wins.
For example if you set value for SSD/NVMe too low, than the fan will starts regardless if the CPU temperature is over the 1st threshold or not.

Version 0.0.12a released

• bugfix: works again with LibreELEC 11

The other day I was concentrating on getting it to work with LE12 and accidentally put a line of code in 0.0.12 that prevented it from working with LE11. However, I'm surprised that no one here has complained about it. Have you all switched to LE12 yet?

I asked this because I had stumbled upon this information::

https://www.raspberrypi.com/documentation/computers/configuration.html#mini-uart-and-cpu-core-frequency

But it seems, that the described behavior regarding the reduced/fixed core clock is not true in all cases and because of some open bugs in the firmware is not predictable.

enable_uart=1 NOT fixing core_freq to 250MHz · Issue #4123 · raspberrypi/linux

Is this the right place for my bug report? I hope so, apologies if that's not the case. I've also posted on the RPi forum (See…

github.com

I understood that VC-1 is not hardware decoded with a RPi4. But at a desktop computer ffmpeg tries to use some common acceleration functions to decode newer formats, which not directly supported by the GPU. It could be wrong, but my idea was, you should check if the VPU of the RPi4 has switched to 500 or 550MHz, to ensure that you get the maximum performance and not work against an additional limit.

vcgencmd measure_clock core