The board is rectangular, 79 mm wide and 127 mm long. (The wiki says 80 mm by 133 mm) It has 4 mounting holes at the four corners, these form a rectangle 71 mm by 118 mm. The holes are 3.3 mm in diameter, large enough for an M3 bolt to fit comfortably. They are lined with metal, connected to the GND bus.
There is an image of the board here: http://files.pine64.org/doc/Pine%20A64%20Schematic/A64-DB-Rev%20B-TOP%20Preliminary.pdf.
There are the following IOs, from looking at the board and starting at the top left corner, and going around déasil:
| Label | connector | Purpose |
| TP | 6-pin high-density | Touch-control |
| CS1 | high-density | Camera |
| PI-2-Bus | 40 pins | GPIOs. |
| VBAT | 3 pins | Lithium Battery |
| RTC | 2 pins | RTC battery |
| USB | 2xUSB-A | apparently the top one allows for gadget-mode |
| WIFI/BT | 14pin and 16pin | Bluetooth/Wifi card connectors |
| 3-pin socket | IR receiver input. | |
| Headphone+mic | 1/8 in TRRS jack | Audio |
| SD Card socket | SD-card for boot and OS | |
| Exp | 10 pins | GPIOs. |
| Euler Bus | 34 pins | GPIOs. |
| DS1 | high-density | LCD-panel Display |
| POWER-JACK | Micro usb B | Power in |
| LAN | RJ45 | Ethernet |
| HDMI | HDMI | HDMI Video out |
For the connector named PI-2-Bus, the naming and form-factor suggests that this is going to be a set of gpio lines very similar to the 40 pins IO on Raspberry Pi devices. Indeed, the pinout is as close to this as appeared to be possible -- the various ground and power pins are all in the same locations, as are pins capable of i2c, SPI, and UART functions.
There are several features here that are very similar to what we know from the Raspberry Pi: The power input is the same kind of micro-USB-B; there is a SD-card for the OS from which the device boots. Then there are USB connectors available for keyboard and mouse, HDMI for a screen; wired Ethernet, GPIO signals.
The processor is Cortex A53, which turns out is the same as the one the Raspberry Pi 3 has. However, the Pine64+ has twice the RAM and what appears to be a wider Ethernet bandwidth, as it isn't limited by the USB2 channel of the Raspberry Pi. Also, a real 64-bit linux is available for the Pine64+ now, so it will be interesting to see how well it performs for the streamng SDR system that I am looking at. Since there is some kind of sound input on-board this might not require any separate sound card either.
Some links to pages with interesting and useful info:
Homepage
Forum
Wiki with some info
IRC channel
I pulled in the Debian Jessie version that has been developed for the PineA64 from the link in the forums. (Great thanks to longsleep and lenny.raposo)
This seemed to be a good choice. There are several other operating systems in development, Android, and Linux distros such as Armbian and Fedora. These are all continually being updated and improved.
The system shows that sizeof(char *) = 8 and sizeof(size_t) = 8 so we have 64-bit architecture. sizeof(time_t) = 8 also, so there is no year-2038 problem to be expected here!
There is support in the kernel for i2c and for the several UARTs so far (2016-08-23) and for SPI. The i2c-1 buss works and a couple of cards that I have, which were originally designed for the Raspberry Pi have been plugged in and found to work fine, though with one important change: the pull-up resistors for SDA and SCL to +3.3 V have to be added as they are not already in place.
There is an RTC onboard and the hwclock utility does work. NTP client is also up, so I get the correct time from various chimers right away.
Userland (sysfs) GPIO support exists, as we have and can see the /sys/class/gpio directory.
GPIO control via /dev/mem is also possible. The code resembles the one on Raspberry Pi, just that there are other registers and addresses defined.
And then I have been able to create and use a custom kernel module, which also can be used to deal with the gpio lines.
Thoughtful aside: Where does fixing end and hacking begin? Adding the resistors to the i2c-1 bus so that the system operates as advertised on the box is fixing. Adding wires to the test-points behind the TP connector in order to access the i2c-0 bus is hacking. Don't even have to solder: plugging custom devices onto the Wifi or Bluetooth connectors, is also hacking. In both cases are we now trying to do things that never were planned for by the designers. Compatibility may suffer, but in projects where the LCD or Bluetooth/Wifi are not being used, why not use these gpios and functions for something fun here?
The developers at Armbian have done a great job of making a more recent kernel, 5.10. There is a utility armbian-config which helps out with enabling and disabling various devices.
