Radxa Zero | SSH Crash "Broken Pipe" after exporting UART TX GPIO pin

[ghost]

Creating a bug report/issue

Required Information

• DietPi version | 8.15.2
• Distro version | bullseye
• Kernel version | 6.1.11-meson64 #23.02.2 SMP PREEMPT Sat Feb 18 00:07:55 UTC 2023 aarch64 GNU/Linux
• SBC model | Radxa Zero (aarch64)
• Power supply used | Standard
• SD card used | None. eMMC.

Steps to reproduce

echo 412 > /sys/class/gpio/export

Expected behaviour

Won't cause the SSH session to break

Actual behaviour

client_loop: send disconnect: Broken pipe

Extra details

No idea if I'm doing something dumb.
I think that UART TX spits data out which could cause the thing to break but then how do I check whether its HIGH or LOW?

[MichaIng]

Are you sure that this is a valid GPIO number (on mainline kernel)? You mean to do echo 412 > /sys/class/gpio/export, right?

Have you tried using libgpio?

apt install gpiod
gpiodetect
gpioinfo
gpioget 0 412

[ghost]

Are you sure that this is a valid GPIO number (on mainline kernel)? You mean to do echo 412 > /sys/class/gpio/export, right?

Yes, sorry. I edited my post.

Have you tried using libgpio?

apt install gpiod
gpiodetect
gpioinfo
gpioget 0 412

Yes although I used the GPIO line instead. It works and won't crash the SSH session.
But has to use a GPIO line...

Also, a regular GPIO pin won't turn LOW even with gpiod

https://wiki.radxa.com/Zero/hardware/gpio

# gpioget gpiochip1 2 # GPIOAO_2
1
# gpioset gpiochip1 2=0
# gpioget gpiochip1 2 # GPIOAO_2
1

The direction changed correctly, from input to output, but it won't turn LOW.

Am I doing something wrong?

[MichaIng]

https://manpages.debian.org/gpioset#l

Note: the state of a GPIO line controlled over the character device reverts to default when the last process referencing the file descriptor representing the device file exits. This means that it's wrong to run gpioset, have it exit and expect the line to continue being driven high or low. It may happen if given pin is floating but it must be interpreted as undefined behavior.

Lol hmm: https://raspberrypi.stackexchange.com/questions/136479/confusion-with-libgpiod-and-the-gpiod-user-tools

Seems to be by design, only fixed on RPi recently, lol. You can use the -m/--mode option to stay active (and hence keep the value until certain action/time) but otherwise it will always return to default. You can use the -b option to push gpioset into background to keep the value forever without disturbance, but then it needs to be killed manually as well.

What a strange limitation of this "new" method which shall replace the deprecated sysfs API, which is even disabled by default on mainline kernel, only actively re-enabled on Armbian and RPi kernel, well most distro kernel builds, likely for exactly this reason.

[ghost]

What a strange limitation of this "new" method which shall replace the deprecated sysfs API, which is even disabled by default on mainline kernel, only actively re-enabled on Armbian and RPi kernel, well most distro kernel builds, likely for exactly this reason.

I must say it's a weird behavior, maybe they thought it would be best to stick the pin to its default value when not toggled specifically.

I think this issue can be closed then?

Conclusion: use libgpiod to read UART TX GPIO pin state.

Edit:
Nevermind, all good.

[MichaIng]

Conclusion: use libgpiod to read UART TX GPIO pin state.

Generally the gpio sysfs API is deprecated and libgpio seems to be the future, so it generally makes sense to switch with own projects. However, as of the above limitation and since most distros re-enable the sysfs API in their kernel builds by explicitly adding a build config, it may not be suitable in all cases.

In any case, using the sysfs API should not crash the system, so this seems to be a kernel bug. Let me reopen to at least try to replicate on Odroid N2+ (same kernel build).

[ghost]

In any case, using the sysfs API should not crash the system, so this seems to be a kernel bug. Let me reopen to at least try to replicate on Odroid N2+ (same kernel build).

Sure! Makes sense to keep it open still.

[MichaIng]

On Odroid N2 I can export and access GPIO pins via sysfs just fine. However, on Odroid N2 the GPIO and PIN numbers are stirred and do not match docs. There are numbers which shouldn't exist at all and others exist which do not exist in docs: #5644
This seems to be correct on Radxa Zero?

[ghost]

On Odroid N2 I can export and access GPIO pins via sysfs just fine. However, on Odroid N2 the GPIO and PIN numbers are stirred and do not match docs. There are numbers which shouldn't exist at all and others exist which do not exist in docs: #5644 This seems to be correct on Radxa Zero?

About the Radxa Zero, there is no problem with the pin numbers.