manuti

Armbian images for R69 on Google Drive.

Thanks for the TV Box link.
But where I can find the image you loaded?
Thanks again.

Login as root and run:
apt install armbian-firmware-full or manually it that won't work - check this: http://mitchtech.net/realtek-wireless-dongle-rt3070-on-the-raspberry-pi/
 
Remember to reboot or reload the module.

The first stretch goal is reached (that was the 'try to cover not only horribly outdated SoCs from half a decade ago but also some of the just outdated ones'). Two stretch goals are yet open and they estimate the same amount of work/money needed (another 22 man days or 22,000€ in total)

Founded. I like to bet for death horses!
And the First additional stretch goal is reached 22.943 € Monday, February 5.

Hi,
 
I have received my SCISHION V88 Piano and I can confirm that it boots to a Ubuntu Mate desktop from a micro SD-card with the image in the first post of this topic.
Like rob0809 I did nothing except insert the micro SD-card and power on
Unfortunately after running for a few minutes there were some I/O errors which I must investigate but this is perhaps due to my cheap (Ansonchina) SD-card.
 
I shall try other images and report back later.
 
Updates:
I tried this image:
https://github.com/ayufan-rock64/linux-build/releases/download/0.5.15/xenial-mate-rock64-0.5.15-136-arm64.img.xz
and it also booted directly but still with I/O errors.
I replaced the Ansonchina 8GB SD-card with a Kingston 8GB one and there were no more I/O errors
 
I tried the following images which also booted directly from the Kingston SD-card with no intervention:
http://dietpi.com/downloads/images/DietPi_Rock64-ARMv8-Stretch.7z
https://github.com/Raybuntu/LibreELEC.tv/releases/download/rb-leia23/LibreELEC-rock64.arm-rb-leia23.img.gz
https://github.com/ayufan-rock64/linux-build/releases/download/0.5.15/xenial-i3-rock64-0.5.15-136-arm64.img.xz
 
Most of these images require an external USB Ethernet adapter (internal Ethernet and WiFi don't seem to be supported).
They also run much more slowly than I had expected. Unfortunately I don't think that this is just due to a lack of hardware graphics acceleration  
But this is just a start and at least they do run
 
Later update:
I found an easy hack to greatly speed up simple operations not involving heavy video or graphics.
(Due to the lack of hardware acceleration, YouTube videos, for example, still play frame by frame.)
I copied exactly the same disk image to both a micro SD-card and to a USB 3.0 storage device.
I modified the label on the root partition of the SD-card so that it would use the USB disk as the rootfs instead.
On most of these images the rootfs is labelled linux-root on partition 7.
I used gparted to change the SD-card's partition 7 label to linux-rootX so that it would pick up the partition on the USB drive instead.
 
I also used parted to correct for the size of both the devices and to increase the size of the root partition on the USB drive. However this is not strictly necessary.
As a stability test and a realistic benchmark, I compiled natively the recent mainline v4.15 Linux kernel: "make defconfig && make -j 4 Image" finished successfully in slightly under 100 minutes.
This is not too bad for a box costing about $40.
 
Even later update:
The best Ubuntu image that I have found is this one:
https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z
This currently redirects to:
https://dl.armbian.com/rock64/nightly/Armbian_5.34.171121_Rock64_Ubuntu_xenial_default_4.4.77.7z
There is only one single partition so I had to:
'- copy the image to a USB storage device
- resize the partition
- add the label linux-root
- copy the appropriate files from the boot directory of this partition to replace the dtb, Image and initrd.img files on the boot partition of the SD-card I used previously
- ensure that there is no partition labeled linux-root on the SD-card
- after booting I installed ubuntu-mate-desktop but this is obviously not mandatory
The advantages of this image are:
- it will find the linux-root partition even if the USB storage device is on a hub (otherwise the USB drive monopolizes the USB 3.0 port)
- YouTube video (nearly) works so there must be some hardware acceleration
Unfortunately the video freezes from time to time. This doesn't seem to be due to a slow Internet connection.
With this image the compilation time for the same kernel dropped to 72 minutes.
 
I also tried this image but it did not seem to boot (at least there was only a blank screen on HDMI).
https://github.com/ayufan-rock64/linux-build/releases/download/0.6.19/bionic-minimal-rock64-0.6.19-181-arm64.img.xz
Maybe it is headless so I shall try again to ssh into it.
(Or to login via a serial console but I have not yet needed to open the case.)
 
Cheers,
Chris

Free Electrons is changing to a new name, in the context of a trademark dispute.
 
The weird thing about this campaign - you support ALLWINNER, while ALLWINNER actually should pay Bootlin to do this for them.
Especially people using OSMC  OpenELEC  LibreELEC  Kodi - should be strong supporter of this Kickstarter ... unless you use a different SoC.
 

I believe that the various PI boards do choose a random MAC address most / all of the time.
If it helps you can specify a MAC address in the /etc/interfaces file 
 
Something like this should do it:
 
# Network interfaces allow-hotplug eth0 iface eth0 inet dhcp hwaddress ether 08:00:00:00:00:01  

Hmm... to summarize the 'OpenSSL 1.0.2g  1 Mar 2016' results for the 3 boards/SoC tested above with some more numbers added (on all A53 cores with crypto extensions enabled performance is directly proportional to CPU clockspeeds -- nice):
ODROID N1 / RK3399 A72 @ 2.0GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 377879.56k 864100.25k 1267985.24k 1412154.03k 1489756.16k aes-192-cbc 325844.85k 793977.30k 1063641.34k 1242280.28k 1312189.10k aes-256-cbc 270982.47k 721167.51k 992207.02k 1079193.94k 1122691.75k ODROID N1 / RK3399 A53 @ 1.5GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 103350.94k 326209.49k 683714.13k 979303.08k 1118808.75k aes-192-cbc 98758.18k 291794.65k 565252.01k 759266.99k 843298.13k aes-256-cbc 96390.77k 273654.98k 495746.99k 638750.04k 696857.94k MacchiatoBin / ARMADA 8040 @ 1.3GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 360791.31k 684250.01k 885927.34k 943325.18k 977362.94k aes-192-cbc 133711.13k 382607.98k 685033.56k 786573.31k 854780.59k aes-256-cbc 314631.74k 553833.58k 683859.97k 719003.99k 738915.67k Orange Pi One Plus / H6 @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 226657.97k 606014.83k 1013054.98k 1259576.66k 1355773.27k aes-192-cbc 211655.34k 517779.82k 809443.75k 963041.96k 1019251.37k aes-256-cbc 202708.41k 470698.97k 692581.21k 802039.13k 840761.34k NanoPi Fire3 / Nexell S5P6818 @ 1400 MHz (4.14.40 64-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 96454.85k 303549.92k 637307.56k 909027.59k 1041484.46k aes-192-cbc 91930.59k 274220.78k 527673.43k 705704.40k 785708.37k aes-256-cbc 89652.23k 254797.65k 460436.75k 594723.84k 648388.61k ROCK64 / Rockchip RK3328 @ 1296 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k PineBook / Allwinner A64 @ 1152 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 144995.37k 387488.51k 648090.20k 805775.36k 867464.53k aes-192-cbc 135053.95k 332235.56k 516605.95k 609853.78k 650671.45k aes-256-cbc 129690.99k 300415.98k 443108.44k 513158.49k 537903.10k Espressobin / Marvell Armada 3720 @ 1000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k OPi PC2 / Allwinner H5 @ 816 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz and MTK Crypto Engine active type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 519.15k 1784.13k 6315.78k 25199.27k 124499.22k aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k MiQi / RK3288 @ 2000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 87295.72k 94739.03k 98363.39k 99325.95k 99562.84k ODROID-HC1 / Samsung Exynos 5244 @ (A15 core @ 2000 MHz): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 78690.05k 89287.85k 94056.79k 95104.34k 95638.87k aes-192-cbc 69102.10k 77545.47k 81156.61k 81964.71k 82351.45k aes-256-cbc 61715.85k 68172.80k 71120.73k 71710.72k 72040.45k ODROID-C2 / Amlogic S905 @ 1752 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k NanoPi M3 / Nexell S5P6818 @ 1400 MHz (3.4.39 32-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 44264.22k 54627.49k 58849.88k 59756.35k 60257.62k aes-192-cbc 39559.11k 47999.32k 51095.30k 51736.15k 52158.46k aes-256-cbc 35803.41k 42665.24k 44926.47k 45733.21k 45883.39k Clearfog Pro / Marvell Armada 38x @ 1600 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 47352.87k 54746.43k 57855.57k 58686.12k 58938.71k aes-192-cbc 41516.52k 47126.91k 49317.55k 49932.63k 50151.42k aes-256-cbc 36960.26k 41269.63k 43042.65k 43512.15k 43649.71k Raspberry Pi 3 / BCM2837 @ 1200 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 31186.04k 47189.70k 52744.87k 54331.73k 54799.02k aes-192-cbc 30170.93k 40512.11k 44541.35k 45672.11k 45992.62k aes-256-cbc 27073.50k 35401.37k 38504.70k 39369.39k 39616.51k Banana Pi M3 / Allwinner A83T @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 36122.38k 43447.94k 45895.34k 46459.56k 46713.51k aes-192-cbc 32000.05k 37428.74k 39234.30k 39661.91k 39718.95k aes-256-cbc 28803.39k 33167.72k 34550.53k 34877.10k 35042.65k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k Edit: Added results for Pinebook and ODROID-HC1 ensuring both were running at max cpufreq
 
Edit 2: Added cpufreq settings for each tested device. Please note throttling dependencies and multi-threaded results below
 
Edit 3: Added Banana Pi M3 single thread performance above. Performance with 8 threads sucks since A83T throttles down to 1.2GHz within 10 minutes and overall AES253 score is below 190000k.
 
Edit 4: Added EspressoBin numbers from here. Another nice example for the efficiency of ARMv8 crypto extensions.
 
Edit 5: Added NanoPi M3 numbers from there.
 
Edit 6: Added Clearfog Pro numbers (Cortex-A9 -- unfortunately OpenSSL currently doesn't make use of CESA crypto engine otherwise numbers would be 3 to 4 times higher)
 
Edit 7: Added Banana Pi R2 numbers from here (Cortex-A7, cpufreq scaling broken since ever so SoC only running with 1040 MHz, numbers might slightly improve once MTK manages to fix cpufreq scaling)
 
Edit 8: Added numbers for ARMADA8040 (A72) from CNX comment thread.
 
Edit 9: Added RK3288 (Cortex A17) numbers from here.
 
Edit 10: Added RPI 3 (BCM2837) numbers. Please be aware that these are not Raspbian numbers but made with 64-bit kernel and Debian arm64 userland. When using Raspbian you get lower numbers!
 
Edit 11: Added Allwinner H6 numers from here.
 
Edit 12: Added RK3399 numbers from here.
 
Edit 13: Added new S5P6818 numbers since now with mainline 64-bit kernel ARMv8 crypto extensions are available

No, there are a lot more but all of this doesn't really matter especially here in this forum. And the whole issue (people using this crappy tool called sysbench trying to benchmark hardware) is not even related to 32-bit vs. 64-bit but different compiler switches. Raspbian packages are built for the ARMv6 ISA so they can be executed on the horribly outdated single core RPis as well. Normal Debian/Ubuntu armhf packages are built for ARMv7 and you would need to switch to arm64 packages since only these packages are built with support for ARMv8 CPU cores (that's what's inside RPI 3 and 2 in the meantime).
 
So comparing an OPi Win running an arm64 Ubuntu or Debian distro with an RPi 3 running any recent Arch, Gentoo, Fedora, OpenSuSE or even an arm64 Armbian (see my link -- I did this) you will see sysbench numbers that are pretty close. Numbers between the different distros will vary since the distro packages are built with different compiler versions and switches. And this is all the lousy sysbench tool in 'cpu test' mode is able to report since this whole test is just calculating prime numbers inside the CPU caches (and as soon as an ARMv8 CPU is allowed to run ARMv8 code this gets magnitudes faster). I don't know of a single real-world use case that would correlate with this pseudo benchmark (except of course if your job is calculating prime numbers, then you can rely on sysbench and if you're running on a RPi 3 should better stay away from Raspbian, DietPi and the other ARMv6 dinosaurs)
 
But while sysbench is wrongly reporting an RPi 3 (or an OPi Win if you choose Xunlong's Raspbian images!) would be magnitudes slower than any of the recent ARMv8 boards with one specific workload the RPi 3 is really magnitudes slower (AES encryption -- think about VPN and disk encryption). Broadcom forgot to license ARMv8 crypto extensions so any other 64-bit (ARMv8) SBC is a better choice than RPi 3 if it's about AES (except ODROID-C2 and NanoPi K2 since their Amlogic S905 suffers from the same problem). See the numbers here: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 (OPi Win scores the same as Pinebook)
 

Image update 20180204 kernel 3.14.29 and 4.9.40. Added version of the images with mali-6 (Ubuntu Mate and Debian XFCE). In these images uses a new library libMali r6p3. These images are in the directory mali-6 on the website. In the directory mali-5 are all old images 20180203 (server and desktop variants). Added to the website version of the images with the kernel 4.9.40 a working version of KODI. Pay attention to the images 20180204 c kernel 4.9.40 Mate and XFCE desktops contain a version of KODI 17.3, which can work on models with S905X. Important. The image with the kernel 4.9.40 to run KODI, you need to log on desktop (which would have been on MATE or XFCE) and from it (via the menu) to launch KODI. Only in this mode will work the sound in KODI. When you exit KODI the screen will remain blank (black), for the appearance of the desktop you need to switch to another console with CTRL+ALT+F1 and go back to your desktop CTRL+ALT+F7.

search the docker registry for armhf   then youll find ubuntu and alpine containers to base your builds on.     ioft/armhf-ubuntu:xenial  is one i use a lot

A little surprise to Chinese New Year holiday. Image update 20180203.

IMHO, if you are not familiar it might be a bad idea to overclock your H3 CPU... It depends on kernel and board (voltageregulation is solved in two ways on H3). Is it just to see what's possible or do you want to get the max. power out of it? If the second is the case, I think you waste your time. This might be a good starting point for you.
http://linux-sunxi.org/Cpufreq

I can confirm using gxm_q201_2g.dtb and it boots fine.

@balbes150
Hi again.
I manage to have everything working in my bootstrapped USB ROOTFS except:
Video resolution shows only part of the image.
xorg log says 1920x1080 virtual size
glxgears gives ~250.000 FPS
glxinfo says "direct rendering yes"
Any tips on how to solve this, or what am i doing wrong?
All packages i have installed came from debian stretch arm64 official repositories (no backports though),
and some packages from your debs in yandex deb directory (kernel and firmwares).
No packages at all from armbian repos are installed (maybe i'm missing something from there?)
If this resolution problem gets solved i'll start tweaking IceWM to the last detail,
and then i'll start creating an auto-build script according to the notes i have taken so far.
Thanks.

OK, solved this by using FriendlyElec's dtb! Armbian folks may want to use this DTB instead of what's in the current distro. lsusb show thumb drive:
 
Bus 001 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive

You might better try to educate yourself about what really happened. Bananas and Oranges are Cubieboard descendants which itself is in a line with Mele A1000 (or more in general: Allwinner A10/A20 based Android devices that were popular in China and were exported later by Tom Cubie which kickstarted more or less linux-sunxi community, Cubietech and sites like CNX). These origins on A10/A20 happened in 2012 when RPi software support was still very limited. Below one rackmounted Mele A2000 cluster (real Ethernet and real SATA combined with SSDs made the difference to toys):
 


 
Even the power plug used on Bananas and Oranges is inherited from those first Mele TV boxes!
 
At the time RPi was in early development Beagleboard was already there, ODROIDs were already there and in China they had something similar to RPi already years before (QQ2440 and Mini2440 are FriendlyARM products, yes the company now selling NanoPis since Westerners are that stupid that they only can accept a good SBC design if it has Pi in its name)
 
When speaking about RPi it's more or less about Western perception and of course marketing (that's where the RPi Foundation really excels)

HC2 is now officially available: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472 (see especially mechanical incompatibility note for few 3.5" HDD at the bottom)

https://yadi.sk/d/e4krIyQW3RW89c

Good to know. I just wanted to upgrade my beelink x2 to the latest version - but when it's like this I'd rather wait a little

Uploaded the site to the directory Armbian a test version of the Ubuntu image Mate 20180116 with the new version of the kernel 3.14.29. In this manner significantly extended the list of dtb files.
Request to all, to try to run this image with different dtb files (including groups on the model of your TV box). If this kernel will work fine, I will upload the remaining images (Ubuntu\Debian server\DE).

I've been using a Beelink X2 with Armbian for some time now booting from eMMC.   I ran an "apt update; apt upgrade" on the box early on 01/14/2018 and a reboot was suggested at the end.  The system did not successfully reboot after this update and it appears that it doesn't recognize uboot on the eMMC.   At the time I had other pressing matters so I set it aside to work on today.   Today I downloaded the latest image Armbian_5.34.171121_BeelinkX2_Debian_stretch_next_4.13.14_desktop.img, verified it and successfully wrote the image to a 16GB microSD card.  This successfully booted the X2, I then did an "apt update; apt upgrade" on the microSD card and rebooted.  This then resulted in an un-bootable SD card!   Something in the latest update is causing an issue with uboot on the X2.  I'm now rewriting the original image to the microSD and will attempt to determine what update is causing the issue!

RPI is married to Broadcom because that's where their engineers used to work. They cobbled together their SBCs from older, inexpensive parts to be able to hit their "amazing" price points. The Broadcom SoCs were designed for set top boxes and are not necessarily the best for Linux SBCs due to their long list of limitations (e.g. slow USB, slow+old ARM cores, slow+limited RAM). For me, the worst offender is the Raspberry Pi 0. It's 11 year old technology (armv6) released with a "teaser" price that was never meant to succeed as an actual product. The other end of the spectrum for offensive Linux SBC board vendors is Qualcomm. They tease out their overpriced chips in a watered down board with odd and half-working (e.g. GPS) parts to get their feet into "this IoT market thing". The Chinese chip vendors are the only ones who are willing to put their best chips (e.g. RK3399) onto publicly available boards running Linux. I have a feeling that this is more of a "try anything to conquer all markets" than a real understanding or effort to help the IoT community.

Information in this topic is very outdated see this topic.