WiringPi can't work for H5 CPU (OrangePi PC 2)

[lsmod]

Hello together,

 

i opened a ticket here https://github.com/armbian/build/issues/1085

 

Why "cat /proc/cpuinfo" does not tell anything about the CPU type?

 

Edited August 18, 2018 by lsmod

[Igor]

Because this was 1st experimental release kernel for H5/A64 and it is still under development. We don't deal with smelly stock kernels on H5 boards.

 

This patch: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/general-add-proc-cpuinfo-entries.patch should solve this problem, but 4.17.y kernel hasn't arrived yet to the stable branch.

 

You can try it by switching no nightly beta or build on your own  ... to test if it works.

[lsmod]

Thank you for the info Igor.

I already expected such an answer.

 

Is there an easy way to recompile the kernel with this patch ?

I never have done such things for an ARM kernel ...

Or how can i use the kernel of the nightly build in the stable distribution ?

 

It would be nice if such things like WiringPi would be part of armbian.

Why are I2C tools included, but no tools regarding the IO-ports ?

 

[lsmod]

Besides - here are the CPU types that are checked in OrangePi.c of WiringPi:

 

I see a difference to your patch with sun50iw1p1 ?

 

/*
 * Probe OrangePi Platform.
 */
int isOrangePi(void)
{
	FILE *cpuFd;
	char line [120];
	char *d;
#ifdef CONFIG_ORANGEPI_2G_IOT
	/* Support: OrangePi 2G-IOT and OrangePi i96 */
	char *OrangePi_string = "rda8810";
#elif CONFIG_ORANGEPI_PC2
	/* Support: OrangePi PC2 */
	char *OrangePi_string = "sun50iw2";
#elif CONFIG_ORANGEPI_A64
	/* Support: OrangePi Win/Win plus */
	char *OrangePi_string = "sun50iw1";
#elif CONFIG_ORANGEPI_H3
	/* Support: OrangePi Win/Win plus */
	char *OrangePi_string = "sun8iw7";
#elif CONFIG_ORANGEPI_ZERO
	/* Support: OrangePi zero */
	char *OrangePi_string = "sun8iw7";
#else
	/* Non-support */
	char *OrangePi_string = "none";
#endif

	if ((cpuFd = fopen("/proc/cpuinfo", "r")) == NULL)
		piBoardRevOops ("Unable to open /proc/cpuinfo") ;
    
	while (fgets(line, 120, cpuFd) != NULL) {
		if (strncmp(line, "Hardware", 8) == 0)
			break;
	}

	fclose(cpuFd);
	if (strncmp(line, "Hardware", 8) != 0)
		piBoardRevOops("No \"Hardware\" line");

 

 

[Igor]

1 hour ago, lsmod said:

Is there an easy way to recompile the kernel with this patch ?

It was not possible to make it more simple than this way:

git clone https://github.com/armbian/build
cd build
./compile BOARD="orangepipc2" BRANCH="next" KERNEL_ONLY="yes"

 

Remember that this kernel is still in the works and this simplicity above might be a bit shattered.

[Igor]

56 minutes ago, lsmod said:

Besides - here are the CPU types that are checked in OrangePi.c of WiringPi:

 

Well, then you will need to adjust this patch (at least remove p1 from the name) and checked for its role elsewhere H3/A64 ... we are mostly using the modern kernel, which is different from those used on Orangepi stock images. Their kernels are made from proprietary Allwinner mixture. 3.10.y or 4.9.y.  which we don't use.

[martinayotte]

5 hours ago, lsmod said:

here are the CPU types that are checked in OrangePi.c of WiringPi:

If you don't want to tweak kernel, you can tweak this WiringPi isOrangePi() function to always return true ...

[chwe]

6 hours ago, lsmod said:

It would be nice if such things like WiringPi would be part of armbian.

Why are I2C tools included, but no tools regarding the IO-ports ?

cause everyone has it's own preferences when it comes to GPIO libs from 'wiring pi' to userspaceIO.. there are multiple possibilities and not all of them are compatible for each or the majority of boards we provide images, whereas i2c-tools is everywhere the same.. 

 

 

[lsmod]

 

8 hours ago, Igor said:

It was not possible to make it more simple than this way:

git clone https://github.com/armbian/build
cd build
./compile BOARD="orangepipc2" BRANCH="next" KERNEL_ONLY="yes"

 

Remember that this kernel is still in the works and this simplicity above might be a bit shattered.

 

O.K. This is a really simple approach.

But i know it will take many dependencies and time to get it working.

I suppose BRANCH="next" is the "testing" and not "stable"?

 

Is there no lazy way for me to take a kernel package from http://beta.armbian.com/ for a quick test ?

I searched but could not find an appropriate package ...

 

7 hours ago, Igor said:

 

Well, then you will need to adjust this patch (at least remove p1 from the name) and checked for its role elsewhere H3/A64 ... we are mostly using the modern kernel, which is different from those used on Orangepi stock images. Their kernels are made from proprietary Allwinner mixture. 3.10.y or 4.9.y.  which we don't use.

 

It seems that the "p1" makes a certain sense.

So i think it is better and easier to patch the WiringPi instead of the kernel.

 

 

[lsmod]

3 hours ago, martinayotte said:

If you don't want to tweak kernel, you can tweak this WiringPi isOrangePi() function to always return true ...

 

Yes - i did have the same idea, but without no effect.

I am only a C novice and there seems to be more checks or i just failed ...

[lsmod]

3 hours ago, chwe said:

cause everyone has it's own preferences when it comes to GPIO libs from 'wiring pi' to userspaceIO.. there are multiple possibilities and not all of them are compatible for each or the majority of boards we provide images, whereas i2c-tools is everywhere the same.. 

 

 

 

I did not do many things so far with WiringPi, and i did it on an original Pi B+ in the past.

But now i want to do again some working with the OrangePi and so i want to use the ports too.

 

What are alternatives for a simply access of the ports of an H3 and H5 in shell and perl?

When there is a working alternative everything is fine and i don't have to do nasty things with the kernel ...

 

I want to use I2C for a DS3231 hardware clock.

[chwe]

7 minutes ago, lsmod said:

 

What are alternatives for a simply access of the ports of an H3 and H5 in shell and perl?

has it to be fast? or just something like let a led blink in a bash-script?

 

easiest way is probably sysfs. 

http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel

 

or ArmbianIO from @Larry Bank (don't know actually if there's a boardconfig for your board). UserspaceIO from @sgjava or you write a template for your board and give pyGPIO a try (well python, not really shell).. 

[lsmod]

8 minutes ago, chwe said:

has it to be fast? or just something like let a led blink in a bash-script?

 

easiest way is probably sysfs. 

http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel

 

or ArmbianIO from @Larry Bank (don't know actually if there's a boardconfig for your board). UserspaceIO from @sgjava or you write a template for your board and give pyGPIO a try (well python, not really shell).. 

 

No - normally it has not to be fast. Just switching some things on and off or read slow signals.

But PWM output could be interesting.

 

When Bit hacking through sysfs is a universal working solution - this will be sufficient - thanks.

I just want to be sure that it is possible when i use Armbian for the H5 board PC 2.

 

Python is not my language, but i will have a look at Armbian IO ...

 

[chwe]

6 minutes ago, lsmod said:

When Bit hacking through sysfs is a universal working solution - this will be sufficient - thanks.

I just want to be sure that it is possible when i use Armbian for the H5 board PC 2.

 

https://github.com/armbian/build/blob/203fb7335e3ef6446c2722639dfdd6bb5aaf2fc0/config/kernel/linux-sunxi64-next.config#L2515-L2519

 

should be everything there I guess..  

 

10 minutes ago, lsmod said:

 

Python is not my language, but i will have a look at Armbian IO ...

when C is more your language, just add a mapping here:  https://github.com/chwe17/pyGPIO/

The backbone of pyA20/pyGPIO is C...  since this doesn't use sysFS, it's a way faster... but speed seems not to be an issue for you. 

[sgjava]

@lsmod I ended up writing my PWM code against sysfs to keep it portable. https://github.com/sgjava/userspaceio/tree/master/pwmio/c/src

 

So if you do not want to use the rest of User Space IO at least you have simple C code to deal with PWM.

[lsmod]

27 minutes ago, chwe said:

 

https://github.com/armbian/build/blob/203fb7335e3ef6446c2722639dfdd6bb5aaf2fc0/config/kernel/linux-sunxi64-next.config#L2515-L2519

 

should be everything there I guess..  

 

when C is more your language, just add a mapping here:  https://github.com/chwe17/pyGPIO/

The backbone of pyA20/pyGPIO is C...  since this doesn't use sysFS, it's a way faster... but speed seems not to be an issue for you. 

 

My first choice for small projects is to program in perl.

It's near C, but i don't need to compile and it is fast and stable.

 

The python library could be something to use with PerlXS

 

27 minutes ago, chwe said:

 

https://github.com/armbian/build/blob/203fb7335e3ef6446c2722639dfdd6bb5aaf2fc0/config/kernel/linux-sunxi64-next.config#L2515-L2519

 

should be everything there I guess..  

 

when C is more your language, just add a mapping here:  https://github.com/chwe17/pyGPIO/

The backbone of pyA20/pyGPIO is C...  since this doesn't use sysFS, it's a way faster... but speed seems not to be an issue for you. 

 

Hmm - at this time i don't understand the sense of this definitions ...

 

Now i find the links for Armbian IO - this could be interesting for others:

• https://github.com/bitbank2/ArmbianIO

[lsmod]

7 minutes ago, sgjava said:

@lsmod I ended up writing my PWM code against sysfs to keep it portable. https://github.com/sgjava/userspaceio/tree/master/pwmio/c/src

 

So if you do not want to use the rest of User Space IO at least you have simple C code to deal with PWM.

 

O.K. Thank you !

 

This is really much information for me with a lot solutions for my problem - Thank you all!

 

So first i try out the simple sysfs, because it seems that i don't need a new kernel.

Then i will have a look on ArmbianIO, because this looks like an comfortable way to access ports - if it works for the H5.

The direct C-Code for the PWM can be helpful.

It is also possible to mix C and Perl if needed.

 

I will report when i have tested it and when it is successfull.

But this can take some time ...

[sgjava]

@lsmod you need the latest mainline kernel to use User Space IO and PWM as non-root user. That's probably another difference is that User Space IO doesn't require root user for GPIO, SPI, I2C, PWM and MMIO. Not all libraries support this.

[lsmod]

Today i find the time to test the sysfs stuff to access the GPIO.

Result: It works partially!

 

I simply connected some Arduino relays on 4 GPIO pins and additionally measured the voltage on it.

echo 71 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio71/direction

   is working and the relay is switching, and

echo 0 > /sys/class/gpio/gpio71/value
echo 1 > /sys/class/gpio/gpio71/value

can switch the relay.

So the output can be set!

 

An problem is to try to access Port-Pin PA20 on Pin 36 or PA10 on 35 with

echo 20 > /sys/class/gpio/export
echo 10 > /sys/class/gpio/export

that results in an writing-Error like "Schreibfehler: Das Gerät oder die Ressource ist belegt."

 

@Igor Any ideas?

[martinayotte]

1 hour ago, lsmod said:

An problem is to try to access Port-Pin PA20 on Pin 37 or PA10 on 36 with

On OPiPC2, the PA10 is on pin 35 not 36, and the pins 37 is PD11 ...

 

[lsmod]

2 hours ago, martinayotte said:

On OPiPC2, the PA10 is on pin 35 not 36, and the pins 37 is PD11 ...

 

 

Yes - i corrected this - and it was connected this way.

The problem is that this Pins cannot be adressed via sysfs, independent of the wiring.

[martinayotte]

12 minutes ago, lsmod said:

The problem is that this Pins cannot be adressed via sysfs

I've no such issue on my OPiPC2, both PA10 and PD11 are working fine.

Check if other apps reserved them using "cat /sys/kernel/debug/gpio" ...

 

[lsmod]

18 hours ago, martinayotte said:

I've no such issue on my OPiPC2, both PA10 and PD11 are working fine.

Check if other apps reserved them using "cat /sys/kernel/debug/gpio" ...

 

 

Thanks for the Tip!

 

What is the meaning of a "red status" ?

gpiochip1: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-20  (                    |orangepi:red:status ) out lo    
 gpio-102 (                    |gmac-3v3            ) out hi    
 gpio-110 (                    |w1                  ) in  lo    
 gpio-166 (                    |cd                  ) in  lo IRQ
 gpio-204 (                    |usb0_id_det         ) in  hi IRQ

gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl:
 gpio-354 (                    |usb0-vbus           ) out lo    
 gpio-355 (                    |sw4                 ) in  hi IRQ
 gpio-362 (                    |orangepi:green:pwr  ) out hi    

But this time the "echo 10" for PA10 is working.

Hmm - seems to be random.

[martinayotte]

3 hours ago, lsmod said:

What is the meaning of a "red status" ?

This is a led defined in device-tree, as well as orangepi:green:pwr, configurable thru /sys/class/leds

3 hours ago, lsmod said:

But this time the "echo 10" for PA10 is working.

Hmm - seems to be random

I don't believe about such randomness ...

[lsmod]

20 hours ago, martinayotte said:

This is a led defined in device-tree, as well as orangepi:green:pwr, configurable thru /sys/class/leds 

I don't believe about such randomness ...

 

O.K. Here i can find this information, but that does not say anything about the GPIO ports:

 

lrwxrwxrwx  1 root root 0 Jan  1  1970 orangepi:green:pwr -> ../../devices/platform/leds/leds/orangepi:green:pwr
lrwxrwxrwx  1 root root 0 Jan  1  1970 orangepi:red:status -> ../../devices/platform/leds/leds/orangepi:red:status

 

I would say PA10 and PA20 are definitely not used for the LED's.

 

It should be PA15 for the Status-LED and PL10 for the Power-LED when the circuit diagram is correct.

 

 

[lsmod]

The question remains why PA20 cannot be used?

# echo 20 > /sys/class/gpio/export
-bash: echo: Schreibfehler: Das Gerät oder die Ressource ist belegt.


# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-10  (                    |sysfs               ) out hi    
 gpio-20  (                    |orangepi:red:status ) out lo    

I should take the time to test the other ways to access the GPIO ...

[martinayotte]

2 hours ago, lsmod said:

It should be PA15 for the Status-LED

If you look carefully at the schematic, the table has a copy/paste typo/error, it is not PA15 if you look the at wiring itself, PA15 is SPI1-MOSI, and the STATUS-LED is really at PA20.

[lsmod]

14 minutes ago, martinayotte said:

If you look carefully at the schematic, the table has a copy/paste typo/error, it is not PA15 if you look the at wiring itself, PA15 is SPI1-MOSI, and the STATUS-LED is really at PA20.

 

Hihi indeed - it is a failure to believe an chinese schematic diagram.

Why they should publish a correct one that have been used for manufacturing ...

 

 

 

[lsmod]

@587-martinayotte I want to test the access of an PCF8574 now.

I can already "see" it on the I2C bus.

Is there any advisable solution in Armbian already existing?

(Before i try a way that must fail )

 

And i will have to look for ArmbianIO now, because i want to read an DHT11 on an Port Pin,

and usually this will be done with a WiringPi Library ...

[vlad59]

Once you see it with `i2cdetect` you can use any program on github : https://github.com/ControlEverythingCommunity/PCF8574 (being the first one) no need for WiringPi for i2c access