manuti

Sure, this is how it should work. Great that now even the RPi folks got it
 
Yesterday I 'unboxed' Orange Pi Lite 2 (Allwinne H6). As small as the H3 Lite but extra thick PCB. After 10 minutes of idle operation the whole PCB including all receptacles is warm so the groundplane efficiently spreads the heat away from the SoC. I put 3 low performing heatsinks on SoC, PMIC and DRAM and reported SoC temperature went down from 49°C in idle to 46°C (after waiting the same 10 minutes or until temperature is stable).
 
So still curious how efficient a 2mm thermal pad between PCB lower side and an aluminium enclosure would work (to transport heat out of an enclosure). To be clear: I'm talking about something like this (and am not willing to spend my own time on such tests any more since done with the low consumption/thermal stuff)
 
Testing such stuff with enclosures that already exist seems impossible. The FLIRC is constructed wrongly and to buy the Wicked you must be mad.

Update to latest armbian, go to armbian-config -> system and change display manager.

Image update Armbian 20180323 kernel 4.14.11 .
Works wired network, USB, monitor (you can change the screen resolution on the fly). The images are in the "test"directory.

Sure. Better results compared to the board lying flat on a pillow
 
Since latest RPi 3+ from last week now also started to copy what those cheap Orange Pi do since years (using the PCB ground plane as massive heatsink) I suggested this test over at RPi forum: https://archive.fo/6kzg0 ... and (not so) surprisingly the post got censored: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=207863&start=225#p1286503 -- they really don't like it over there their users could get the idea that there grows more than Raspberries on this earth 
 
BTW: really impressive how inefficient the old RPi 3 was and is from a thermal point of view:

 
vs.

Try it. I like Arch. They have also images for other boards.

Yes, I use it as headless machine. 
 
Linux odroid-u3 4.15.11-1-ARCH #1 SMP Tue Mar 20 00:23:08 UTC 2018 armv7l GNU/Linux

Yes!!! and now @balbes150 is moving to kernel 4.9.40 
 

@Tido
I've been using Linux desktops on a vast number of physical and virtual systems from enterprise to dinky toys, standardizing on plain Debian and LXDE for robust and stable systems. The LXDE-desktop uses even less ressources than XFCE and is particularly suited for small boards. The choice of desktop ( XFCE ) and Ubuntu bloat are somewhat contrary to the idea of Armbian as a lean and robust distribution. If your seriously interested in Linux desktops opt for the real thing and set up a lightning fast LXDE desktop based on Debian stable. In combination with x2go terminal server you'll experience a vastly superior and universal desktop world.
Enjoy !

No, all TV-box stuff is handled by Balbes150's excellent work.

To run kernel 4.9 successfully, you need
1. New u-boot (it is used in firmware from Android-7).
2. The correct dtb.

Early 2018 update
 
Time for another small update. It's 2018 now and since it seems Armbian will support a couple of RK3399 devices later this year let's have a closer look at the storage performance of them.
 
RK3399 provides 2 individual USB3 ports which seem to share a bandwidth limitation (you get with a fast SSD close to 400MB/s on each USB3 port but with two SSDs accessed in parallel total bandwidth won't exceed 400MB/s). RK3399 also features a PCIe 2.1 implemenation with 4 lanes that should operate at Gen2 link speeds (that's 5GT/s so in total we would talk about 20GT/s if the SoC is able to cope with this high bandwidth). Rockchip changed their latest RK3399 TRM (technical reference manual) last year and downgraded specs from Gen2 to Gen1 (2.5GT/s or 10GT/s with 4 lanes). So there was some doubt whether there's an internal overall bandwidth limitation or something like that (see speculation and links here).
 
Fortunately a Theobroma engineer did a test recently using Theobroma System's RK3399-Q7 with a pretty fast Samsung EVO 960 NVMe SSD: https://irclog.whitequark.org/linux-rockchip/2018-03-14 -- it seems RK3399 is able to deal with storage access at up to 1.6GB/s (yes, GB/s and not MB/s). This is not only important if you want ultra fast NVMe storage (directly attached via PCIe and using a way more modern and efficient protocol like ancient AHCI used by SATA) but also if RK3399 device vendors want to put PCIe attached SATA controllers on their boards. ODROID guys chose to go with an ASM1061 (single lane) on their upcoming N1 since they feared switching to a x2 (dual lane) chip would only increase costs while providing no benefits. But Theobroma's test results are an indication that even x4 attached controllers using all PCIe lanes could make reasonable use of the full PCIe bandwidth of 20GT/s.
 
Below we'll now have a look at USB3/UAS performance and PCIe attached SATA using ASM1061 (both done on an ODROID N1 developer sample some weeks ago). Those tests still use my usual EVO840 SATA SSD so results are comparable. You see two ASM1061 numbers since one is made with active PCIe link state powermanagement and the other without (more or less only affecting access patterns with small block sizes).
 
Then of course beeble's NVMe SSD tests are listed (here fio and there iozone -- numbers should also be valid for the other RK3399 devices where you can access all 4 PCIe lanes via M.2 key M or a normal PCIe slot: Rock960, NanoPC-T4 or RockPro64 (M.2 adapter needed then of course -- ayufan tested and got even better iozone numbers than beeble). And maybe later I'll add SATA and USB3 results from EspressoBin with latest bootloader/kernel.
 
(for an explanation which boards represent which SoC and why please see my last post above)
Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write RPi 2 under-volted 2033/2009 29 / 29 RPi 2 2525/2667 30 / 30 Pine64 (USB2/UAS) 2836/2913 42 / 41 Banana Pi Pro (SATA) 3943/3478 122 / 37 Wandboard Quad (SATA) 4141/5073 100 / 100 ODROID-XU4 (USB3/UAS) 4637/5126 262 / 282 ROCK64 (USB3/UAS) 4619/5972 311 / 297 EspressoBin (SATA) 8493/16202 361 / 402 Clearfog Pro (SATA) 10148/19184 507 / 448 RK3399 (USB3/UAS) 5994/6308 330 / 340 ASM1061 powersave 6010/7900 320 / 325 ASM1061 performance 9820/16230 330 / 330 RK3399-Q7 (NVMe) 11640/36900 1070 / 1150 As we can see RK3399 USB3 performance slightly improved compared to RK3328 (Rock64). It should also be obvious that 'USB SATA' as in this case using USB3/SuperSpeed combined with a great UAS capable USB-to-SATA bridge (JMicron JMS567 or JMS578, ASMedia ASM1153 or ASM1351) is not really that worse compared to either PCIe attached SATA or 'native SATA'. If it's about sequential performance then USB3 even outperforms PCIe attached SATA slightly. The 2 USB3 ports RK3399 provides when combined with great UAS capable bridges are really worth a look to attach storage to.
 
NVMe obviously outperforms all SATA variants. And while combining an ultra fast and somewhat expensive NVMe SSD with a dev board is usually nothing that happens in the wild at least it's important to know how the limitations look like. As we've seen from the RK3399-Q7 tests with fio and larger blocksizes we get close to 1600 MB/s at the application layer which is kinda impressive for devices of this type. Another interesting thing is how NVMe helps with keeping performance up: This is /proc/interrupts after an iozone run bound to the 2 big cores (taskset -c 4-5): https://gist.github.com/kgoger/768e987eca09fdb9c02a85819e704122 -- the IRQ processing happens on the same cores automagically, no more IRQ affinity issues with all interrupts ending up on cpu0  
 
Edit 1: Replaced Pine64 numbers made with EVO750 from last year with fresh ones done with a more recent mainline kernel and my usual EVO840
 
Edit 2: Added Rasperry Pi 2 results from here.
 
Edit 3: Added EspressoBin numbers from here.
 

you could try to create a script which does check the mounts and create a auto-mount in cron every minute if isnt mounted.
take a look here for commands:
https://serverfault.com/questions/50585/whats-the-best-way-to-check-if-a-volume-is-mounted-in-a-bash-script

You don't need a new guide. Motion 4.1.1 isn't available on Armbian, Mr Dave's build is only for Raspbian.
 
On Armbian (i.e. Orange Pi Zero) download new Stretch build 5.38 next, mainline 4.14.14. Do not use Ubuntu.
 
Follow original installation guideline:
https://github.com/ccrisan/motioneye/wiki/Install-On-Debian
(For Debian Stretch)
 
BEFORE point 4 install pip dependencies:
sudo pip install wheel
sudo pip install setuptools
sudo apt-get install zlibc zlib-gst zlib1g-dev
 
Continue to point 4...
... at the end of installation point to [yourip]:8765 and configure it.
 
et voilà! :-)
 
Now Motioneye 0.38 run on motion 4.01.
New motion version is usefull for new cam h264/rtsp based.
 

 
With little OPZ performance is quite respectable:
15fps (streaming) / 10 fps (analisys and capture) with a HD stream 1280x720px, H264 900 kbit/s
12fps (streaming) / 7 fps (analisys and capture) with a HD stream 1280x720px, mjpeg 2,5 mbit/s
Load:  1.94  1.24  0.53
Temp: 70 °C
(without hardware acceleration...)
 
 
Mk

On Which image can I test? Any
 
How? Go to armbian-config -> System -> Nightly and proceed. If this option is not there, defreeze upgrading
 
Restart and after your system is up, proceed to one of those areas:
 
- desktop install from armbian-config on top of CLI (any board)
- set first_run_network configuration, setting ip within /boot/armbian_first_run.txt (any board except Espressobin)
- kernel switching or upgrade (any board, especially Odroid XU4 NEXT) 
- setting fixed/dhcp network with armbian-config (any board except Espressobin)
- configure frame buffer within h3disp utility (any h3 board with a legacy kernel)
- DTS sound on DEV kernel (miqi, Tinkerboard)
- ROCK 64 default kernel
- check effects of changing everything to Network Manager withing firstrun/armhwinfo and other scripty
- check install from a blank image (https://dl.armbian.com/odroidc2/nightly/ and https://dl.armbian.com/orangepiplus2e/nightly/)
- set AP mode (any board)

All changes are reflected in a beta repository and are coming from the build script, branch "development". If you want to build this state, use LIB_TAG="development" while running the script. Make sure you are doing this on sine test install.
 
In case you find a bug:

- report it here
- push a fix to the build script, branch development

Update image kernel 4.9.40 20180315

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

Even if they get h264 decoding working, its going to be a huge win for allwinner community.
Having a working h265 isn't really all that useful to be honest, since the common chips (H3,H5 etc) only support 8 bit decoding, while most media i came across is encoded for 10 bit.
 
h264 media on the other hand is still widely available, so having mainline support would be awesome. Now if someone would get this working under chrome or firefox, that would be a different ballgame

I can't remember all the options, but I think "armbian-config" has a switch to go directly to the Desktop or not.
And "nodm" must be properly configured see: https://wiki.archlinux.org/index.php/Nodm

These are my MXQ https://raspberryparatorpes.net/rivales/rivales-raspberry-pi-mxq-pro-4k-y-mxq-pro-plus/
Related to the performance of the OS, the system go quite well in my MXQ PRO PLUS (2GB RAM) but have micro freezes or hang for 1 second every minute in MXQ PRO (1GB RAM).
I flashed Ubuntu Mate and Debian Server. But the image installed to the eMMC is Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20171226.img.xz
To install in the eMMC I use the option in armbian-config tool. You can launch from Terminal with: 
sudo armbian-config I can't remember where it is exactly in the menu tree. Bear in mind when you choose to Install (install in SATA, NAND or something like this say the option) you lose the Android and the option don't ask for confirmations. 
 
Kind regards.

I have another MXQ Pro Plus 4K and works quite well.
https://raspberryparatorpes.net/rivales/rivales-raspberry-pi-mxq-pro-4k-y-mxq-pro-plus/
I flashed finally Linux in eMMC memory. 
Normally the system must start in graphic mode but asking for an user and password. 
If you want to go straight to the Desktop you must install "nodm" ( sudo apt install nodm ) and maybe remove "lightdm". I don't have any flickering or video issues. 
Regards 

I was confused, my box doesn't have 9082xs it needs ssv6051 drivers which armbian @balbes150 supports
 
after installing all relevant firmware deb files, i see in dmesg
*** sta_cfg_set, /usr/lib/firmware/ssv6051/ssv6051-wifi.cfg *** [ 80.459198] ERROR: filp_open I looked for the file, is in /lib/firmware instead
 
my quick fix
 
ln -s /lib/firmware /usr/lib/firmware now wifi works. Using Armbian_5.41_S9xxx_Debian_stretch_3.14.29_server_20180305.img.xz
 
device: s905w based x96 mini with ssv6051
 

Hello,
First, thanks everybody here for making this possible.
Second, I am a newbie on booting Linux on TV box, so bear with me. Thanks.
My problem:
I have a MXQ Pro+ 4k (2GB RAM - 16GB storage - Android 7.1.2 - 64bit) box and have tried most of the recent images for x905s based TV boxes, following the instructions on the first page of this topic.
I have a semi-workable result using Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_mate_20180203, but still it is not really usable.
I wrote this image to USB 3.0 stick and booted after updating via local update on Android.
After setting user I can only access desktop after typing ctrl+alt+f1 -> login -> startx.
The system doesn't login automatically and I get a lot of screen flickering with messages regarding lightdm and light desktop manager.
What am I doing wrong? How do I get to desktop automatically? Can anyone help, please?
(please ask if I didn't specify all the necessary details)
Thanks.

Hi
I have a device NEXBOX A95X (S905X, 2/16), installed Armbian_5.37_S9xxx_Ubuntu_xenial_3.14.29_server_20171226.img, but I can not configure wifi
I give the commands:
 
 

That's what I've been hearing, especially concerning ddr4.
 
I have a board coming, and a heatsink.  So I can give some comments on the design/etc later on.  My assumption going in is, other than RAM and a few pins, this should be virtually identical to Rock64.  RK805/RK3328/GbE/Same USB setup/eMMC/etc.  The big difference is the RAM.
 

Ayufan’s Armbian on a V88 Piano or V88 Mini III
 
These two TV boxes seem to be electrically identical except that the V88 Mini III has 2 GB RAM and 8 GB ROM whereas the V88 Piano has 4 GB RAM and 16 GB ROM.
They use the same PCB as can be seen from the photos in these FreakTab topics:-
- http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/681869-scishion-v88-piano-tv-box-rk3328-4gb-ram-16gb-rom-android-7-1-usb-3-0-fast-lan
- http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/663248-scishion-v88-mini-iii-tv-box-rk3328-2-8gb-2-4-wifi-fast-lan
 
I do not have a V88 Mini III to test but I believe that my results for the V88 Piano should also be relevant to it.
 
N.B. many sites claim that the V88 Piano has Gigabit Ethernet (1000 Mbps). It does not: it only has Fast Ethernet (100 Mbps) like the V88 Mini III.
 
One nice thing about these TV boxes is that, unlike many others, they will boot easily from a micro-SD card.
Just insert the card and power on
 
My aim was to have Ubuntu running with all version-specific partitions (boot and root) on a USB drive.
I wanted to keep Android in the internal eMMC so that I could dual-boot by just inserting or removing the micro-SD card.
 
I wanted to have the root partition on a USB stick for three reasons:
1) A good USB stick is faster than a micro-SD card.
2) This avoids the system writing repeatedly to the micro-SD card because, if the root partition is on the micro-SD card, after a while it gets corrupted and will no longer boot. This happened to me with both a cheap Ansonchina card and also with a Kingston card. Maybe the write timings in the micro-SD card driver are incorrect.
3) Whilst experimenting on Amlogic boxes I have fried two big micro-SD cards. I have read that others have fried cards on Rockchip boxes. Moving the rootfs to a USB stick enables me to use a smaller and cheaper card.
(I suspect that they were destroyed by over-voltage due to a badly programmed regulator. With a 5 V USB stick and a 5 V PSU there should be no risk as I don’t think the regulators used can step up the voltage.)
 
I also wanted the boot partition to be on the USB stick so that I could have several GNU/Linux distributions on different USB sticks and boot with the same unmodified micro-SD card containing just the boot loaders.
 
I have deliberately avoided the necessity to have a Linux (or even Windows) PC.
 
N.B. the Ubuntu system will not (yet) have working Wi-Fi.
 
You will need:-
- a rooted V88 Piano (mine was sold pre-rooted)
- a micro-SD card: mine was 8 GB but 4 GB should suffice
- a USB Flash Drive: I have used both 32 GB and 8 GB but 4 GB may suffice for a fairly minimal system
- a USB keyboard (and mouse if installing a desktop): I used a wireless mini-keyboard/mouse
- a wired (RJ45) Ethernet connection with DHCP and Internet access
- an HDMI display
 
WARNING: before using a /dev/ or /dev/block device verify that you are using the correct one, using dmesg for instance. Otherwise you could overwrite precious data.
However if you remove all additional USB drives the names below should be correct.
 
The login is rock64 with password rock64 which is also required for sudo.
 
First step – install Ayfan’s Ubuntu Xenial Minimal 0.5.15 on a micro-SD card and prepare 0.6.25 on a USB stick.
 
Boot Android.
 
I installed and used Google Chrome for the following downloads because, with the stock Lightning browser, I couldn’t see when the download had finished.
(The busybox wget can't be used because it doesn’t support https.)
 
Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 in the browser.
Download xenial-minimal-rock64-0.5.15-136-arm64.img.xz
 
If you wish to pass directly to Ubuntu Bionic you could use the Bionic 0.6.25 image instead of Xenial below.
However this may make it more difficult to update U-Boot later as I think a Xenial environment is expected to compile it.
Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.6.25 in the browser.
Download xenial-minimal-rock64-0.6.25-193-arm64.img.xz

Insert the micro-SD card and the USB stick.
N.B. all existing files on both will be destroyed.
You will be asked how to use the USB stick: choose "removable storage" and "cancel" if asked whether to format it.
 
Execute the following actions and commands (in the text following the $ or #).
 
Install and start ConnectBot.
 
Open a local shell.
Become root.
$ su
 
Enter the directory where browsers save downloaded files.
# cd /sdcard/Download
 
Decompress the files.
# busybox xz -d xenial-minimal-rock64-0.5.15-136-arm64.img.xz
# busybox xz -d xenial-minimal-rock64-0.6.25-193-arm64.img.xz
 
Write the 0.6.25 image to the USB stick.
# dd if=xenial-minimal-rock64-0.6.25-193-arm64.img of=/dev/block/sda bs=1048576
 
Write the 0.5.15 image to the micro-SD card.
# dd if=xenial-minimal-rock64-0.5.15-136-arm64.img of=/dev/block/mmcblk1 bs=1048576
 
Ensure everything is written.
# sync
 
Power off the box.

Second step – boot Ayfan’s Ubuntu Xenial Minimal 0.5.15 and prepare the switch to 0.6.25 on the USB stick.
 
Insert the micro-SD card.
Boot and login (rock64/rock64).
 
Become root.
$ sudo -s
 
Remove partitions 6 (boot) and 7 (root) from the micro-SD card so that U-Boot and Linux will use the ones on the USB stick next time.
Luckily this only deletes their entries so Linux can continue to use them until they are unmounted.
Reply "Yes" and "Ignore" to the warnings.
# parted /dev/mmcblk1
rm 6
rm 7
q
 
# poweroff

Third step - boot Ayfan’s Ubuntu Xenial Minimal 0.6.25 from the boot and root partitions on the USB stick and prepare to update to a recent version.
 
Insert the USB stick in the middle USB slot and insert the micro-SD card.
Boot and login.
$ sudo -s
 
This DHCP configuration will be necessary for Bionic.
# cd /etc/network/interfaces.d
# sed s/eth0/eth1/ eth0 > eth1
 
At the time of writing there are only pre-release versions of 0.6.x but Ayufan has promised an official release shortly after the official release of Bionic due on 24th April.
If, in addition to Ubuntu updates,  you want to update to Auyufan's pre-release versions with an added risk of instability then:
# vi /etc/apt/sources.list.d/ayufan-rock64.list
Uncomment the last line
 
# apt update
 
The following lines are necessary if you update to a more recent Ayufan version which will disable eth1:
This is needed to re-enable eth1:
# apt install device-tree-compiler
Make rc.local enable eth1 which is disabled in recent versions and disable eth0 which is not used on the V88 Piano:
# vi /etc/rc.local
Add these two lines just before the last line (exit 0):
enable_dtoverlay eth1 ethernet@ff550000 okay
enable_dtoverlay eth0 ethernet@ff540000 disabled
 
# apt dist-upgrade -y
 
If you want a Mate desktop you can:
# install_desktop.sh mate
 
This gave me an error which I corrected with:
# apt -f install
 
If you wish you can also upgrade from Xenial to Bionic with do-release-upgrade.
 
# reboot
 
You should now be running an up-to-date version with the boot and root partitions on the USB stick.

The next step will be to compile and install a more recent U-Boot supporting the USB 3.0 port correctly.
To be continued...

The procedure above may seem convoluted so here are some additional explanations.
0.5.15 is used for its boot loaders as it is the latest version which will boot directly from a micro-SD card. Unfortunately it does not have working Ethernet and its U-Boot will not load correctly from the USB 3.0 slot.
0.6.25 is used because it has working Ethernet to install device-tree-compiler which is needed to re-enable eth1 on recent versions.