tkaiser

I tested this out, I can control those pins.  Is the issue that the SPI driver can show up and smash everything?  And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user?
 
Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.
 
 

Revised and re-tested tutorial with current Armbian OPi PC2 images, removed unneeded kernel compilation section.

Doesn't matter, that's what the '### Installed packages' entry is for
 
Since I don't understand what's happening on your installation I don't think so. You're running off eMMC, there's no SD card present, the boot environment doesn't look right and there's an older nand-sata-install.log lying around. I would need to understand this first...

Ok, switching from 408 MHz DRAM clock to 624 MHz on OPi Zero Plus (still cpufreq limited since DVFS not working, I'm running at 1008 MHz but can consider myself lucky since we've seen H5 boards that get instable at 1008 MHz with 1.1V VDD_CPUX for sure):
Test BSP Armbian old Armbian new std memcpy MB/s: 887.9 634.8 875.1 std memset MB/s: 2037.9 1553.0 2252.7 7z comp 22: 1288 1234 1515 7z comp 23: 1344 1279 1637 7z decomp 22: 3296 3329 3832 7z decomp 23: 3215 3317 3768 sysbench 648 (s): 14.4798 14.1447 14.1378 sysbench 816 (s): 11.4151 11.2191 11.1106 sysbench 1008 (s): 9.2395 9.0787 8.9818 openssl speed aes: almost identical So once DVFS is working there will be another slight performance increase in a few weeks.

@tkaiser NanoPi Neo2 with debian stretch:
Linux nanopineo22 4.13.13-sunxi64 #214 SMP Thu Nov 16 01:52:21 CET 2017 aarch64 GNU/Linux
as attachment
 
NanoPi_Neo2_tinymembench.txt

... and will never be supported. It wasn't supposed to be buildable at all but the condition was implemented in wrong place.

PC2: http://sprunge.us/jVAH

Since I prepare a little NAS test with Orange Pi Zero Plus today I upgraded the firmware of the other JMS578 on the NAS Expansion board. Side effect: with the more recent firmware the USB-to-SATA bridge also provides more real information from the connected disk instead of itself.
 
Prior to the firmware upgrade only /dev/sda shows nice information:

 
After I upgraded the 2nd JMS578 (needs a full shutdown and removing power after the upgrade!) now /dev/sdb also reveals more information (though the drive's serial still bogus):

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
 
So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
 
Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
 
So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

To prepare next steps I booted with vendor OS image once (obviously no tuning at all for this board, it seems that's generic Allwinner H5 BSP stuff already used for Orange Pi PC 2 before, at least this is /boot/orangepi/OrangePiH5orangepi.dtb being decompiled).
 
Performance results here: https://pastebin.com/TZhEPrqs (64-bit kernel 3.10.65, settings limiting cpufreq to 1008 MHz and clocking DRAM at 624 MHz)
 
Then I thought I take FriendlyELEC's Xenial image for their NEO Plus 2 (since same voltage regulation, switching between 1.1V and 1.3V toggled by PL06 pin) but to no avail. IIRC they implement some board detection logic and I ended up with no cpufreq support but running at 816 MHz, DRAM clocked at 672 MHz: https://pastebin.com/8wEaPiUp (quick note wrt iperf3 tests: with Armbian IRQ affinitiy settings numbers improve from 844/922 Mbits/sec to 895/940 Mbits/sec so once we have voltage regulation configured correctly on this board and can exceed 816 MHz cpufreq full GbE saturation will be possible)
 
With BSP kernel and without heatsink this thing idles at 55°C according to sysfs so it now wears a heatsink (and all tests above were made with a fan running in parallel). 

Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus

And updated wifi driver with fixed MAC address is coming later on to beta repository. 

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
 
So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
 
Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
 
So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
 
So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
 
Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
 
So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
 
So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
 
Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
 
So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

Yes, the lsusb ID is "Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp."
but IT IS a JMS567 like noted at the FriendlyElec-page for the NAS:
http://www.friendlyarm.com/index.php?route=product/product&product_id=192
 
And as attachment the proof as a picture
 
 

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

Well, I thought I was joking but in fact this does exist. An industrial i.MX6 design with 40 pin header does exactly that. Exposing the needed PCIe pins on the header:
 

Just a little bit: https://forum.armbian.com/topic/4921-orange-pi-zero-plus-h5-chip/?do=findComment&comment=43667 (but with UAS active also CPU utilization slightly decreases so it's good anyway)
 

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

Its now set up on the UK server  for both dl and apt. Test it, if you visit from the US it redirects you to main. Clone the setup on to any webserver with the following patch against /etc/nginx. Add more regions in the map if needed and make sure the server name directive for each vhost contains all the regional host names. You will also need the max mind geoip database from here: http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz. Save it to /usr/share/GeoIP. It literally takes less than 2 mins per server then its done.
 
Dont fanny about with bad solutions when the proper solution is so easy.
 
diff -r bkp/etc/nginx/nginx.conf /etc/nginx/nginx.conf 60a61,64 > #Updated maxmind geoip data > geoip_country /usr/share/GeoIP/GeoIP.dat; > geoip_city /usr/share/GeoIP/GeoLiteCity.dat; > diff -r bkp/etc/nginx/sites-available/apt.uk.armbian.com /etc/nginx/sites-available/apt.uk.armbian.com 0a1,6 > map $geoip_city_continent_code $closest_server { > default apt.armbian.com; > EU apt.uk.armbian.com; > US apt.armbian.com; > } > 5c11 < server_name apt.uk.armbian.com; --- > server_name apt.uk.armbian.com apt.armbian.com; 7a14,18 > > #GeoIP redirect > #if ($closest_server != $host) { > # rewrite ^ $scheme://$closest_server$request_uri break; > #} diff -r bkp/etc/nginx/sites-available/dl.uk.armbian.com /etc/nginx/sites-available/dl.uk.armbian.com 26a27,32 > map $geoip_city_continent_code $closest_server { > default dl.armbian.com; > EU dl.uk.armbian.com; > US dl.armbian.com; > } > 31c37 < server_name dl.uk.armbian.com; --- > server_name dl.uk.armbian.com dl.armbian.com; 33a40,44 > > #GeoIP redirect > if ($closest_server != $host) { > rewrite ^ $scheme://$closest_server$request_uri break; > } If you need vpn's for testing I can give you and ipsec, l2tp or pptp vpn connection that terminates in the US, UK, Germany, Italy, France, Australia, Russia, Taiwan, Japan or Holland.

Wrapped in a warm hat is one of my TV boxes (Tronsmart Vega S96) .
Run test for a couple of hours. Here is the result at the end of the second hour. Such a conclusion in the console, no change for end hours, so stopped the test.