7 7
eternalWalker

[NanoPi M3] Cheap 8 core (35$)

Recommended Posts

15 hours ago, James Kingdon said:

Yes, the 32bit version is armhf. I don't have any boards set up to run soft float.

I thought this call __aeabi_uldivmod was eabi soft float?

Share this post


Link to post
Share on other sites

No, I don't think so, it not taking floating point arguments for one thing. I think it's a helper function for something not readily expressible in the arm 32 bit instruction set, in this case 64 bit integer divide with remainder.

Share this post


Link to post
Share on other sites

James: I'm not so worried. You'll notice that the M2 just got a refresh as the M2a, so I'm guessing there's something similar in the works for the M3. They're pin compatible chips, after all.

 

For everyone else, Rafaello has 64 bit support running nicely by porting the Samsung Artik changes over to the 4.11.6 kernel, as well as uboot, etc.

 

https://github.com/rafaello7/linux-nanopi-m3

Share this post


Link to post
Share on other sites

Since I was interested in AES performance of the S5P6818 (ARMv8 crypto extensions usable or not?) to compare with other boards we're currently looking at I tried to boot the experimental image but can't login as root (tried it only via SSH so far). Board answers to pings but as soon as I connect with SSH and enter the password the M3 disappears from the network (pings stop working). I changed fstab options to replace 'commit=600' with 'sync', disabled log2ram and at least I now have armhwinfo.logauth.log and syslog from /var/log/. Is this expected behaviour or did others manage to login/use this image already?

 

Wrt AES tests: CPU features look sufficient, don't they: 'fp asimd aes pmull sha1 sha2 crc32 cpuid'

 

Share this post


Link to post
Share on other sites

Now I built my own OMV image with kernel 4.11.12 and had no more login hassles (most probably related to password expiration policy on normal Armbian images?). Quick USB2 performance test (repeating the test I did one year ago):

EVO840 JMS567 on USB host port, kernel 3.4.39 (defaults)      random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7063     7476     7531     7570     7536     7573
          102400      16    15812    17276    20397    20326    20421    16990
          102400     512    25465    25454    29117    28545    29114    25501
          102400    1024    25843    25401    29048    29279    29420    25899
          102400   16384    26592    26600    31280    31306    30841    26472

EVO840 JMS567 on USB host port, kernel 4.11.12 (ondemand)     random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     8510     9415     9943     9611     8323     9660
          102400      16    17705    20494    20712    20821    20369    20281
          102400     512    32877    33483    34939    36870    34841    32381
          102400    1024    32484    34057    34926    34561    34078    34246
          102400   16384    32105    33975    34851    35168    35427    34431

EVO840 JMS567 on USB host port, kernel 4.11.12 (performance)  random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     8219    10566    10595    10628    10355    10566
          102400      16    18219    21177    21225    21285    21287    21270
          102400     512    34467    34416    36900    37134    37088    34569
          102400    1024    34722    34936    37574    37677    37727    34897
          102400   16384    33827    35113    37789    37851    37922    35091

No 'USB Attached SCSI' (UAS) available with this kernel so USB2 storage performance now as expected (maxing out between 35-37MB/s)

 

Tests were done after applying these fixes/tweaks (there's no interactive governor so our ondemand tweaks were not applied and fixed IRQ affinity also helps with performance). Full debug output here (please note the funny 'dwc2 c0040000.dwc2otg: Overcurrent change detected' messages that prevented me from using anything connected to USB OTG port already a year ago with the old kernel)

 

I was curious whether we can make use of ARMv8 crypto extensions here (to add some impressive numbers there) but it doesn't seem so. Results at 1.4 GHz from 'for i in aes-128-cbc aes-192-cbc aes-256-cbc ; do openssl speed -elapsed -evp $i; done':

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

(/proc/crypto contents as reference).

 

BTW: Powering through Micro USB was too unreliable for me so I searched for FriendlyELEC's nice serial/PSU board sharing the same power barrel connector with Orange and Banana Pis and combined it with Xunlong's 3A PSU:

NanoPi_M3_Powered_reliably.jpg

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
7 7