Jump to content

[RFC] Support Cortex-A53/arm64?

tkaiser

By tkaiser
in Armbian build framework

 Share

Recommended Posts

tkaiser

tkaiser

Posted
Posted

Hi,

 

since a Geekbox (Rockchip RK3368) and two Pine64+ (Allwinner A64) are collecting dust and at least for the latter longsleep already prepared a nice image build process that makes including a 'foreign' rootfs quite easy I thought about supporting arm64 also and not just only armhf.

 

But I still lack oversights over our own build process or don't know in which direction other devs will move (I saw zador rearranging stuff the last days) so I thought I better ask first instead of hacking around :)

 

I thought about adding a global variable defaulting to "armhf" and setting it to "arm64" for the new boards in configuration.sh since we later have to call

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
debootstrap --arch=arm64

My goal for now is just being able to spit out an Armbian arm64 rootfs (RELEASE="jessie"/"xenial") I can use with longsleep's image build process to get an idea how far we get with arm64 now (both 3.10.65 and mainline). But I also thought about doing it right from the beginning and stop doing q&d hacks...

 

Any thoughts?

1
zador.blood.stained

zador.blood.stained

Posted
Posted

I think "Right from beginning" way is adding compiler and debootstrap/make arch variables to new board template and adding arm64 tools installation to prepare_host, then it will be easy enough to make necessary adjustments to compilation process.

 

About Xenial release - I will try to add it as soon as it's declared "stable" (end of April, right?).

tkaiser

tkaiser

Posted
  • Author
Posted

Good idea but it seems a bit redundant to me. Why not just using armhf vs. arm64 and setting the different compiler/debootstrap/make arguments later in the build process? I just fear templates might get too complicated and prevent experienced users from adding new boards.

 

On the other hand I also thought about adding the IRQ distribution stuff to the new templates so we can define two variables (one for legacy, the other for vanilla) that contain a list of $processor-1 device names to make the current sun8i hack useable for all boards we support.

 

And then we should take all available templates and create a file armbian-boards.conf that will be copied to /etc into the image containg all the stuff from the templates in a (colon separated?) list like this

$NAME:$STATUS_WIP:$DESCRIPTION: ...

If we then take care that $NAME in the template matches $ID in armhwinfo (after a small transformation) then we've already everything set up to 

  • warn (through motd) that the OS image is preliminary ($STATUS_WIP)
  • distribute IRQs in a sane and consistent way (and let the user adjust this to his own needs by editing /etc/armbian-boards.conf)
  • do some sort of mismatch detection between board and config used
tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/28/2016 at 11:58 AM, zador.blood.stained said:

About Xenial release - I will try to add it as soon as it's declared "stable" (end of April, right?).

 

I just tried to switch to Xenial the brute-force way:

grep -i -r trusty * 2>/dev/null | awk -F":" '{print $1}' | sort | uniq | while read ; do sed -i -e 's/trusty/xenial/' -e 's/Trusty/Xenial/' -e 's/Tahr\ 14/Xerus 16/' "${REPLY}"; done

Can't work of course now:

Failed to fetch http://apt.armbian.com/dists/xenial/main/binary-armhf/Packages".

Ok, adding arm64 is a bit more work than I thought ;)

tkaiser

tkaiser

Posted
  • Author
Posted

Success!

 

macbookpro-tk:~ tk$ slogin 192.168.83.88

tk@192.168.83.88's password: 

 ____  _             __   _  _         

|  _ \(_)_ __   ___ / /_ | || |    _   

| |_) | | '_ \ / _ \ '_ \| || |_ _| |_

|  __/| | | | |  __/ (_) |__   _|_   _|

|_|   |_|_| |_|\___|\___/   |_|   |_|

                                       

 

Welcome to ARMBIAN Ubuntu 16.04 3.10.65+ 

 

System load:   0.08            Up time:       2 min

IP:            192.168.83.88

CPU temp:      30°C           

Usage of /:    16% of 3.5G   

 

Last login: Mon Feb 29 12:03:04 2016 from 192.168.83.91

 

tk@pine64plus:~$ uname -a

Linux pine64plus 3.10.65+ #31 SMP PREEMPT Sun Feb 28 18:55:54 CET 2016 aarch64 aarch64 aarch64 GNU/Linux

tk@pine64plus:~$

 

Just kidding, I only used longsleep's Xenial OS image for Pine64 to get a clue what to expect when switching to Xenial (for example packages missing, eg. figlet/toilet) and arm64 in general. I believe it's good to 'just have a look' now before starting to adjust our new templates :)

 

BTW: I used 'sysbench' the last 2 years to roughly compare performance of ARMv7 boards. Not possible any longer when running on ARMv8 with software compiled for ARMv8:

 

tk@pine64plus:~$ sysbench --test=cpu run --num-threads=4

sysbench 0.4.12:  multi-threaded system evaluation benchmark

 

Running the test with following options:

Number of threads: 4

 

Doing CPU performance benchmark

 

Threads started!

Done.

 

Maximum prime number checked in CPU test: 10000

 

 

Test execution summary:

    total time:                          3.2562s

    total number of events:              10000

    total time taken by event execution: 12.9950

    per-request statistics:

         min:                                  1.21ms

         avg:                                  1.30ms

         max:                                 13.14ms

         approx.  95 percentile:               1.30ms

 

Threads fairness:

    events (avg/stddev):           2500.0000/10.70

    execution time (avg/stddev):   3.2487/0.00

 

(the Raspberry Foundation uses the very same silly benchmark and published today benchmark results for the yet available RPi 3: also ARMv8 based but not that impressive: 49.02 seconds that's just 15 times slower than A64! Maybe they get the idea why it would make sense to make use of Aarch64/ARMv8 architecture and not let code for ARMv6 run on ARMv8 cores in ARMv7 mode ;) )

 

And running these sorts of benchmarks only for a few seconds like above is pretty useless since thermal throttling should also be considered (this happens when sysbench runs for a few minutes and the A64 wears already a heatsink):

 

Bildschirmfoto%202016-02-29%20um%2013.25

 

(I made an RPi-Monitor template for A64 already available). Even with this light workload already throttling occurs and CPU frequency will be reduced. And then I tried to run ssvb's new Cortex-A53 cpuburn version but the Pine64+ immediately deadlocked. Seems I have to buy the new 2.5A PSU for RPi 3 to compensate the crappy Micro USB DC-IN connector also used on the Pine boards.

2
tkaiser

tkaiser

Posted
  • Author
Posted

Just a small note. To prepare the arm64 switch (GCC 5.2 toolchain strongly recommended) I tried to build OS images using gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf (I simply did an untar below /usr/local and exported PATH=/usr/local/gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf/bin:$PATH prior to calling compile.sh and then tried out the most crappy kernel tree we currently support. Works as expected:

Linux version 3.4.110-sun8i (tk@opennms) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-1) ) #86 SMP PREEMPT Mon Feb 29 20:23:08 CET 2016

 

  Reveal hidden contents

 

 

Therefore I would suggest to do the same with all images (kernel debs), put them somewhere on mirror.igorpecovnik.com and ask experienced users to try them out. If this works we could integrate the 5.2 Linaro toolchain in our build system to also prevent strange effects when people try to build from source on systems where exotic cross-compile toolchains are present.

 

Any thoughts?

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/1/2016 at 7:13 AM, Avinash Ga said:

Wondeful. Soon i will be getting my pine64 boards. I am eager to try armbian supported image on it.

 

Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users :)

 

BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.

4
tkaiser

tkaiser

Posted
  • Author
Posted
  On 3/29/2016 at 5:07 AM, wildcat_paris said:

 

This is just building the BSP kernel which is an easy task. The other parts are more problematic. Something that works quite good is longsleep's attempt to build a whole image (Uli is using his kernel tree): https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess

 

Allwinner's BSP u-boot can not be built with GCC 5.x (32-bit mandatory, GCC 4.8 recommended) but the kernel has to be built with 5.2 (aarch64) or above so this is another change we have to make to Armbian's build system (and not really decided how yet).

 

I would also wait for mainline u-boot being fully ready. Both mainline u-boot and kernel already boot but there's a problem with missing DRAM initlialisation code preventing any Armbian build being redistributable now. Allwinner said a few weeks ago they're thinking about releasing this code with a GPLv2 license but AFAIK the developers are still waiting for an answer.

 

And then there remains the question how to deal with Allwinner's BSP (AKA 'legacy kernel'). Longsleep summarized it here perfectly.

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/29/2016 at 12:33 PM, tkaiser said:

tk@pine64plus:~$ sysbench --test=cpu run --num-threads=4

sysbench 0.4.12:  multi-threaded system evaluation benchmark

 

Running the test with following options:

Number of threads: 4

 

Doing CPU performance benchmark

 

Threads started!

Done.

 

Maximum prime number checked in CPU test: 10000

 

 

Test execution summary:

    total time:                          3.2562s

    total number of events:              10000

    total time taken by event execution: 12.9950

    per-request statistics:

         min:                                  1.21ms

         avg:                                  1.30ms

         max:                                 13.14ms

         approx.  95 percentile:               1.30ms

 

Threads fairness:

    events (avg/stddev):           2500.0000/10.70

    execution time (avg/stddev):   3.2487/0.00

 

Just a funny note: SinoVoip announced yesterday an own A64 board: BPi M64. They took kernel/u-boot/device-tree settings from longsleep/linux-sunxi community and prepared their most recent OS images already for BPi M64 (providing the necessary stuff on the FAT partition and being able to overwrite the bootloader with their bpi-bootsel command).

 

Since at the moment they didn't alter anything regarding device-tree stuff (it's all 100 percent copy&paste from Pine64+) I simply tried it out and tested their so called 'Raspbian Lite' OS image on Pine64+ (boot log):

root@bpi-iot-ros-ai:/tmp# sysbench --test=cpu --cpu-max-prime=10000 run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          52.2640s
    total number of events:              10000
    total time taken by event execution: 208.9829
    per-request statistics:
         min:                                 18.97ms
         avg:                                 20.90ms
         max:                                 61.86ms
         approx.  95 percentile:              21.83ms

Threads fairness:
    events (avg/stddev):           2500.0000/5.05
    execution time (avg/stddev):   52.2457/0.01

root@bpi-iot-ros-ai:/tmp# bpi-hw 
bpi-m64

root@bpi-iot-ros-ai:/tmp# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Same hardware. Using a good OS image (making use of ARMv8 instruction set) the benchmark takes 3.2 seconds, 'Team BPi' manages to provide an OS image where the same benchmark takes 16 times longer: 52 seconds (Armbian running on an Orange Pi Plus 2E takes less than 40 seconds). Then rootfs is nearly full, u-boot and kernel are already outdated and of course kernel update doesn't work since 'Team BPi' was so clever to read the necessary files from an unusual location and so on... So you already know what to expect when you have to rely on their software/support :)

2
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept