Piki on Pine64

My friend Harold Wong gave me a Pine64 as a retirement present. My plans for this machine are:

• I had a very old audio playback node called Piki the Poison Dart Frog, which died. I transferred another old machine into this role, but the Pine64 would make a very nice and power-efficient replacement.

• Learn about ARM processors and set up procedures to support ARM on OpenSuSE.

• I need a new mini-laptop. The available products with Intel processors are slugs, but the ones with ARM processors look attractive. I want to assess whether the ARM machine is going to be supportable in my ecosystem.

What is a Pine64?

The Pine64 is a single board computer with these features:

• Allwinner A64 SOC.
• CPU component: ARM Cortex A53 64bit 4 cores @1.2GHz
• Graphics component: Mali 400-MP2, up to 4k x 2k px; full size HDMI connector
• Micro SD card slot: addressing limit 128Gb
• Ethernet: 10/100MHz (RJ45)
• USB-2.0 type A, 2 ports
• 3.5mm stereo jack (FAQ says 4 wires with mic)
• Expansion buses for Raspberry Pi and Euler
• Power: micro-USB connector; power supply is not included, needs 5 volts 2 amps when booting, typically 0.5 amps when idle.
• Price: $15 plus shipping, $7 to USA, $14 elsewhere

There are newer variants with 1Gb or 2Gb RAM, gigabit Ethernet, and connectors for a camera and a display panel with touch.

Web resources:

Pine64 Company Page

The front page does something with dynamic content in the product hype, which takes a lot of CPU power for client-side scripting, so leave that page as quick as possible.

Pine64 FAQ

The FAQ appears to be for the original board. Later, two upgraded boards have come out which I don't see mentioned in the FAQ.

sunxi Linux for Pine64

This is a open source community site that supports Allwinner SoC based devices. These chips are designated sun4i, sun7i, etc., hence the name sunxi. The one in the Pine64 is the sun50i. This appears to be a Linux distro for ARM. They have what they call a near-mainline kernel port based on kernel 4.7 (not feature complete), and a lot of interesting information about the Pine64 hardware details.

Pine64: The Un-Review

by Brian Benchoff (2016-04-21) on Hackaday. He had a lot of trouble with his Pine64 and never got any of the available OS images to boot, hence the un-review title. There are a lot of comments; many people had no problem getting their boards to boot and run. Brian and another commenter complain that their motherboard was warped. Remember to attach your power button, which is needed to turn off the Android image. jimc says: The symptoms suggest a flaky wall wart (customer provided) that provides less than 2 amps. You see the same problem on Raspberry Pi.

Pine64 Quick Start Guide (with Gotchas)

By Ray Hightower (2016-04-04). Highlights of the blog post:

• As of the posting date, the kernel on the Arch Linux image has a bug in DMA; there is at least one other distro (not named) that has the same bug.

• Images are distributed in RAR format; use unrar to decompress (its license does not qualify as free software). Using a machine other than the Pine64 :-) copy the image onto your SD card using dd. Jimc says: It should be possible to use the p command to unrar to extract to standard out which could be redirected to the SD card raw device.

• Move the SD card to the Pine64. Turn on power. His machine booted with no hassle. His Arch Linux image has 3 default users: root, guest, alarm. Password is the same as the loginID (super secure, change right away :-).

• Pine64 uses 2.5 watts. Jimc says: According to the Pine64 FAQ, this is the power once booted up, 0.5A (500mA) at 5V. It draws 2A while booting (10W), and a smart charger will not deliver over 0.5A without negotiation, which the A64 doesn't do (same for Raspberry Pi). That would prevent booting; see the un-review above. And a wall wart with a marginal max current could cause unreliable but sometimes successful booting.

• The DMA bug manifests itself with the network device. He doesn't say much about the exact symptoms or what to do about it. (Jimc says: this could be the reason for slow networking reported by some forum posters.)

• Jimc research: this commit on Github, dated about 2016-07-15, may or may not fix the DMA problem.

Benchmarking The Low-Cost PINE 64+ ARM Single Board Computer

By Michael Larabel (2016-03-26) on Phoronix. He's testing the Pine64+ with 1Gb RAM; mine is the non-plus with 0.5Gb RAM and less features. Here's what the Pine64+ has:

• Processor: ARM Cortex A53 64bit 4 cores @1.2GHz, by Allwinner
• Graphics: Mali 400-MP2 (on chip), full size HDMI, 4Kx2Kpx
• RAM: 1Gb (also available: 0.5Gb, 2Gb, fixed at time of purchase)
• Card slot: MicroSD, 256Gb addressing limit (FAQ for the non-plus model says its limit is 128Gb)
• Ethernet: Gigabit (mine is 10/100MHz)
• USB 2.0, 2 ports
• Sound: 3.5mm stereo out (no mic) (FAQ says it's 4 wires with mic)
• Realtime clock on board
• LiIon battery charger on board
• Connectors for display panel with touch, and a camera (not on my board)
• Expansion buses for Raspberry Pi and Euler
• Price: $19 (depends on memory) plus shipping ($7 to USA, $14 elsewhere)

Open source drivers for the Mali 400-MP2 GPU are not available, which means that you get unaccelerated 2D graphics. In contrast the Broadcom VC4 GPU on the Raspberry Pi has reverse engineered drivers.

The kernel used in this test, from Arch Linux, is Kernel3.10.65-2-pine64-longsleep (aarch64). Michael had no problem booting this image.

Benchmark results of the Pine64 are similar to Raspberry Pi-3, maybe 10% faster or slower depending on which test.

OpenSuSE for Pine64

OpenSuSE has distro support for the Pine64. There are at present (2016-08-01) two variant images:

• Based on kernel 4.5. This is a near-mainline kernel and is intended to mature eventually into something that can be included in the Linux kernel tree. The serial port (UART) works, but not much else. In particular you don't have Ethernet, USB, graphics or SMP (multiple cores). Except the description says it is pre-configured to use DHCP to request an IP address…

• Based on Allwinner's hacked 3.10 kernel. This one is pathetically back-version and does not get driver or security updates. But ethernet, graphics, USB and presumably SMP all work.

• Terra854 has updated the SuSE image (2016-08-05). Download link, 1.9Gb, looks like uncompressed. It has kernel 3.10.101-0-pine64-longsleep-39. Even so, rpm -qa shows that package kernel-default-4.5.0-3.1.aarch64 is installed and kernel-default-3.10.whatever isn't, and none of the files from 4.5.0 are present whereas all the files from 3.10.101 are there.

What's In the Box?

The motherboard only. You provide your own wall wart, SD card, keyboard, mouse and display. Harold nicely included a non-smart wall wart rated for 5V 2A, the kind used for a Raspberry Pi. Referring to the review above by Brian Benchoff, my motherboard is not warped at all. RoHS compliant. Board dimensions: 126 x 80mm (5.0 x 3.25in). The RJ45 and USB connector stick out a few mm more.

I'm planning to get a new SD card. Forum posters report good results with the Samsung EVO product line and problems with low-priced ersatz cards, so I'm going to go with the crowd on this. SBSF Amazon, prices are $10 for 32Gb, $20 for 64Gb, $40 for 128Gb. SanDisk, Toshiba and Transcend are also mentioned as reputable.

I also want an enclosure. Amazon has a nice-looking wood one for $15; also some plastic/metal cases. I'll tell you if I like it when I get it. Ordering the Eleduino PINE64/ 64 plus Acrylic Enclosure Case (Black), $13.49. Nicely made, fits perfectly, has cutouts for the expansion buses, which are important for connecting the serial cable.

Serial Console

For kernel hacking I would need a UART to USB adapter for the serial console. I'm not sure how much use I'm going to get out of this since everything is supposed to just work (yeah, sure), but If I do mess with the SuSE 4.5 kernel I'm going to need the serial console to see what it's doing. It's going to attach to pins on the Euler bus with flying leads (I guess). Gotcha: when you disconnect power for a hard reset, current leakage from the UART prevents a complete reset. Either disconnect the UART too, or add a reset button to the board.

elinux.org wiki for Pine64 serial console. They have a link to a product, a 1 meter cable with USB type A on one end, and 3 flea clips on the other. There is a Future Technology (FTDI) UART to USB chip hiding inside and it appears on the host as a USB TTY. Price $15 (USD) from Digikey. Several similar products are available on Amazon; look for TTL-232R-RPI and beware of cheap imitations.

Combining info from the datasheet for the TTL-232R-RPI on Allied Electronics and the linux-sunxi.org wiki page for Pine64 yields these connections for the serial console. Host to client means from your laptop to the Pine64, and vice versa. The EXP bus is labelled and is between the Euler bus and the SD card slot; pins 2, 9 and 10 are labelled. The wiki page's pin labels are from the client's point of view (TXD means Pine64 sends to laptop) whereas the datasheet labels them from the host's point of view (TXD means laptop sends to Pine64). The same UART is accessible on the Euler bus, but from the EXP bus there is a buffer so client RXD can't leak power into the Pine64 preventing a proper shutdown.

You end up with the black wire on the pin closest to the edge of the board and closest to the card slot; the yellow wire next to it; and the orange wire as the yellow wire's cross street neighbor. It works.

Data written to the serial console will appear on the Linux USB TTY. Use your favorite console emulator such as kermit to see what it displays and to send commands. The wiki page author recommends screen with this command line, modified by jimc for Linux. Execute as a user with write access to the TTY, e.g. root, and substitute the correct device name if you have several of them.

screen /dev/ttyUSB0 115200

Initial Attempt

I got the SD card, the serial cable, and the case. These were my initial steps to check out the Pine64 board.

Preparation for Checking the SD Card

• I installed iozone-3.430 and tiobench-0.4.1 from SuSE Build Service.
• modprobe rtsx_usb_sdmmc -- I have this blacklisted because …
• The card ended up on /dev/mmcblk0p1
• Unknown filesystem type exfat (duh, it's proprietary for Windows)
• For testing I formatted it with ext4. mkfs -t ext4 -L EVO-64G /dev/mmcblk0p1
• To use the -U option of iozone, you need to put your mountpoint (and device) in /etc/fstab temporarily. And of course you need to mount it first.

Check the SD Card

• iozone -a -U /mnt -f /mnt/testfile.dat 2>&1 | tee /tmp/iozone.out
• Observations while running the tests:
  • The output is about 160 bytes wide. Expand your window horizontally, for easier reading.
  • Random reads are around 37 Mbyte/sec. Actually this same speed is seen for all tests with read in their title.
  • Tests with write in their title are a lot faster, 1.9 to 2.4 Gbytes/sec. This has got to be a cache effect: write the data into a mbuf, say it's done, but the data will actually be written when the driver gets around to it. If I had used the -s (synchronous) option, I might have gotten a better test.
  • For read and reread, if you read the entire file in one or sometimes 2 chunks you can do it at up to 6 Gbyte/sec. This has to be some kind of optimization, different from the asynchronous write issue.
  • The test in auto mode (-a, test everything) takes a lot of time. I was not patient enough to wait for it to finish, since I'm only trying to verify that the card is working close to the expected speed, not to compare details of different cards. After about 45 minutes it was just starting 0.5Gbyte files.

• I really want to do a simple defect scan. Here's a command line:

  while dd if=/boot/initrd bs=1M status=none ; do /bin/true ; done > /mnt/testfile.dat

  Guess what, it's going to take about 15 hours to write the stuff and then read it back and compare. Hmm, let's defer this to overnight.

Assemble the Case

• This is the Eleduino PINE64/ 64 plus Acrylic Enclosure Case.

• The transparent parts have a protective film which you should remove.

• The black part goes on the bottom. Preassemble the hexagonal spacers in the four corner holes using 4 of the provided screws.

• Set the Pine64 board on the bottom sheet (orientation doesn't matter). Match up the cutouts in the sidewalls with connectors on the Pine64, and drop the sidewall's feet in their slots in the bottom plate. Several of the end connectors are surrounded by the holes in the sidewalls so you'll need to lift the Pine64 board. Finally, orient the top sheet so the cutouts match with the bus connectors, and set it over the sidewalls' upper feet. Attach the top sheet with the remaining 4 screws.

Preparations for Board Testing

• What hostname am I using? Piki the Poison Dart Frog. The old Piki is pushing daisies so I can use this name immediately.
• I have an aggressive internal firewall. I need to register the Pine64's MAC address. [Done.]
• Download 3 filesystem images. Save them in /s1/pine64 .
  • OpenSuSE pseudo-mainline based on kernel 4.5. 252Mb, took 17 mins. Renamed to openSUSE-4.5-pine64.raw.xz .
  • OpenSuSE based on kernel 3.10 provided by Allwinner. 183Mb, took 10 mins. Renamed to openSUSE-3.10-pine64.raw.xz .
  • Debian Jessie by Lenny Raposo with Longsleep kernel. 1.6Gb, took 25 mins. Renamed to debian-jessie-pine64.zip .
• Copy one of the images to the SD card, using the indicated command line.
• Starting with the Debian Jessie image by Lenny Raposo.
  • On your laptop or desktop machine, insert the SD card in the card slot, but do not mount it. Unmount, if already mounted for testing.
  • For me the raw device is /dev/mmcblk0 . Make sure you have correctly identified your raw device.
  • unzip -l debian-jessie-pine64.zip -- lists the content; it contains one 8Gb image file.
  • unzip -p debian-jessie-pine64.zip > /dev/mmcblk0
    Took 395 sec, mostly writing the card. There is no speed advantage if you unzip to disc and then copy to the card.
  • Gnu parted (parted /dev/mmcblk0) reveals a BIOS/MBR partition table with two partitions: 52Mb FAT16, and 7.5Gb ext4. But you can't mount them. Quit. Remove the card and re-insert it; now the kernel re-reads the partition table. Unmount them, if an automouter mounts them automatically.
  • Run parted again. resize 2 100%. This allocates the rest of the space on the card to the root partition. Quit.
  • fsck -f -C /dev/mmcblk0p2 (required by resize2fs, and is prudent anyway).
  • resize2fs /dev/mmcblk0p2 (expands the filesystem to fill its partition).
  • fsck -f -C /dev/mmcblk0p2 (again, for paranoia).
  • Mount and investigate the partitions. Partition 2 appears to be a normal installation of Debian Jessie. Partition 1 (FAT16) has the kernel (11.7Mb) and the initrd (only 1.1Mb).
  • Unmount the partitions. Move the card to the Pine64.
  • The card slot is a ratchet type: push the card in all the way and it will spring out slightly. To remove it, push in again and release; the card will jump out.

Power It On -- Debian

• Turn on the monitor. Connect the serial cable. Start screen running on your real machine.
• The power connector (micro-USB) is upside down; the wire's USB logo goes on the bottom.
• When you plug it in, a red LED near the connector lights up. Some forum posters ask, does it ever change to green? No, it's always red until you power off the machine either by a system call or by pulling the plug (avoid if possible).
• The booter shows promising messages. It boots the kernel. It appears to be using systemd as process 1, and services start up. The messages go by too fast for me to say that all wanted services start up.
• On the Debian image the loginID is debian, password debian. You are supposed to use sudo for root access.
• But screen has a lot of trouble with either missed or overlapping bytes: a lot of text is lost. This behavior went away in subsequent tries. I never found out what caused it.
• Growl, botched the login (debian/debian), it wouldn't let me retry. To power cycle the machine, pull the plug, hiss, boo! Keep this to a minimum.
• OK, it let me on.
• A lot of chars are not echoed. I think the probability that a keystroke is sent and acted on, but not echoed, is higher than missing a sent character.
• eth0 is up but has no address. I assigned it by hand, after retrying several times due to communication problems. OK it's up.
  sudo ip addr add 192.9.200.207/26 dev eth0
• sshd was already running and I can get a session (as debian).
• Which services are running?
  • systemd and friends
  • sshd
  • NetworkManager
  • freshclam (clamAV I think)
  • /usr/local/sbin/pine64_corekeeper.sh
  • cron
  • avahi-daemon
  • dbus-daemond
  • ntpd
  • minissdpd (UPnP, universal plug and play, CVE-2016-3178 and 3179 dated about 2016-03-04 and several earlier CVEs, turn this off unless you rely on UPnP)
  • rsyslogd
  • polkitd (PolicyKit)
  • Getty on ttyS0, currently in a session on the serial console
  • exim4 (mail transfer agent)
  • agetty on tty1 -- what's tty1?
  • lightdm, and the X-server is running, so it says
  • bluetoothd (no Bluetooth HCI on this board)
• /var/log/Xorg.0.log says it could not enable hardware acceleration. It wants the sunxi-g2d GPU which was not found.
• Nothing seems to wake up the display. See below, search for XAUTHORITY, for the test procedure, but like in that case it produced nothing on the display.
• I tried editing /etc/resolv.conf but the listed nameservers and/or searchlist were not honored. See below for why. Once the DHCP server (dnsmasq) had the correct MAC address, the correct IP, nameservers and searchlist were used and the machine could resolve all classes of names and could communicate (ping) with them via IPv4 and IPv6. The only discrepancy was that /sbin/dhclient for IPv6 got a random IPv6 address, not the assigned one as wickedd-dhcp6 was able to do. I didn't try to debug this.
• No dig program, hiss, boo!
• systemctl poweroff -- This cleanly turns off power; the red light goes out.

Trying the OpenSuSE-3.10 Image

• Unmount any partitions from the SD card, if auto-mounted.
• Basically the same procedure as before. The image will expand to 1.3Gb. Takes 75 secs. Command line:
  xzcat openSUSE-3.10-pine64.raw.xz > /dev/mmcblk0
• The partitions you get from SuSE are:
  • GPT partition table; parted offers to fix the backup GPT and to recognize the space not covered by the allocated partitions, but I declined both.
  • Partition 1: EFT (UEFI), fat16, 210Mb of which 0.69Mb is used.
  • Partition 2: Linux root, ext4, 1.16Gb, 96% in use.
• Partition 2 seems to be a normal SuSE root partition. Grub2 is used. The kernel is in /boot, 11.4Mb, and the initrd is 33.2Mb.
• Booting is normal on a SuSE system with Grub2. It loads the kernel, then the initrd… Oops, it's stuck. I tried several times but I'm afraid this is a writeoff.
• Let's accept parted's offer to clean up the image. The space not covered by the image remains unallocated. I used the command resize 2 100% to put all the space in the Linux partition, after which I ran fsck -f -C /dev/mmcblk0p2 (no complaints). The space is allocated but the filesystem does not cover it. I then ran resize2fs /dev/mmcblk0p2 (took 1 to 2 minutes). It looks reasonable on the laptop.
• It's still stuck. I tried power cycling the serial console but that had no effect. Several tries (power cycle the Pine64), re-seating the card, etc., still hung. I should have used my Kill-a-Watt first. In the hung state, the Pine64 draws 0 watts (red light is on so more correctly it's under 1 watt). Other people report 10W during booting. Positive control: connecting the wall wart to a cellphone with a low battery, it delivered 13W.
• Following forum suggestions I disconnected all peripherals and connected power. Same behavior, 0 watts. Most likely the thing about peripherals is either an urban legend, or someone's power supply that won't give enough power for all the peripherals, or a DMA bug that affects Ethernet, with particularly bad effects during booting; it was fixed in 2014-04-xx.
• Since the SuSE-3.10 image never booted, it's probably the culprit.

Reverting to the Debian Image

• Peripherals reconnected.
• Setting up the card same as before.
• Boot the card. It boots! Successfully! This proves that the problem was with the SuSE image rather than infant mortality of the Pine64.
• And this time the intermittent dropped characters on the serial console are not seen.

Trying the Updated OpenSuSE Image (3.10.101)

• Setting up the card same as for the other 3.10 image.
• This image uses a MSDOS (BIOS/MBR) partition table and no UEFI.
• Ordinary user: pine64 / pine64linux ; root / pine64root
• Power measurements: 4 to 5 watts, both while booting and normal running. The Kill-a-Watt meter averages over about 1 second and if there were brief spikes I would not notice. For a Raspberry Pi the power supply needs to produce 2 amps or 10 watts for reliable booting, and forum postings suggest the same power for the Pine64. This measurement was with all peripherals connected: USB hub, keyboard and mouse; Ethernet; speakers; monitor (HDMI). The latter two drew almost zero power.
• These services were running at boot:
  • systemd and friends
  • auditd
  • dbus-daemon
  • wickedd and friends including wickedd-dhcp4
  • ntpd
  • sshd
  • Getty on /dev/ttyS0 , currently in use for console session
• Traditional /var/log files are not supported (no rsyslogd), use journalctl or systemctl status.
• This image uses Wicked to manage the network but still did not get a DHCP address. (Fixed below.)
• It accepted RFC 2462 auto configuration (IPv6). But no IPv4 address.
• Wicked (wickedd-dhcp4) would not get an address, can't tell why, no messages in the journal. I added the address by hand and it worked:
  ip addr add 192.9.200.207/26 dev eth0,
  Here's a guess: nobody else can send anything, and neither can DHCP.
• Outside hosts can connect to Piki (if you set its IP address), but Piki cannot originate connections to the outside. Routes are there. Jacinth is dropping all the packets! Well, isn't that cute! The sticker on the board giving the serial number also gives what looks like a MAC address of 00:06:dc:8b:8b:03 but when the machine boots the MAC address is really 36:c9:e3:f1:b8:05. Fixed, firewall accepts the packets, networking is now normal.
• No rsync command! Can't install it because no IP address. [Fixed and installed rsync.]
• I propagated CouchNet's ssh configuration. Seems to work.
• Let's see what happens if I reboot. After I reloaded dnsmasq, which handles DHCP on my system, and wicked ifdown eth0 and ifup, it got the correct IPv4 and IPv6 addresses. On a subsequent reboot, the machine came up normally, with no hand labor.
• Keystone packages that are already installed:
  • alsa, alsa-utils
  • audit
  • coreutils
  • curl wget
  • Miscellaneous utilities: file gawk grep gzip less parted sed tar
  • gpg2
  • info
  • kernel-default-4.5.0-3.1.aarch64 (see below)
  • krb5
  • ntp
  • openssh
  • pam
  • perl python-base ruby
  • vim
• uname -r says 3.10.101-0-pine64-longsleep and /lib/modules has modules for this version. There is no sign of files from kernel 4.5.0. There is no installed package for 3.10.101. The Tumbleweed repo for aarch64 has kernel 4.5.0 only.
• There appears to be no X-server installed nor any of the usual X-Windows greeters. No sign of activity on the graphical display. chvt is there, but chvt 1 or other numbers has no effect; nor does echo XXXX > /dev/tty1.
• But there is a Mali driver loaded.
• I inserted and successfully mounted a USB flash memory stick.
• Sound (ALSA) is apparently available for HDMI as hw:0, but I can't test that. The local sound card is not in evidence. Available sound-like modules are
  • sunxi_codec.ko
  • sunxi_i2s.ko
  • sunxi_sndcodec.ko
  • snd-hrtimer.koulte
  Installing these modules resulted in messages such as:
  sunxi-codec-machine sound.6: ASoC: CPU DAI (null) not registered
  And the local sound device did not appear. Also when I powered off later it got a kernel panic shutting down one of the sound modules (can't tell which).
• SMP works; /proc/cpuinfo lists 4 processors. There is an AES engine. Also SHA1 SHA2 CRC32.
• Conclusion: These elements are confirmed working: Ethernet, USB, SMP. Sound is not working. Graphics not tested, software not installed. To do the Piki role the machine really needs sound.
• Snooping in the repo: 26351 packages, vs. 29575 in the main (Intel) repo. This was open source only, and excluding i586/i686. Less than 10% of the main repo packages are missing from aarch64.

Trying the OpenSuSE Image (4.5.0)

• It's fairly clear that I need to try kernel 4.5.0 for a complete test, and to find out how much stuff is really accessible.
• I'm going to save the image (updated 3.10.101) so I can revert to it without re-doing the configuration work.
  xz -kc /dev/mmcblk0 > piki-3.10.101u.img.xz
  Estimated 1900 secs to read 64Gb off the card. Total time 5000 secs, 100% cpu 1 core. Compressed to 231Mb (a lot of zeroes). Maybe saving the image was not such a great idea. Restoring it was also extremely slow, probably twice as long; I let it run overnight.
• openSUSE-4.5-pine64.raw.xz has a UEFI booter.
• I copied the image onto the card (same procedure as for the other OpenSuSE image), transferred it to the Pine64, powered on… Silence on the serial console. This brings to two the number of my new machines that failed to boot the installed system using UEFI. According to this thread on forum.pine64.org dated from 2015-12-29 to 2016-04-17, the Allwinner BIOS cannot boot UEFI. But tllim (I think a senior member) talked to the Allwinner people and they know the open source community wants UEFI. The problem is source closedness, not limits to what the BIOS could be programmed to do.
• Reverting to the saved image which started as openSUSE-pine64-08-05-16.img.xz .

The Way Forward

Now I need to make a strategy decision: how to get the most use out of the Pine64 with the least work. So far the only bootable images (that I've tried) have been debian-jessie-pine64.zip (by Lenny Raposo) and openSUSE-pine64-08-05-16.img.xz, the recently updated one from Terra854 with MBR booting and the 3.10.101 kernel. Unless something awesome happens, all my experiments will have to start with the latter image. I'm looking at these branches:

Better Restore Procedure

Here's a likely better procedure:

• Use tar to save the image content as files.
• It may be necessary to save the boot partition as an image, due to issues with file placement and blocklists.
• Write a script that formats the card using parted and mkfs.
• Un-tar the content. With luck this will go faster than writing 64Gb of zeroes.
• Yes, it did work better.

Test Graphics

I should expand the installed distro, and particularly, I should install the X-Windows server, a Mali driver for it (from where?), an appropriate greeter (probably lightdm, warts and all), and a minimal desktop environment, perhaps LXDE, or XFCE which I use on all my other systems.

• I'm trying to install these packages for X-Windows:
  • xorg-x11-server
  • xorg-x11-driver-input
  • xorg-x11
  • xeyes
  • xlogo
  • xload
  • lightdm
  • lightdm-webkit-greeter-branding-bevel (not in repo)
  • xterm
  • xorg-x11-fonts
  • Drags in GStreamer Multimedia Codecs- Base
  • 116Mb to download, 349Mb uncompressed
• It drags in a lot of stuff including the Gnome greeter.
• xf86-video-mali now actually exists. But not in the main repo. It is available in these forms:
  • There is a github directory with the Sunxi driver but you need to check it out and build it. I'm not sure if it has a spec file for building a RPM package. Installing a zillion build dependencies for X-Windows will be a challenge.
  • Source RPM package from www.openmamba.org for the Mali-400 GPU which is what we have. MIT license. This one is dated 2013-07-29 (old), posted by Silvan. Not promising.
  • RPM package for xorg-x11-drv-armsoc which is for ARM MALI GPUs such as on the Samsung Exynos CPU. For Fedora-24. Downloaded ftp://195.220.108.108/linux/fedora-secondary/releases/24/Everything/aarch64/os/Packages/x/xorg-x11-drv-armsoc-1.4.0-2.20151221.fc24.aarch64.rpm It requires a symbol Xorg; I'm ignoring it. No key, ignoring. See below for the result of trying this.

Results of starting display-manager with xorg-x11-drv-armsoc :

• lightdm and the X-server start up.
• /var/log/Xorg.0.log says we have: fonts, fbdev, keyboard, mouse
• /var/log/Xorg.0.log says we don't have: -keeptty (required for systemd-logind integration), AIGLX
• No sign of life on the display.
• Giving up on the armsoc driver, and uninstalling the RPM.
• (Need to intall XFCE pattern once the display works.)

Before trying to compile the sunxi driver I'm going to try to find one among the already download images. Trying these images:

• How to mount an image:

  • Decompress the compressed file to the laptop's disc.
  • parted $(image file)
  • unit B #Show sizes in bytes
  • print # Make a note of the start point of the root partition.
  • quit
  • mount -o offset=$(start point in bytes) $(image file) /mnt
  • umount /mnt # Automatically de-allocates the loop device

• openSUSE-pine64-08-05-16.img.xz -- is the one I'm running now, no relevant driver.

• debian-jessie-pine64.zip -- Drivers are in /usr/lib/xorg/modules/drivers whereas SuSE puts them in /usr/lib64/xorg/modules/drivers . Trying fbturbo_drv.so . This image also has fbdev_drv.so and modesetting_drv.so, which the Pine64 already has.

  It looks to me like the X-server is not going to load anything other than fbdev by default. The Debian image has /etc/X11/xorg.conf which specifies the fbturbo driver explicitly.

  fbturbo.so requires these shared libraries: libUMP.so.3 This is described as a Sunxi Mali-400 proprietary library. I need to steal it from the Debian image at /mnt/usr/local/lib/libUMP.so* . SuSE wants it in /usr/local/lib64, and run ldconfig after installing.

  The module's ABI (18) does not match the server (20). Blecch. That's the end of Debian. When I ran this image there was no sign that the display was alive.

• openSUSE-3.10-pine64.raw.xz -- This image has neither fbturbo_drv.so nor libUMP.so.

• openSUSE-4.5-pine64.raw.xz

Brainwave! For the tests above, for connecting my display to the Pine64 I was using a HDMI to DVI adapter, a DVI to VGA adapter, and a VGA cable. Suppose the GPU does not drive the VGA (analog) signal lines? I stole a DVI cable from another machine.

• systemctl start display-manager
• lightdm starts up; it starts the X-server. Verify in /var/log/Xorg.0.log that some graphics driver was activated and some screen was found: in my case it was fbdev, but if I were using the Debian image it would have been the Mali driver
• ps agx | grep bin/X
  It says: /usr/bin/X :0 -auth /run/lightdm/root/:0
  and other options. Note the -auth file.
• XAUTHORITY=/run/lightdm/root/:0 xauth list
• xauth add piki/unix:0 MIT-MAGIC-COOKIE-1 2beaaetc.etc.
  (Copy and paste the line printed by xauth list.)
• DISPLAY=:0 xset dpms force on
  (Wakes up the display.)
• DISPLAY=:0 xlogo
  (or your favorite X app -- optional.)
• Growl! The display shows nothing on the DVI port (or any other port). It claims that the ports are in power save mode, i.e. no signal. So that was a bust.
• Clearly on both DVI and VGA, the X-server was retrieving the EDID, although fbdev does not print it out like the radeon or nouveau drivers would, suggesting that there never was anything wrong with the cable and adapters. I'm starting to suspect a broken GPU.

This is turning into a time sink. I think I'm not motivated enough to make a real contribution to bringing to life the display on the Pine64. It's not promising that when I booted the Debian image it did not activate the display despite being configured to do so and having a supposedly working, though back-version, driver.

Test Kernel 4.5

I should reinstall kernel 4.5.0, and in the unlikely case that it boots, I should test which hardware actually works, since the last report on that kernel is from 2016-04-xx, 4 months ago. It has the same UEFI configuration that openSUSE-3.10-pine64.raw.xz has, and does not boot.

CouchNet Configuration

I should see how much of my standard configuration I can install on the Pine64 -- probably quite a lot, but not all.

Enterprise Mirror

I'm reluctant to put work into setting up an enterprise mirror if the Pine64 is going to end up useless, but if it's promising then I'm going to be a whole lot happier with the packages on my own machine. But in a rolling distro, how do you keep packages up to date?

Conclusion

From struggling with the Pine64 I have learned a number of points.

Hardware Support Style on ARM

I've seen a number of forum posts, although I concentrated on those specifically relevant to the Pine64. Although ARM CPUs typically reside as a component of a SOC, there are hundreds of designers of such devices, and they combine the CPU with a variety of other subsystems, particularly the graphics processor. Open source graphics drivers are rarely available; one exception is the Broadcom Videocore (VC4) GPU on the Raspberry Pi. The Pine64 uses a Mali 400-MP2 GPU with a proprietary driver.

SOC vendors compete intensely, and are terrified that competitors will steal their software work, and GPU providers have a similar issue at a higher level. Thus closed source is the rule for ARM.

A major disappointment is that I have not been able to put together the desired combination of the operating system (OpenSuSE) and a graphics driver that works. If I continue with the Pine64, or if I get an ARM-based other kind of machine such as a mini-laptop, I will need to stick with the kernel and graphics software (X-Windows) provided by the vendor. For the Pine64 this is seriously back version. As of this writing, the latest Linux kernel is 4.7.1 and the one in OpenSuSE Leap 42.1 (the distro used on most machines on my home net) is 4.1.27, whereas the Allwinner kernel is 3.10.101; the 3.10 series began in 2013-06-xx (3 years ago) and 4.1.x came out in 2015-06-xx (1 year ago). The proprietary GPU driver is also back-version, two X-Windows ABI major versions back.

I'm afraid that it's not acceptable to be stuck in a time warp like that, without security fixes and general bug fixes. Particularly for the proposed mini-laptop.

Quality of the Distro

I looked at OpenSuSE's ARM support, and 90% of the packages in the main distro are also available for ARM. (This excludes non-open source packages and i586 packages.) That's 26351 packages for ARM. This is a pretty good collection. However, there is a problem with the provided images for Pine64: they don't boot. They are organized for UEFI booting, and the Allwinner A64 SOC cannot handle UEFI at all. Weren't they tested? Did nobody report a bug?

UEFI has its pros and cons, which are off topic for this document, but it doesn't look like rocket science to make UEFI work for ARM: use uboot (which is an accessory produced in the kernel build) to load Grub2's stage1 in the EFI partition. Compare with how SuSE does it on Intel boxes: the UEFI BIOS gets control, loads the shim module (which has a signature from Microsoft's key, if Secure Boot is turned on), and the shim then loads Grub2's stage1.

I'm not exactly happy that this relatively simple and important feature of the distro, being able to boot, slipped through the cracks. Bug report here, bug 994496 on SuSE's bugzilla.

The image that I did get to work, from Terra854, is community modified and is hosted on the Pine64 website, not SuSE's site.

Hardware Support

The goal for this project was to use the Pine64 as an audio playback node, with reasonably normal integration into my network. But the sound card doesn't work, which kind of puts a damper on that goal. And I've never seen anything on the display, which prevents a role as a general purpose desktop machine; I also have a low priority need for one of those.

What Do I Do Next?

Unfortunately I have to declare that the Pine64 project has failed, and I have to stop putting effort into a project that's not going to have a result.