For the most part, everything outlined in the install instructions for installing to a Linux based system applies to Armbian and goes smoothly.
Installs to both OrangePi Zero and Friendlyarm NEO went smoothly with a couple of exceptions noted below.
-
There is no default account in the Armbian installation. After install, users ssh to the unit as 'root' and are prompted to change the root password and then prompted to create a new user account.
If you create an account named "pi" then all the Octoprint Installation Instructions can be followed almost blindly using the `pi' account.
If you create an account of another name, (ie oprint), then you have to update the scripts and system permission instructions with that user name.sudo usermod -a -G tty pi -> sudo usermod -a -G tty oprint -
If you use a plugin that accesses and uses GPIO pins and the behavior is not as expected, then as with all things Octoprint, first check the log files to see what is going on. In this case, the PSUControl plugin was the one plugin of interest.
2021-12-28 14:38:06,637 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2021-12-28 14:38:10,830 - octoprint.plugins.psucontrol - INFO - Periphery version: (2, 3, 0)
2021-12-28 14:38:10,831 - octoprint.plugins.psucontrol - INFO - Using GPIO for On/Off
2021-12-28 14:38:10,831 - octoprint.plugins.psucontrol - INFO - Configuring GPIO for pin 6
2021-12-28 14:38:10,851 - octoprint.plugins.psucontrol - ERROR - Exception while setting up GPIO pin 6
Traceback (most recent call last):
File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/gpio.py", line 539, in _open
self._chip_fd = os.open(path, 0)
PermissionError: [Errno 13] Permission denied: '/dev/gpiochip0'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/octoprint_psucontrol/__init__.py", line 190, in configure_gpio pin = periphery.GPIO(self.config['GPIODevice'], self.config['onoffGPIOPin'], initial_output)
File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/gpio.py", line 496, in __init__self._open(path, line, direction, edge, bias, drive, inverted, label)
File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/gpio.py", line 541, in _openraise GPIOError(e.errno, "Opening GPIO chip: " + e.strerror)periphery.gpio.GPIOError: [Errno 13] Opening GPIO chip: Permission denied
You may need to update the permissions on the Armbian installation to allow the octoprint user to access the GPIO pins and you need to properly identify the GPIO pins.
On a raspi based system, the default permissions for the gpio are visible with an ls -l
user@raspbian:~ $ ls -l /dev/gpiochip0
crw-rw---- 1 root gpio 254, 0 Dec 27 07:47 /dev/gpiochip0
Compared to the armbian install-
user@armbian:~$ ls -l /dev/gpiochip0
crw------- 1 root root 254, 0 Dec 27 23:52 /dev/gpiochip0
Notice the difference in the file permissions and owner name and owner groups. On the default raspi system, the owner is 'root' and group is 'gpio'.
On the armbian system, the gpio pins are owned buy the root group.
We can fix this by creating a gpio group, and then adding the octoprint user to that group. So to fix the permissions on armbian, we need to do some udev rules magic.. Refernce page: GPIO - linux-sunxi.org
-
Create the new gpio group and add the octoprint user.
user@armbian:~$ sudo groupadd gpio
user@armbian:~$ sudo usermod -a -G gpio oprint
You can verify the group creation and user addition-
user@armbian:~$ sudo getent group | grep gpio
gpio:x:1001:oprint
shows that in the group 'gpio' the user 'oprint'is a member..
-
Create the udev rule with the proper ACLS's
user@armbian:~$ sudo /etc/udev/rules.d/96-gpio.rules
# /etc/udev/rules.d/96-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/sunxi-pinctrl/gpio && chmod -R 0770 /sys/devices/platform/sunxi-pinctrl/gpio'"
SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
save and reload the rules -
user@armbian:~$ udevadm control --reload-rules && udevadm trigger
restart the octoprint service or just reboot
user@armbian:~$ sudo service octotoprint restart
now checking the permissions of gpio, we see that they belong to group 'gpio'
user@armbian:~$ ls -l /dev/gpiochip*
crw-rw---- 1 root gpio 254, 0 Dec 28 19:16 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Dec 28 19:16 /dev/gpiochip1
and since the user oprint is a member of the group 'gpio' then octoprint is able to access the gpio pin.
- Verify that you are citing the pin number correctly. Pin names on ARM SoC based boards are little different than raspberry pi's. The best way to identify the pin is with a manufacture drawing. Here is an example of an OrangePi
For this example, we are going to use PA06 as the pin of interest. If no direct GPIO reference is given, then we can calculate it from the pin name. From the GPIO - linux-sunxi.org
and
https://github.com/torvalds/linux/blob/74c78b4291b4466b44a57b3b7c3b98ad02628686/drivers/pinctrl/sunxi/pinctrl-sunxi.h#L19 pages-
To obtain the correct GPIO pin number calculate it from the pin name: (position of letter in alphabet - 1) * 32 + pin number
For pin PA06, it would be (1-1)*32+6 = 6 (since A is the 1st letter)
and thus we would use GPIO pin 6 for the plugin of inteterest, PSUControl.
