James Kingdon Posted June 16, 2017 Posted June 16, 2017 3 hours ago, @lex said: Have you checked with armhf? Yes, the 32bit version is armhf. I don't have any boards set up to run soft float.
@lex Posted June 16, 2017 Posted June 16, 2017 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?
James Kingdon Posted June 16, 2017 Posted June 16, 2017 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.
devman Posted July 2, 2017 Posted July 2, 2017 On the github repository (https://github.com/friendlyarm/linux-3.4.y/issues/3) one user has gotten the artik 4.4.19 kernel to boot, although only with one core running. It's obviously not a final solution, but it's an encouraging development, as friendlyarm doesn't appear to be releasing a 64 bit kernel themselves anytime soon.
James Kingdon Posted August 10, 2017 Posted August 10, 2017 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.
devman Posted August 11, 2017 Posted August 11, 2017 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
tkaiser Posted August 22, 2017 Posted August 22, 2017 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.log, auth.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'
Igor Posted August 22, 2017 Posted August 22, 2017 For the record. This problem happened to me sometimes.Wrote on mobile
tkaiser Posted August 25, 2017 Posted August 25, 2017 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:
Recommended Posts