Jump to content

Armbian on MiQi SBC hardware ?

Peba

By Peba
in Rockchip

 Share

Recommended Posts

Igor

Igor

Posted
Posted

Yes, if you can do the job of bringing the device into the build system. Since this is a new chip for us, it could not be plain simple. In general we don't have much / (me) any experiences with Rockchip and at least one of us would need to get this device, since porting and supporting without a hardware is no go ... except cloned boards. The chip is powerful / interesting but for the rest I would need to check closely. At least powering with micro USB is not a good idea and I hope there is an  alternative way.

1
tkaiser

tkaiser

Posted
Posted
  On 9/17/2016 at 6:00 AM, Igor said:

At least powering with micro USB is not a good idea and I hope there is an  alternative way.

 

There is the fan header, Zador found that out by looking at schematic: http://forum.armbian.com/index.php/topic/1095-miqi-is-a-35-single-board-computer-with-rockchip-rk3288/?p=8338

 

I'm pretty impressed by the performance (and possible tweaks, see at the bottom of this page) but believe it would be necessary to come up with a fully blown desktop Armbian image since here the board seems to perform pretty well (GPU and video acceleration). For headless use cases the lack of IO bandwidth could be a problem. Anyway, I would appreciate if Peter starts with that and would assume Benn Huang could be asked to send out a few more developer samples.

2
Peba

Peba

Posted
  • Author
Posted

There is already a complete build environment based on work done by Linaro(RFS) and Rockchip(kernel).

I am not sure if it makes sense to re-invent the wheel ?

http://www.bitkistl.com/2016/09/the-rockchip-toolbox.html

 

Last week we got some performance patches from Willy Tarreau (you know - the cluster guy, build farm)

With that It was possible to run Kodi, smplayer and some webGL demo at the same time, I just used some of the patches (e.g.set cpu throttling to 80+)

http://1wt.eu/miqi/
https://forum.mqmaker.com/t/miqi-based-build-farm-finally-up-and-running/605/1

Demo Video:

https://youtu.be/DnHJckoxGJU

 

VPU acceleration for Kodi 17 is still WIP, Jacob Chen and Marc aka Mac_l1 started on that.

Kernel 4.10+ is available from another guy.
https://forum.mqmaker.com/t/mainline-kernel-compilation/572
https://github.com/Miouyouyou/MyyQi

 

Anyway I will ask Benn about your proposal for some MiQis :-)

 

Thank You,

Peter

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 1/21/2017 at 3:57 PM, Peba said:

There is already a complete build environment based on work done by Linaro(RFS) and Rockchip(kernel).

I am not sure if it makes sense to re-invent the wheel ?

http://www.bitkistl.com/2016/09/the-rockchip-toolbox.html

Well, Armbian (as a build system) is not about reinventing the wheel, but is about supporting a large number of boards and platforms with as little board/platform specific tweaks as possible while compiling from sources as much as possible. If adding a new board/platform requires changes to the build script, there needs to be a good reason to do this.

And providing official images for the new platform requires enough hardware samples for the team - some polishing always requires access to the hardware if you don't want to spend weeks instead of hours if relying on somebody else to do the live testing.

1
Igor

Igor

Posted
Posted
  Quote

I am not sure if it makes sense to re-invent the wheel ?

http://www.bitkistl....ip-toolbox.html

 

Main added value of our build system is bringing down the complexity. We could also say: what's written on that page and scattered around various external links (and which require advanced knowledge to understand) is with Armbian summed under one command.

1
jernej

jernej

Posted
Posted
  On 1/23/2017 at 10:07 PM, manuti said:

Any chance to have Asus Tinker Board support as spin-off of MiQi armbian?

 

Once SoC is supported, adding new boards should be easy. But first, please wait until RK3288 is supported in Armbian.

1
Da Alchemist

Da Alchemist

Posted
Posted
  On 1/23/2017 at 10:22 PM, jernej said:

Once SoC is supported, adding new boards should be easy. But first, please wait until RK3288 is supported in Armbian.

 

I wonder if the work is necessary because this Board is not  really available. The RK is well supported by Linux and SBCs with Rockchip are the more expansiv ones...

 

But in the End Armbian is a non Profit Thing, so supporting Boards is not depending on econnomic Reasons. :)

Igor

Igor

Posted
Posted

MiQi added to Armbian. What I did:

 

- added kernel 4.4.50 ... took from https://github.com/mqmaker/linux-rockchip(4.4.16) ... and patch all the way up to 4.4.50. 

- added stock MiQi uboot. I tried too merge it with mainline but figured out soon that it's not going to be easy and abandoned that

- added boot scripts with environment file

- packaged kernel, u-boot, ...

- updated kernel config to meet Docker requirements 

- added proper serial console

- tested CLI and desktop build. Both runs smoothly.

Known bugs: random MAC, eMMC install script and boot script need some adjustments

 

Unknown: mali, video accleration librarires, ... etc. most likely those should go: https://github.com/mqmaker/rk-rootfs-build

 

From tomorrow morning, betas will be available here: https://dl.armbian.com/miqi/nightly/

 

armbianmonitor -u
http://sprunge.us/TWMF

Console log:

 

  Reveal hidden contents

 

4
Igor

Igor

Posted
Posted
- fixed eMMC install,
- added development kernel (4.10.x) with MALI driver (untested)
 

Onboard 16GB eMMC media performances - not the top performer but still very decent.

root@miqi: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

        File stride size set to 17 * record size.
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     2403     2503    12483    12840    10950     2400
          102400      16     8277     8682    26678    26378    24787     8526
          102400     512    26729    27105    40906    40921    40702    27001
          102400    1024    27644    27575    41840    41808    41731    27562
          102400   16384    28077    28056    43618    43609    43589    28147
2
tkaiser

tkaiser

Posted
Posted
  On 2/21/2017 at 1:03 PM, Igor said:

Onboard 16GB eMMC media performances - not the top performer but still very decent.

 

Great work, thanks! As a reference eMMC performance numbers done by Jean-Luc months ago:

                                                            random  random
              KB  reclen   write rewrite    read    reread    read   write
          102400       4    3836    3989    13389    13370   10816    3727
          102400      16   14491   14452    28656    27941   25246   13844
          102400     512   30696   30482    50109    50102   49613   30575
          102400    1024   30844   30666    51191    51202   50959   30466
          102400   16384   32673   33962    55222    55213   55158   33856

So maybe it's a different IC now or there's something 'wrong' with settings. Anyway: I hope Peter jumps in and throws some patches at us (those mentioned above from Willy Tarreau and maybe others to get VPU support and so on) 

Igor

Igor

Posted
Posted

Next test was done with mainline kernel 4.10.0 and performance CPU governor, while the one before was done on 4.4.50 with powersave.

                                                              random    random 
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     2527     2558    13977    14042    11684     2457
          102400      16     8800     8918    28143    28229    26319     8692
          102400     512    27341    27273    42205    42257    42042    27342
          102400    1024    27834    28148    42597    42648    42559    27925
          102400   16384    28056    28484    45067    45142    45128    28636

I guess those eMMC chips are simply different, yes.

1
Myy

Myy

Posted
Posted

Greetings everyone !

 

Concerning the eMMC, note that one of the patches applied to kernel 4.10.0 just mute the eMMC driver, in order to avoid it spamming the logs with

mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)

Discussion about the original patch (not the adaptation) can be found here : http://lists.infradead.org/pipermail/linux-rockchip/2017-January/013621.html

Still, if anyone with DTS knowledge could analyse the DTS files and see if the eMMC drivers are not misconfigured, that would be nice.

 

Also, you could see if trimming affect performances by running fstrim before.

Igor

Igor

Posted
Posted

@Myy

Welcome and thanks for update. At least we have something on the bug list now :)

 

@tkaiser

 

I had no luck ... I started with Ubuntu Xenial and ... lot's of dependencies did not met and at the end Kodi crashed :(

mdel

mdel

Posted
Posted

nice a "new" soc to play with.

 

could someone post the result of :

openssl speed -elapsed -evp bf-cbc aes-128-cbc

 

also i see on cnx rk3288 specs, the following :

 

  • Standalone crypto and decrypto, compatible with AES 128bits/DES/3DES/SHA-1/SHA-256/MD5/160bits PRNG

found some /lib/modules/../kernel/arch/arm/crypto/ modules on the git link posted above.

any trace of crypto engines in armbian's legacy kernel ?

 

maybe some more info in /proc/crypto

 

thx.

Igor

Igor

Posted
Posted

ARMBIAN 5.26 stable Ubuntu 16.04.2 LTS 4.4.51-rockchip  

openssl speed -elapsed -evp bf-cbc aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 4194998 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 1163073 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 302774 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 76480 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 9587 aes-128 cbc's in 3.00s
Doing bf-cbc for 3s on 16 size blocks: 3308303 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 64 size blocks: 1000628 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 256 size blocks: 263953 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 1024 size blocks: 66903 bf-cbc's in 3.00s
Doing bf-cbc for 3s on 8192 size blocks: 8398 bf-cbc's in 3.00s
OpenSSL 1.0.1t  3 May 2016
built on: Fri Jan 27 00:26:25 2017
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) 
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      22373.32k    24812.22k    25836.71k    26105.17k    26178.90k
bf-cbc           17644.28k    21346.73k    22523.99k    22836.22k    22932.14k
tkaiser

tkaiser

Posted
Posted
  On 2/25/2017 at 8:06 AM, Igor said:

ARMBIAN 5.26 stable Ubuntu 16.04.2 LTS 4.4.51-rockchip  

openssl speed -elapsed -evp bf-cbc aes-128-cbc
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      22373.32k    24812.22k    25836.71k    26105.17k    26178.90k
bf-cbc           17644.28k    21346.73k    22523.99k    22836.22k    22932.14k

 

This looks way too low. ODROID-XU4 with A15 @ 2GHz gets almost 4 times better AES scores: http://forum.odroid.com/viewtopic.php?f=93&t=17882&p=170395#p170373

 

Did you check cpufreq in parallel? I wonder whether it would help building OpenSSL from scratch and using 'mcpu=cortex-a17'?

Igor

Igor

Posted
Posted

Yes, you are correct. It was on powersave, those are now on proper speed:  :)

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      79215.37k    86050.52k    89357.40k    90211.33k    90456.06k
bf-cbc           50721.71k    57495.64k    59830.53k    60454.91k    60631.72k
tkaiser

tkaiser

Posted
Posted
  On 2/25/2017 at 8:44 AM, Igor said:

 

Yes, you are correct. It was on powersave, those are now on proper speed:  :)

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      79215.37k    86050.52k    89357.40k    90211.33k    90456.06k
bf-cbc           50721.71k    57495.64k    59830.53k    60454.91k    60631.72k

 

Thank you for the update, so I would assume by manually compiling OpenSSL with CPU specific flags and adding some Willy Tarreau patches (2 GHz instead of 1.8 GHz) MiQi will outperform ODROID XU4 in this area easily :)

 

BTW: Though I know it's somewhat stupid since sysbench sucks. But can you please also post output from the call below:

sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)

(while checking with 'armbianmonitor -m' whether throttling occured or not and at which clockspeed MiQi finishes).

Igor

Igor

Posted
Posted 
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)
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: 20000




Test execution summary:
    total time:                          71.6801s
    total number of events:              10000
    total time taken by event execution: 286.6122
    per-request statistics:
         min:                                 25.38ms
         avg:                                 28.66ms
         max:                                 85.60ms
         approx.  95 percentile:              32.45ms


Threads fairness:
    events (avg/stddev):           2500.0000/6.56
    execution time (avg/stddev):   71.6530/0.02

Where / which 2Ghz patch? ... I can try it later.

 

Just received eMMC for XU4 to try to fix that problem.

tkaiser

tkaiser

Posted
Posted
  On 2/25/2017 at 9:14 AM, Igor said:

Where / which 2Ghz patch? ... I can try it later.

 

See post #4 above or directly http://1wt.eu/miqi/patches-4.9/ (mainline kernel, so this is stuff for next or dev sometimes in the future). No need to hurry, I would believe fixing the eMMC issue with XU4 has higher priority :)

mdel

mdel

Posted
Posted

@@Igor

thx for the benchmarks.

 

those figures are quite impressive for a 32bit soc, it's about 20% higher than my s905 for aes-128

 

Could you also post the output of /proc/crypto to see if it uses an accelerated engine ?

 

unfortunately i didn't realize that this rk3288 is not one of the cheap ones, so basically you're up for a 65$ board (+20$ shipping) or a 60e tv box.. the 60$+15$ xu4 looks like a better deal.

 

 

@@tkaiser

so igor's board was running at 1800MHz and watching the patch there's a claim it's stable at 1920MHz, but looking at the table i see that :

static struct rockchip_cpuclk_rate_table rk3288_cpuclk_rates[] __initdata = {
+	RK3288_CPUCLK_RATE(2208000000, 1, 3, 1, 3, 3),

so i would also run at 2208MHz ??

 

are those patches specific to the MiQi board, or to the current kernel code published ? (meaning it would apply to any rk3288 board)

thx

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/25/2017 at 6:54 PM, mdel said:

@@tkaiser

so igor's board was running at 1800MHz and watching the patch there's a claim it's stable at 1920MHz, but looking at the table i see that :

static struct rockchip_cpuclk_rate_table rk3288_cpuclk_rates[] __initdata = {
+	RK3288_CPUCLK_RATE(2208000000, 1, 3, 1, 3, 3),

so i would also run at 2208MHz ??

I think commit messages for the patches answer your question: 

http://1wt.eu/miqi/patches-4.9/0007-ARM-dts-rockchip-miqi-add-turbo-mode-operating-point.patch

http://1wt.eu/miqi/patches-4.9/0006-clk-rockchip-add-all-known-operating-points-to-the-a.patch

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