Hi,

I have installed "Armbian_22.08.7_Tinkerboard_bullseye_current_5.15.74_minimal.img.xz" on a Tinkerboard (no S, with RK3288).

 

I have tried to set the output of some header pins without success. I used both "sysfs" and "gpiod" (which uses char-devices).

Test procedure, e.g. for pin 36 (gpio223):

# echo "223" > /sys/class/gpio/export
# cat /sys/class/gpio/gpio223/direction 
in
# cat /sys/class/gpio/gpio223/value 
0

# echo "out" > /sys/class/gpio/gpio223/direction
# cat /sys/class/gpio/gpio223/direction
out
# echo "1" > /sys/class/gpio/gpio223/value
# cat /sys/class/gpio/gpio223/value 
0
# echo "0" > /sys/class/gpio/gpio223/value
# cat /sys/class/gpio/gpio223/value 
0

 

The example is for the pin36 is grounded by an resistor with 1kOhm. If the resistor is switched to 3.3V all read values are go to "1".
The read values match the measured voltage (~0V for "0", ~3.3.V for "1").

 

The same behaviour for "gpioset 7 7=0". After this, the "gpioinfo 7" lists the line as output, like expected. Only the voltage remain unchanged (gpioget will change the line to input).

 

With TinkerOS the same test is working (with sysfs only, because old Kernel 4.4.).

 

Afterwards I have also tested some (or all) different options, like "sudo gpioset -m wait -D push-pull -B pull-down gpiochip7 7=0". But no success.

 

Have I something missed to set up in the device tree? I have enabled i2c1 & i2c4 and disabled all other features (uart, spi and w1-gpio etc.) by usage of armbian-config.

 

Thanks for your help in advance

 

gpioset --help

Quote

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.

 

@usual user thanks for the fast reply, but therefore I have also tested sysfs and the "wait" option.

 

Today I found my fault: It seems the used 1kOhm resistor together with the meter was not strong enough to override the internal resistors. The default internal resistor setup is possibly different between the Kernels. Using a LED show the correct behavior. Today I have also used another pin (header26, asus251, chip8-line3), so I will double check this.

I have done some investigation and it looks a little bit different, but it seems there is the same behaviour for character device and sysfs.

 

If all features are off (i2c1, uart etc.) the following header pins act fine as output:

• 3, 5, 7, 19, 21, 22, 23, 24, 26, 27, 28, 31

not working as output, current state in round brackets:

• 8 (1), 10 (1), 11 (0), 12 (1), 13 (1), 15 (1), 16 (0), 18 (0), 29 (0), 32 (1), 33 (1), 35 (0), 36 (1), 37 (1), 38 (1), 40 (0)

 

Thats the reason why my initial test with pin 36 is not working and pin 26 has worked.

 

 

Edited November 26, 20223 yr by gen2thomas
"current state" reversed (was LED on/off)

1 hour ago, gen2thomas said:

it seems there is the same behaviour for character device and sysfs.

Because the sysfs interface is only a wrapper for the character device interface to provide users with the legacy interface if they insist, this is to be expected.
Since you did not say how the base DTB wired the pins, and I am too lazy to pick it out myself because I do not own this device, this is a very expected result. For example, I see from the information here that pin 32, 33 are occupied by default with the serial console (UART functionality). Applying overlays can reconfigure the default functionality, but not all pins are configured with GPIO functionality by default. Good vendors offer appropriate documentation for their provided software, but since the configuration depends on the active DTB, it is at best to be interpreted as a guide. Any other provider may have changed the configuration according to their ideas.