Pine64: Unable to export GPIO 64 - 67

[linda]

Armbianmonitor:

http://ix.io/1LFj

How can I use / release the ports PC0-PC3 (GPIO 64 - 67) in kernel 4.19?

 

In my project I am using the ports PC0-PC3 (GPIO 64 - 67) for in-circuit programming (with avrdude). Everything was fine until I switched from kernel 4.14 to kernel 4.19.

 

Now the ports are already in use. (Although according to the pine64 schematics nothing is connected to those ports)

 

sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins
...
pin 64 (PC0): device 1c68000.spi function spi0 group PC0
pin 65 (PC1): device 1c68000.spi function spi0 group PC1
pin 66 (PC2): device 1c68000.spi function spi0 group PC2
pin 67 (PC3): device 1c68000.spi function spi0 group PC3
...

In kernel 4.14 the ports were unclaimed:

sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

...

pin 64 (PC0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 65 (PC1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 66 (PC2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 67 (PC3): (MUX UNCLAIMED) (GPIO UNCLAIMED)

...

 

How can I free the ports so I can use kernel 4.19 in my project?

 

Here is the related information from armbianmonitor -u:

[ 5222.922107] sun50i-a64-pinctrl 1c20800.pinctrl: pin PC3 already requested by 1c68000.spi; cannot claim for 1c20800.pinctrl:67 [ 5222.922122] sun50i-a64-pinctrl 1c20800.pinctrl: pin-67 (1c20800.pinctrl:67) status -22

 

Thanks for any information in advance.

[martinayotte]

7 hours ago, linda said:

sun50i-a64-pinctrl 1c20800.pinctrl: pin PC3 already requested by 1c68000.spi;

Install DT compiler from here : http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_arm64.deb

Decompile DTB into DTS :

dtc -I dtb -O dts -o sun50i-a64-pine64-plus.dts /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb

Edit the file sun50i-a64-pine64-plus.dts by changing "status" from "okay" to "disabled" of the "spi@1c68000" node and save.

Recompile the DTB from this modified DTS :

dtc -I dts -O dtb -o  /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus.dts

Then, reboot ... The GPIOs will be available ...

[linda]

I have changed the DT file after the instructions and now I can use the ports again for my in-circuit programming!

Many Thanks!

[avdh]

I have a similar problem with the Orange Pi One Plus.

 

I can use gpio to get a display of the pins. I can test most all pins according to the instructions using

    gpio blink ##

except i.a. PC0/SCLK.0/64 , pin 23 on the header. In the hardware schematic it is called SPI0_CLK and this can be found in the H6 V200 user manual page 385 where it has the alias PC0. This in turn agrees with the number 64 assigned by gpio. All pins that blink in gpio, also work in a small test program.

 

So I tried to use dtc on the file I thought applicable : sun50i-h6-orangepi-one-plus.dtb.

However there is no similar device 68000 and no clue what to disable.

 

What concerns me the most is the following: I have disabled all devices of the armbian hardware list via armbian-config. I thought that that means that I can experiment freely with all the 26 pins on the header, but apparently that is not true.

Any clues appreciated.

 

Groetjes Albert

 

 

[martinayotte]

2 hours ago, avdh said:

I thought that that means that I can experiment freely with all the 26 pins on the header

No, some like those SPI pins are assigned for SPI purposes.

2 hours ago, avdh said:

So I tried to use dtc on the file I thought applicable : sun50i-h6-orangepi-one-plus.dtb.

Yes, you could decompile the DTB into DTS and remove the SPI node and its pins, and then recompile a new DTB.

[avdh]

18 hours ago, martinayotte said:

No, some like those SPI pins are assigned for SPI purposes.

Yes, you could decompile the DTB into DTS and remove the SPI node and its pins, and then recompile a new DTB.

Apparently. I found an spi0 entry that uses exactly PC0/PC2/PC4 , the I/O's which don't work.

RCS file: RCS/sun50i-h6-orangepi-one-plus.dts,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
473,477d472
<             spi0-pins {
<                 pins = "PC2\0PC3\0PC0\0PC5";
<                 function = "spi0";
<                 phandle = < 0x17 >;
<             };

The above is the change I made to the dts, then I recompiled and did a reboot (power cycle to be exact.)

 

However this makes no difference, not to gpio, nor my test program. I have enough digital IO's to work with but I hate it that I don't know what is going on.

 

By the way, amazing speed and accuracy of response.

 

Groetjes Albert

[martinayotte]

2 hours ago, avdh said:

However this makes no difference, not to gpio, nor my test program.

Maybe it is the program you were using that doesn't handle PC0 properly, because I've tested it using sysfs, and I was able to drive PC0 properly with a LED connected and it is also working without commenting SPI0 :

echo 64 > /sys/class/gpio/export 
echo out > /sys/class/gpio/gpio64/direction 
echo 1 > /sys/class/gpio/gpio64/value 

 

[avdh]

  On 11/30/2019 at 4:18 PM, avdh said:

 

On 11/30/2019 at 6:27 PM, martinayotte said:

Maybe it is the program you were using that doesn't handle PC0 properly, because I've tested it using sysfs, and I was able to drive PC0 properly with a LED connected and it is also working without commenting SPI0 :

echo 64 > /sys/class/gpio/export 
echo out > /sys/class/gpio/gpio64/direction 
echo 1 > /sys/class/gpio/gpio64/value 

 

That  makes three different programs that fail to light led 64.

 

The mystery has been solved now.  It is a hardware problem.

I borrowed an identical Orange Pi One Plus, and the LED behaves as expected with all

programs. Indeed there was no need to disable SPIO.  Frankly I expected so. My program worked on a very low level,

and allowed to inspect the status of the io ports.

gpio $48 + L@ H.
0000,0000,7077,7771 OK
gpio $58 + L@ H.
0000,0000,0000,0040 OK
$40 gpio-on
 OK
gpio $58 + L@ H.
0000,0000,0000,0041 OK

You see that the first nibble of gpio[0x48] is 1 meaning output.

After setting port 64 (0x40) on the zeroth bit of gpio[0x58] is 1, and the led is on.

 

Again, thanks for the help.

Groetjes Albert