rfc [RfC] Make Armbian more IoT friendly?

[tkaiser]

Just a thought. Over half of the boards we support feature a 26 or 40 RPi compatible GPIO header and all the other boards expose various protocols and GPIO on various pins and headers.

 

Users coming from Raspbian and trying out any of our boards expect that basics work the same. While it's both impossible and not desirable to be 100% compatible with Raspbian a few things would make transition from Raspbian to Armbian for IoT folks more easy.

 

Simple example: Default user pi in Raspbian has access to GPIO pins -- on Armbian it's currently root only. How's that done? A group called gpio exists in Raspbian, pi is added to it and /etc/udev/rules.d/99-com.rules does all the magic:

 

 

 

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
	chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
	chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
	chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
	ALIASES=/proc/device-tree/aliases; \
	if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
		echo 0;\
	elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
		echo 1; \
	else \
		exit 1; \
	fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
	ALIASES=/proc/device-tree/aliases; \
	if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
		echo 0; \
	elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
		echo 1; \
	else \
		exit 1; \
	fi \
'", SYMLINK+="serial%c" 

 

 

 

So adding a detection in automatic user creation (we don't want to ship with pre-defined users ) to check for pi as name we could add this in Armbian too.

 

Another area are the various WiringPi library variants that exist for different SoCs that partially need adjusted settings since pin mappings differ (see example for BPi M2+). AFAIK the knowledge which lib has to be used on which SoC is present here but scattered all over the place. Wouldn't it be cool if people experienced with this stuff start to collect information (as a first step as part of our documentation, later maybe providing own variants of these libs for our most popular SoC variants)?

 

Disclaimer: me is the wrong person for this stuff since I'm still an absolute IoT NOOB and always have a hard time trying out GPIO stuff

 

So this thread is meant to collect ideas and opinions on this.

[Peter Scargill]

So this thread is meant to collect ideas and opinions on this.

 

I agree - the Pi for me is the "main" unit of this type - as everyone else has copied the name Pi - and they have masses of support - so to me all other systems should attempt where possible, compatibility in addition to their own unique offerings.  So in my script I make a user Pi and add that user to a load of groups.  As you'll see here...   http://tech.scargill.net/the-friendlyarm-nanopi-neo/ the Friendlyarm people have Ubuntu which is of no interest to me -  as a Pi user I wanted Debian - as near to Raspian as possible - well, Armbian is a great start from what I can see - I have it installed - and thanks to readers I now have normal (pi) user control over GPIO - suitable for Node-Red (though no-where near as good as having the GPIO nodes in Node-Red running natively).  I've a couple of pins I've no idea why I can't access them but I have the bulk of them.  Being able to use them for PWM and I2c as one can do EASILY on the Pi without root access, would make these boards a lot better - after all, with a Pi3 for £29 - for me just about the only reason to use alternatives is cost. The FriendlyArm M1 and NEO seem great little boards and cheap - and now I have Node-Red etc running on both (as you'll see in the blog) - but more control over the GPIO would be marvelous without having to guess which pin maps to what.

 

Here for example  -http://abyz.co.uk/rpi/pigpio/ a great library for the Raspberry Pi - with gpio, PWM, I2c etc. Surely this is the kind of thing that should be readily available in the other boards too.

 

Oh, my blog - and the NEO...   http://tech.scargill.net/the-friendlyarm-nanopi-neo/

[tkaiser]

I agree - the Pi for me is the "main" unit of this type - as everyone else has copied the name Pi - and they have masses of support - so to me all other systems should attempt where possible, compatibility in addition to their own unique offerings.

 

 

Sure, but we are no hardware vendors. Armbian is still a community project initially driven from different use cases. All we could do now is to ease transition (for example allowing user pi access to GPIO pins, but since we do not provide hardware and some board vendors do not comply to standards -- see example with BPi M2+ and 1-Wire above -- we never are able to provide a similiar situation as with the various RPis and Raspbian)

 

All we can try to do is a move in the right direction, learn what IoT people expect, discuss whether this is possible with Armbian internally and then slightly improve the situation. But only if Armbian users/devs want to go this direction and volunteers familiar with this stuff join the party. So for the moment this thread should serve as collection of ideas/objections only.

 

Since you mentioned FriendlyARM boards... from our perspective all H3 boards are more or less the same (at least it's pretty easy to support a new one -- coming up with optimal settings for different devices based on their differences is another story). So if you already want to try out Armbian then there's not much difference whether you choose an Orange Pi PC (slightly higher idle consumption but slightly better consumption under load due to better voltage generator) or a NanoPi M1 (better idle consumption, higher temperatures but otherwise identical feature set compared to Orange Pi -- stop! I forgot: blue led instead of red ).

 

If you don't want to use Armbian (though this is something somewhat weird from our perspective ) then it makes a huge difference since vendor provided software/support for Oranges are hard to get while FriendlyARM does an awesome job here (also if you want to try out their various Matrix modules then choosing their official OS image will be the better choice since I would fear nothing of the stuff will work out of the box with Armbian now, at least no one had looked into). But if Armbian is the OS image of choice it really doesn't matter that much which of the various H3 devices will be used -- the differences are minimal if it's not about special use cases like 'NAS' where GBit Ethernet or 2GB DRAM instead of 256MB are important.

[Igor]

We can simply ask on user creation: "Do you want to have access to GPIO?" ... with some brief description what that means.

[tkaiser]

We can simply ask on user creation: "Do you want to have access to GPIO?" ... with some brief description what that means.

 

Sure, but if we go this direction we have to keep in mind that based on combination of kernel and board the sysfs paths differ the udev rule has to adjut permissions for, that we then also have to ensure that BS fex contents like the one famous 'Team BPi' provided for their M2+ board have to be corrected by someone able to test through (same for NEO), that the module to be loaded and added to /etc/modules might be named differently depending on kernel and so on.

 

Adding a group and users to it is simple. Limiting this whole thing to one platform (H3/legacy) also. But if we don't provide consistent support for at least all boards that feature a RPi compatible header the efforts are somewhat useless since the time saved for supporting a specific board will be spent answering the same question again and again in forum

[arox]

I am far more worried by drivers than by user libraries. I made some projects with RPI, as it was the first platform to provide a GPIO, an UNIX-like software and low price. I then buy other arm boards for more power in desktop/server applications.

 

Now, I dont see much interest in RPI platforms : not well suited for desktop or IOT due to lack of coherence in hardware (no sata, no usb3, no eMMC, no BT, no heatsink, no power efficiency) or software (HW video acceleration, 64 bits OS, outdated firefox (iceweasel) browser ...). Things are evolving constantly, but when I want to start a project, I will not buy a card that "may have" what I need or "may be" sold some times in the future as a RPI zero.

 

So, I dont want to use RPI anymore. For other arm cards and armbian, what I need to know is : can I use GPIO interrupts, i2c or pwm or spi ... to use a RTC clock, a ds18b20, a motor driver, a LCD or inkpaper (dont know where to buy it) screen, an spi ADC, or make a button without polling ... And that with witch card and witch kernel version. User space programs are not a problem provided that the libraries are not outdated, but when there is no driver ... For example, there are posts about gpio_lirc driver. Nobody seems to know if it is usable or needs to be adapted

 

BTW, for desktop or server usage I am happy with armbian (preferably ubuntu based), but for specific use or IOT, I simply use the kernel and modules because I am not happy with Debian (I dont need a freedesktop.org based system for such sort of things).

[tkaiser]

I dont see much interest in RPI platforms : not well suited for desktop or IOT due to lack of coherence in hardware (no sata, no usb3, no eMMC, no BT, no heatsink, no power efficiency)

 

Well, at least the RPi Zero when using in featureless mode is energy efficient (as long as you don't connect an USB-Ethernet-dongle of course )

 

While I agree on most of RPi's limitations I can understand that people prefer the platform -- simply due to Raspbian and that tutorials they find on the net can be followed easily (the support factor -- RPi's community is huge). If you tried out an Orange Pi at the end of last year you had to deal either with OS images that did not work or when using loboris' overheating/instabilities. The bad reputation many/most of the Pi clones have is IMO due to bad software/support. And while this is something we might not need to care about at all (we don't sell any of these devices) it would be nice to enhance support also in this area if we get more volunteers on board that are familiar with this stuff.

 

Currently I think it's a bit of a chicken and egg problem. But if you look at Martin Ayotte's DT overlay work for mainline kernel and all the other bits if information scattered all over the forum I'm pretty confident that situation could improve even if I have still no clue about most of this stuff being a server guy having completely different use cases in mind.

 

BTW: It got totally unnoticed but @lex managed to build ffmpeg with HW accelerated video encoding on H3 boards recently (this is the last use case where we currently need RPi). IMO we're moving in the right direction as community

[zador.blood.stained]

Started to write a long wall of text several times, but wasn't happy with the result, so to keep this short:

 

Making Armbian for selected number of boards and kernel configurations more IoT friendly is possible, but requires some effort to maintain (for mainline kernel).

Compared to RPI we don't have uniform interface for activating and configuring different hardware interfaces, so everything should be done (for legacy kernel) and maintained (for mainline) for each SoC and board/group of similar boards individually.

 

GPIO group and udev rules should be done as an option in armbianmonitor (since we don't have any GUI/dialog based system configurator) should be provided by default in board support package, users will be able to use this by adding themselves to "gpio" group.

[arox]

...

 

I can understand that people prefer the platform -- simply due to Raspbian and that tutorials they find on the net can be followed easily (the support factor -- RPi's community is huge). If you tried out an Orange Pi at the end of last year you had to deal either with OS images that did not work or when using loboris' overheating/instabilities. ...

 

IMO we're moving in the right direction as community

In a sense, RPI becomes well suited for its initiam goal : education... When you want to do something more serious with an arm card, there is now better choices. And it could be also true for IOT with new devices as C.H.I.P.(I dont understand why the first nanopi was discontinued - lack of sells ?). So there may be a need for a system and support for arm IOT platforms. But I understand that armbian goal is mainly to provide a well tuned OS to cards badly supported by manufacturers.

 

As you say things are moving in the right direction : 6 month ago, I never had thought of using the GPIO of anything else than an RPI. That is the fact that those cards now got support and a visible community, and that the choice in hardware features becomes very large (and the price very low) that makes the RPI less interessant (RPI A+ is too expensive, RPI zero impossible to procure and badly designed with its micro connectors)

[nico]

I believe this initiative is very good! First, because it facilitates the functionality we need now in this starting stage of RPi alternative boards, and second because I think it encourages manufacturers to make products more standards.

[maruel]

tkaiser, udev rules files can be easily added by a user as root. So it's not a big deal if it is not done in the image, it can be fixed afterward.

 

On the other hand, /dev/gpiomem has real benefit to run gpio apps fast (read the pin directly from the CPU register), without using gpio sysfs, without requiring root. This is a pure "Raspbianism" but I think it's a good feature to be looked into.

 

This requires writing a kernel driver something like https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/bcm2835-gpiomem.cbut for other processors. That's harder to do for a end user than adding udev rules.

 

Allwinner A64: As per http://files.pine64.org/doc/datasheet/pine64/Allwinner_A64_User_Manual_V1.0.pdf page 73~75 and page 81, base address 0x01C20000 for a few Kb could be mapped the same way. http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdfpage 90 implies that Allwinner H3 uses a similar memory mapping so it could probably be shared at least for these two processors.

 

Amlogic S905: I did a quick peek at datasheet at http://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdfpage 45 and 80, tells 0xc8834000 being the interesting base address.

 

I didn't look for other processors.

 

I have no linux kernel dev experience though so it may take a while for me to create a functional one, albeit copy pasting the raspbian's one (yay GPL I guess?).

 

Does this sound like a "good" idea?

[zador.blood.stained]

On the other hand, /dev/gpiomem has real benefit to run gpio apps fast (read the pin directly from the CPU register), without using gpio sysfs, without requiring root. This is a pure "Raspbianism" but I think it's a good feature to be looked into.

 

This requires writing a kernel driver something like https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/bcm2835-gpiomem.cbut for other processors. That's harder to do for a end user than adding udev rules.

We already have sunxi-pio (part of sunxi-tools) and some forks of Raspberry Pi compatible GPIO library that use same method. The only difference is they use /dev/mem, so either superuser privileges or full access to /dev/mem for normal user is required.

[maruel]

That's my point; /dev/gpiomem was created to give only access to a few Kb of non translated memory without compromising on security.

 

I'd rather have my GPIO using apps not run as root and/or be able to poke into the kernel's memory as a user.

[zador.blood.stained]

That's my point; /dev/gpiomem was created to give only access to a few Kb of non translated memory without compromising on security.

We,, bcm2835-gpiomem driver looks simple and platform-independent, but maintaining sets of patches for all devices and kernels will be tricky, and this is not counting the userspace part.

[maruel]

Context: I implemented a GPIO driver in Golang for A64 running armbian using memory mapped registers leveraging /dev/mem. Will test on H3 as soon as I receive my board. The main improvement over sunxi-pio is that I implemented edge based triggering leveraging sysfs gpio, since interrupts are not accessible in user mode yet polling sucks.

 

I realized the /dev/gpiomem concept (at least as implemented by Raspbian) is not applicable on (some) Allwinner processors (at least on A64 and H3) because they require 2 separate sections to be memory mapped to access all the pins. GPIO belonging to group PB to PH use the registers located at 0x01C20800 and group PL uses registers located at 0x01F02C00. So I'll forget on this gpiomem idea for now. And since Pine64 has PL pins on its PI2 header, it's really important to be able to access this group.

 

That's annoying as this requires me to run my app as root for the foreseeable future, which is really a downer.

 

---

 

<random rant>

 

Allwinner CPUs has only a subset of pins supporting edge based triggering: in groups PB, PG, PH and PL, unlike bcm283x which supports it on all pins. On the other hand, you can query the current pull resistor on any pin on Allwinner, unlike bcm283x which is a black box. You can't have it all...

[pmartin]

[...]

 

Adding a group and users to it is simple. Limiting this whole thing to one platform (H3/legacy) also. But if we don't provide consistent support for at least all boards that feature a RPi compatible header the efforts are somewhat useless since the time saved for supporting a specific board will be spent answering the same question again and again in forum

From my experience with the RPi: creating the gpio group and adding the proper udev rules is all that is needed. I am fine with adding my account name to the gpio group (I understand that server use cases might not want to grant access to GPIO to all users).

 

My applications do not require so fast access that I need any /dev/gpiomem. Normal access to GPIO is capable of thousands read/write per second at least, and all I need for sprinkler control is tens of read/write per _day_  . If the application needs the kind of speed that /dev/gpiomem provides, how does it get consistent and stable timing on Linux? Real-time priorities? Even then..

 

I am also fond of the RPi, but Raspbian is not always right. I do remember GPIO on Raspbian being a mess for some time. It handled GPIO properly only recently (adding the udev rules within the last 2 years or so). I had to survive some udev rules' oddities (open the gpio pin, see access being allowed, then rescinded, then allowed again--a race condition probably).

 

Regarding support: maybe add a table documenting the Linux GPIO to board connector's pins mapping in each board's specific page? See the Scargill blog on the NanoPi Neo (http://tech.scargill.net/the-friendlyarm-nanopi-neo/) as an example.

[Rudolf]

Armbian more user friendly.

I try to make Armbian more user friendly. Please see my documentation for the Orange Pi Lite (WiFi on board):

http://www.rudiswiki.de/wiki9/OrangePiKnowHow

It has the following topics:

    Know How for the Orange Pi
    Orange Pi Lite
        Armbian software
        WiFi connect
    Orange Pi One
        Armbian software
    Shared software additions
        Screen resolution HDMI
        VNC server
        VNC and sudo
        VNC and Screen Shot
        Terminal TAB command complete
        Often use programs
        Samba share
        XFCE4 panel additions
        Python, TKinter
        Tipps
    Hardware IO
        Analog
        Audio
        GPIO
        I2C bus
        Infrared
    Links

 

For the xfce4 desktop upper panel I added some useful plugins:

 

 

I think that also for IOT a desktop make sense, please see my frequency response analyzer:

http://www.rudiswiki.de/wiki9/RaspberryPiWobbulator#Measurements_and_conclusion

 

What I am still missing is the possibility to access the I/O pins from the user via Python.

 

Regards, Rudolf

[arox]

I think that also for IOT a desktop make sense ...

 

A remote Gui can make sense, but not a "desktop". And if you need such a GUI, it should be some mundane http browser. I don't understand why my thermometer should host 700 MB of icons ? Simply, "Windows" is obsolete and people trying to make linux windows-like are also obsolete.

[Rudolf]

A remote Gui can make sense, but not a "desktop".

I mean:

https://en.wiktionary.org/wiki/desktop

quote: (computing, graphical user interface) The main graphical user interface of an operating system, usually displaying icons, windows and background wallpaper.

 

If you have a Tkinter window for showing a diagram, or a RRD graph it makes for sure sense.

Regards, Rudolf

[chocomega]

Is there any progress on this topic ?

I've managed to setup the permissions for GPIO and it took me a while to figure it out (I should had look on this forum first...) so an option to set this up automatically would be great for newbies like myself.

But I must admit it is also part of the fun to dig for infos on the internet (when it works)

[Tido]

On 18.8.2016 at 5:26 PM, Igor said:

We can simply ask on user creation: "Do you want to have access to GPIO?"

I was just thinking adding this to armbian-config: create dedicated GPIO user

[Tido]

Just thinking out loud, would it make sense to combine this creation with the installation of ?

• https://nodered.org/ - Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.
• http://mqtt.org/ - MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol.
• http://mosquitto.org/ message broker that implements the MQTT protocol

[tkaiser]

7 minutes ago, Tido said:

would it make sense to combine this creation with the installation of

 

To do this correctly a lot of work is needed. I started with something like that based on @Peter Scargill's 'the script' but gave up back then due to other priorities.

 

IMO it would be great if Armbian lays the foundation for something like that (root-less GPIO access and such basics, having I2C and SPI active with mainline kernel by default without having to fiddle around with DT overlays first and so on...) and it would also be great to fix current issues with eg. armbian-monitor first before adding new functionality.

[bozden]

Why not add it into armbian-config?

[barish]

On 18.8.2016 at 4:14 PM, tkaiser said:

Simple example: Default user pi in Raspbian has access to GPIO pins -- on Armbian it's currently root only. How's that done? A group called gpio exists in Raspbian, pi is added to it and /etc/udev/rules.d/99-com.rules does all the magic:

 

So would it do any harm, if by default a udev rule is added to armbian which creates a group "gpio" and allows access to /sys/class/gpio to this group?

 

It would save me some work, and other users of openHAB , which by default adds the user "openhab" to group "gpio" (if it exists), would have a working service out of the box.

[tkaiser]

7 hours ago, bozden said:

Why not add it into armbian-config?

 

Just two reasons:

 

1) It does what it tries not always good

2) It does what it tries not always good

 

But since discussions never happen, the only way to deal with this is frustration and discouragement 

[arox]

11 hours ago, Tido said:

Just thinking out loud, would it make sense to combine this creation with the installation of ?

• https://nodered.org/ - Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.
• http://mqtt.org/ - MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol.
• http://mosquitto.org/ message broker that implements the MQTT protocol

 

Mosquitto is packaged with apt. Why not nodered ?

 

(I am asking myself if I want or need to use nodered and found some pretty long, complicated and boring tutorial ...)

[lagerschaden]

It would be GREAT if rootless access to gpio was integrated in armbian (just like in raspbian).

 

I made a little test on my Orangepi-One:

created a group gpio and added the user to the group gpio, then created the file /etc/udev/rules/99-gpio.rules, this makes the access rootless

# /etc/udev/rules/99-gpio.rules

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
    chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
    chown -R root:gpio /sys/devices/platform/sunxi-pinctrl/gpio && chmod -R 770 /sys/devices/platform/sunxi-pinctrl/gpio;\
    '"

Edit (02/09/2018): for later versions of armbian the file must change (tested with 4.14.18 and 4.14.65):

# /etc/udev/rules.d/97-gpio.rules

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
    chown -R root:gpio /sys/class/gpio && chmod -R 0770 /sys/class/gpio &&\
    chown -R root:gpio /sys/devices/platform/soc && chmod -R 0770 /sys/devices/platform/soc'"

 

Now you can use the access on the bash for the PIN PA12 (calculation see https://linux-sunxi.org/GPIO)

echo 12 >  /sys/class/gpio/export                  # enable access to PA12                 
sleep 0.1                                          # wait some time to become gpio12 active
echo out > /sys/class/gpio/gpio12/direction        # PA12 is output
echo 0 >   /sys/class/gpio/gpio12/value            # PA12 is low
echo 1 >   /sys/class/gpio/gpio12/value            # PA12 is high
echo 12 >  /sys/class/gpio/unexport                # disable access to PA12

My skills in programming are not good enough  to transform this to C, C+, Python etc, but you don't need any root privileges.

Edited September 2, 2018 by lagerschaden
changed for later versions of armbian

[bozden]

15 hours ago, tkaiser said:

1) It does what it tries not always good

 

Well, of course you know much better, I only used it on OPi devices and legacy OS.

 

I wrote an installation script similar to what DietPi does (1's or 0's to turn features on and off). If GPIO is on,  it handles the groups/users stuff, downloads and compiles related repository for WiringPi. Much work to go of course for adding stuff like MQTT or OpenHub etc.

 

But I'm sure it will be much difficult for so many devices and multiple OS versions...

 

[barish]

@lagerschaden, I did the same with my Olinuxino Micro A20, and had to change one path in the udev rule:

 

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
    chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
    chown -R root:gpio /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio && chmod -R 770 /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio;\
    '"

This seems to work well, I tested with GPIO pins 1, 2, 3 and 112, 114, 116, 118.

As a pure user of GPIO (and not really a programmer) I've no idea on what the path name depends, why it's sunxi-pinctrl in your case and soc@01c20800.pinctrl/gpiochip0 in my case (I am using mainline kernel).