I tried openbsd 6.2
Installing this is easy, I pulled down the file miniroot62.fs from https://mirrors.dotsrc.org/pub/OpenBSD/6.2/arm64/ and copied it to the SD card with the usual dd command:
dd of=/dev/sdb if=miniroot62.fs
Hook up a serial cable to UART0, pin X7, X8, X9, with a terminal running at 115200 at the other end of it, put the sd card in and power on.
Then it is a matter of selecting I for install, then go through the rest of the installation, where it asks for usernames, passwords, hostnames, and what other packages to install. I chose all of them as was recommended.
Now for examining the system. It is bsd unix, so it is familiar, yet things are quite different under the hood. There is no systemd for example, here things work traditional with /etc/rc files.
The compiler here is clang, not gcc, and that means that there is a different way to create shared libraries. Something like this seem to work fine:
CCFLAGS=-I /usr/local/include -Wall -O -fPIC -fvisibility=hidden OFILES=whatever.o somethingelse.o cc -c $(CCFLAGS) whatever.c cc -c $(CCFLAGS) somethingelse.c cc -shared -o libexample.so $(OFILES)
Turns out, there is a different way to deal with them as well: linking new .so files in standard locations such as /usr/local/lib seem to require a reboot in order to work.
Another thing, the various #includes are not quite the same, and this compiler is much more pernickety about undefined functions.
More details on what works in terms of gpios and other things will follow.
This is a true 64-bit system:
Size of void * = 8 Size of code * = 8 Size of size_t = 8 Size of time_t = 8 Size of long long = 8 Size of long = 8 Size of int = 4 Size of short = 2 Size of char = 1 Size of long double = 16 Size of double = 8 Size of float = 4
The way to handle gpios is via ioctl() calls on the /dev/gpio* devices. Seems a little like old-school unix in some ways... let's see what it takes to turn an LED on and off through this. There are 3 of these: /dev/gpio0, /dev/gpio1, and /dev/gpio2. I have a hunch that the three gpio devices correspond to the three blocks of gpios that we see as symlinks in the /sys/class/gpio directory on Linux systems. Thus /dev/gpio0 would be the PB-PH ports, /dev/gpio1 are for the PL ports, and /dev/gpio2 is the set of pinctrl.1 ports from the pmu, linear 1024 on up.
Time to checkout gpio(4) and the command-line tool gpioctl(8).
The device-files are showing with rw for owner root only, so we might have to use setuid or make a server process.
Now a simple open, then call to the ioctl(gfd, GPIOINFO, &gi) showed that the three gpios offered 0 pins each... Not too encouraging. Looks like these have to be allocated and made available earlier on.
Documentation says, the gpios have to be pre-allocated in /etc/rc.securelevel And indeed, creating /etc/rc.securelevel and /etc/rc.local with simple echo hello in them, shows them being run before and after the "closing of the secure door" takes place during startup.
So which gpio numbers are which? Can it be as simple as /dev/gpio1 pin numbers map to the PL numbers, since these are in the second controller space at 0x1f02c00 ? PL10 is on pin P7, so what does
gpioctl gpio1 10 set out pp
do, if anything? nah, gave me:
gpioctl: GPIOPINSET: Operation not permitted
But what if we try this in the /etc/rc.securelevel file?
No, same thing there. Without args, it tells us that each of the three gpio devices have 32 pins.
That doesn't map to the previous expectation... And the stock system doesn't show any of these gpios to be change-able, probably because it is not tuned for the Pine 64 hardware, but just some generic setup, or maybe it is set-up to match whatever is present on the Raspberry Pi 3 instead.
I will leave this on the shelf for now.
Now, it turns out this same 64-bit openbsd is supposed to run on Raspberry Pi 3, since these are 64-bit, so that can be another interesting thing.
