Jump to content

[NanoPi M3] Cheap 8 core (35$)


eternalWalker
 Share

Recommended Posts

Search Before Posting!

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?

Link to comment
Share on other sites

Drat, just got confirmation that the m3 has been discontinued, just as 64 bit support is starting to come together courtesy of @rafaello7 https://github.com/friendlyarm/linux-3.4.y/issues/3

There's still the T3 with the same processor, but it's not as cost effective for my uses. It would be more compelling with 2G of ram - perhaps we can hope for a new version.

 

Link to comment
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

Link to comment
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'

 

Link to comment
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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...