tkaiser

Sorry for the late feedback. In the meantime I tested a new build with latest bootscript and it didn't boot at all. Was too lazy to connect serial console (since running a test on HC1 in parallel where the adapter was connected to) and thought 'Seems Zador is preparing whole switch to armbianEnv.txt so let's wait for this happen'. But now I wonder whether you're still preparing stuff or not?

Of course not, you won't get an AR9380 with antennas for less than 10 bucks. These cards are said to work well as AP but I never tried it with mine since with antennas it's the same as with mSATA-to-SATA adapters. I ordered them multiple times in China and receive weeks later something different not worth a return/refund (only one mSATA adapter arrived ever). In other words: I'm also one of the 'buy cheap, buy twice' guys I'm always laughing at I want 3 antennas since I've 2 client devices capable of 3x3 MIMO.

If you're on a branch that's already bumped to 4.13 then yes. In general if you want to stick to an older kernel release you need the appropriate patches for that exact version too. As a very simple example: Since I needed to revert back to 4.12 on Clearfog Pro and we switched already to 4.13 I had a look at the specific commit which fortunately only changed kernel config and a single patch. So all I had to do was to throw the old patch file in the appropriate directory below userpatches and same with the older linux-mvebu-next.config version. Easy. With board families that are still heavy WiP (some sunxi families for example) it might look different and you end up playing with 20 or even more files (throwing the old patch files below userpatches and disabling newer patches by using zero sized files of same name there)

You need to 'build' an enclosure of course (can be a used box and at least I prefer to have electronics invisible so this stuff is just sitting somewhere in a drawer with some ventilation -- an example). With a direct SATA connection hdparm is always fully working (and for disks that still ignore hdparm settings there are scripts available that do a spin-down manually, see discussion/links here) Wrt components: M.2 SATA adapter is just a few interconnections between two sockets. This is an item with a more realistic price. I bought for less than $10 an '450Mbps Apple Atheros AR5BXB112 AR9380 Dual Band' card on eBay coming from Hongkong (simply search for this or parts of the name) Same for PSU, simply search for 'psu 5v 12v' or something like that or better check local sellers to be sure PSU follows regulations

Documentation: macbookpro-tk:Armbian tk$ grep -r ARMBIAN_MAINLINE_KERNEL_VERSION build/* macbookpro-tk:Armbian tk$ It would be great if you could continue looking 'from the outside' on the documentation, collect issues here or simply send a PR against https://github.com/armbian/documentation if you're sure what needs to be adjusted.

By providing power to them Seriously, the Clearfog boards use the common 5.5/2.1mm barrel connector (centre positive) you find tons of 12V PSUs for everywhere. A nice solution to power board and external disks can be a dual-voltage PSU with screw terminals as can be seen here: https://forum.armbian.com/index.php?/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/&do=findComment&comment=29574 PSU ratings are 5V/2A / 12V/2.5A (I simply followed Igor buying one and chose the same) and it can handle powering a Clearfog Pro and a 3.5" disk spinning up (the Barracuda I use needs nearly 2A on the 12V rail when spinning up). Or you combine a 12V PSU with step-down converter to generate to 5V for 2.5" disks. But if you don't want to solder screw terminals are the easiest choice. BTW: mSATA/mPCIe share the same mechanical connector, on Clearfog boards with default settings u-boot is configured to drive them as mPCIe and patches are needed to transform them into true mSATA slots (you can then use with mechanical mSATA-SATA adapters). And the same is now true with the M.2 on most recent Clearfog Base where the M.2 slot is SATA by default and has to be transformed into PCIe also by a u-boot patch. In other words: if you want hassle free operation stay with the defaults, use the mPCIe slot for Wi-Fi, use the M.2 for SATA and use the USB3 port to connect another disk if needed (you won't notice any performance differences with HDDs anyway, I found it pretty hard to measure lower performance even if a good USB3 hub is in between)

Not really, same with Marvell/Globalscale and 'community' (they seem to be only interested in big Linux distros and *BSD support is essentially only there for 32-bit Armada 38x). You might visit again http://espressobin.net/forums/topic/pfsense/#post-879 (keep in mind that @gonzopancho is Jim Thompson) and check there the pfsense forum link. No one on this earth ever tried, right? Since all R1 users fear the 'might need additional care by the driver' and 'haven’t looked at the driver sources whether it can handle the unconfigured switch properly' bits this hardware operation is accompanied with. At least all the people I asked so far whether it works magically disappeared from the forum.

Has this ever been confirmed by a human being soldering the necessary resistor and checking whether R1 in bricked state is a dumb switch or separates WAN and LAN ports? Well: http://forum.banana-pi.org/t/question-about-lan-wan-isolation/3822/9 -- besides that I still fail to understand the design concept and both BPi 'development focus' and 'customer care'. Instead of answering user questions how to get the R2 to boot after a power failure (well, ahem, this thing is advertised as being a router, isn't it? Wouldn't it be great if it could boot after a power failure without someone standing next to it and pressing a button for 10 seconds?) they instead answer that playing 720p video is possible software decoded on their 'router'. Also they claim the ASM1062 on their router/NAS combo being the only SATA device in the universe implementing a mythical (and non-existant) '4 TB barrier' preventing normal SATA disks of any size able to work with this device (seriously: SATA is 48-bit LBA by design, this R2 is not running an outdated BIOS or a really old Windows release. And if there would be a TB limit then it would be 2TB and not 4TB -- if 4TB are working then the next possible limitation is 144PB) And the super secret battery connector is another issue (why the hell aren't they able to tell their customers how to use their boards with their proprietary 6-pin battery connector? Or at least sell such batteries which they also refuse to do)

Well, then good luck since you need FreeBSD support for the SoC family first (and there's not even basic one yet and especially with such feature-packed SoCs like those Armadas you want more than basic support ). Please check the link wrt pfSense on ARM: http://espressobin.net/forums/topic/pfsense/#post-879 Given that a few *BSD devs are pretty active with sunxi hardware I would suppose pfSense support for an OrangePi R1 exists earlier than for those more suitable 64-bit Marvell platforms. Well, we're really off-topic in a NAS thread now Back to 'low power NAS' use cases: x64 designs are becoming attractive in this area again especially when using Intel's QuickAssist technology (QAT). I try to get my hands soon on a Denverton mainboard like GIGABYTE's MA10-ST0 to see what's possible with ZoL in the meantime (see the performance section in 0.7 release notes). If time allows I test this out on Clearfog Pro in the meantime to get an idea about raidz2 performance on such an ARM platform too.

So you never bought Netgate products before? For example https://www.netgate.com/products/sg-1000.html (the TI SoC has an internal 3 port GbE switch that is used here)

USB is an option too. RTL8153 for example works surprisingly well with more recent driver/kernel. Even a fully saturated 1Gbps uplink is not a problem. But why would anyone in this world combine a router/firewall thingie with storage anyway? It's either a router or a NAS but not both at the same time. BTW: Of course an USB attached NIC can not make use of Marvell's packet processor. That's why the people not so happy with ESPRESSOBin design will love the R-1 instead: https://www.netgate.com/blog/lord-vader-your-firewall-is-ready.html

Just move the whole 'thread' to where it belongs to: https://forum.armbian.com/index.php?/forum/31-sd-card-and-power-supply/

Why do you trust even in these 1512MHz? Care to remember what Willy Tarreau discovered when trying to use Amlogic SoCs for his build farms: http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm#Very_interesting_discoveries_about_cheating_vendors_-_2016.2F07.2F09 Your consumption numbers also look suspicious but the tool you used is pretty lightweight. When I tested with a NanoPi M3 last year (octa-core A53 with up to 1.4 GHz) I would've to search for another PSU to power the board when allowing the 1400 MHz since consumption was too high for my 5V/2.5A 5V/2A PSU (IIRC with cpuburn-a53 1300 MHz was the maximum). You could try this NEON optimized Linpack here: https://github.com/ehoutsma/StabilityTester to get a clue. Maybe stabilitytester.sh already runs out of the box (trying to walk through available cpufreq/dvfs OPP) but at least you can check for dependencies and how to call xhpl64. Testing individually by sending CPU cores 0-3 or 4-7 offline is an option too Edit: NanoPi M3 tests back then (it was even worse and with the Linpack not even running at 1GHz on all 8 cores was possible): https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=14697

Interesting. Are you able to repeat the test without the mSATA SSD being present (me assuming that then the JMS578 not tries to register itself on the USB bus and you being able to enjoy a working card reader)? Wrt JMS578 behaviour: On ODROID HC1 the JMS578 is always present on USB bus even when no SATA device is connected to it. With Pine's ROCK64 SATA cable and 'my' Xunlong NAS Expansion board it's different so I would assume that's configurable behaviour (maybe depending on JMS578 firmware or toggled by GPIO settings). Maybe this is also important. But I've not the slightest idea how to query the JMS578 for firmware version (in Hardkernel/ODROID forum they provided a firmware flashing tool a while ago but not from 'official' JMicron sources since they forbit providing end users with this stuff but from a server 'somewhere on the Internet')

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

Did you had a mounted filesystem on the mSATA (so the host was 'fighting' for the device? ) At the bottom my dmesg output when running with 4.11.1 kernel: http://sprunge.us/IIPS At 138.934447 the JMS578 appeared on the bus after I provided external power to the SSD. I did not mount the disk, then around ~388.583768 I tried to insert an USB card reader which did not work due to mechanical problems. But at least the JMS578 shortly disappeared on the bus and after I remove the card reader 10 seconds later JMS578 and SSD re-appeared. Then around ~442.766930 I attached another SSD (funnily with same sector count) in an JMS567 enclosure to the respective USB receptacle, the JMS578 disappeared and the JMS567 with connected SSD appeared. Not that much 'device descriptor read/64, error -71' occurences and of course it would be pretty stupid to play 'hot swap' anyway. But at least we know that the NAS Expansion board can be used with only one disk in a way that then one of the two USB receptacles is routed to OPi Zero's USB host controller so you get one connected disk and another USB jack that has not to share bandwidth with anything

Tested the following topology now: No Zero connected through pin header, just an OPi PC connecting its USB OTG (configured as host) to the NAS Expansion board which is connected to an SSD (today surreptitious advertising not for Samsung as usual but Intel this time!) Works pretty well, iozone numbers from the OPi PC running legacy kernel (no UAS, OTG port in host mode): random random kB reclen write rewrite read reread read write 102400 4 7897 10436 10499 10519 7999 10431 102400 16 18151 21142 21284 21325 21311 20959 102400 512 35564 36253 36768 36723 36833 34635 102400 1024 36223 36801 37285 37371 37374 36405 102400 16384 37030 36431 37935 38082 38085 37800 Armbianmonitor -u: http://sprunge.us/gXXb So we have two basic modes: NAS Expansion board used together with an OPi Zero connected through pin headers: if there's no SATA device connected to JMS578 it's configured to not show up on the bus (consumption also lower, most probably since the SATA PHY is unpowered in this mode?) if a (m)SATA device is connected JMS578 activates itself and shows up on the USB bus. The mSATA slot is usb2, SATA slot is usb3 but if an USB peripheral is connected to one of the 2 USB receptacles the respective JMS578 disappears from the bus and the externally connected USB device 'wins'. Left receptacle wins over mSATA, right one over SATA ('left' is near audio jack, 'right' near the SATA connector) When there's a power source connected to the usual Xunlong power barrel (4.4/1.7mm, centre positive) the connected Zero can also be powered from the NAS Expansion board When there's no external power source connected then the OPi Zero provides the power to NAS Expansion board NAS Expansion board with no Zero connected through pin headers: behaves like a normal 'dual disk enclosure', left USB receptacle is connected to mSATA, right one to the SATA port At least the JMS578 can be powered by the connected host through the USB power lines Still open questions (at least for me): mSATA SSDs need 3.3V, does the NAS Expansion board generate them when only when powered through its own barrel connector or also when power is provided from an OPi Zero? What does happen if a power source is connected to an OPi Zero and to the NAS Expansion board? Mixed mode possible (OPi Zero connected and able to use mSATA slot while an externally connected host gets 'routed' to the other JMS578)? I don't know whether @martinayotte is claiming this over here based on a test or judging from the picture above or if simply did not understand at all (most probably the latter)

Ah, I start to understand. So in this mode then the NAS Expansion board creates a direct connection between the USB receptacle and the JMS578 (left <--> mSATA, right <--> SATA)?

Huh? Which hub? There's some logic on the Expansion board and in the JMS578: if there's no SATA device connected to JMS578 it's configured to not show up on the bus (consumption also lower, most probably since the SATA PHY is unpowered in this mode?) if a (m)SATA device is connected JMS578 activates itself and shows up on the USB bus. The mSATA slot is usb2, SATA slot is usb3 but if an USB peripheral is connected to one of the 2 USB receptacles the respective JMS578 disappears from the bus and the externally connected USB device 'wins'. Left receptacles wins over mSATA, right one over SATA Only mSATA slot populated with SSD, Ethernet dongle on right USB port: root@orangepizeroplus2:~# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Now external disk in JMS567 enclosure connected to left USB port. The onboard JMS578 with the SSD behind disappears since the external JMS567 takes over: root@orangepizeroplus2:~# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 002: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Based on my understanding connecting such a Male-Male cable will only result in a direct connection between the other host and either usb2 or usb3 on the Zero. The respective JMS578 will disappear as soon as anything is connected to 'its' USB receptacle. Here's dmesg output at the end: http://sprunge.us/IIPS

@James Kingdon can you please check IRC backlog from today (http://irc.pine64.uk) and join the party there? We NEED you

According to their OS image and schematic the board should switch between 1.1V/1.3V. Please be aware that for whatever reasons the thermal readouts on OPi PCB rev 1.4 are somewhat off (still no idea why). Are you able to somehow precisely measure consumption of the board (without the shield if possible)? I would be really interested in idle consumption and temp when telling the CPU to clock at either 240 MHz or 1200 MHz.

Sure, h3consumption is made for that. Just search the forum for it.

For anyone really interested in hardware/software capabilities and progress better ignore the manufacturer copy&paste spam above and visit BPi R2 forum instead: http://forum.banana-pi.org/c/Banana-Pi-BPI-R2 There you find the iperf numbers, the poor SATA performance, R2 suffering from the same problem as R1 and also people desperately asking for SinoVoip's most hidden secret: their proprietary battery connector they don't want you to use. The R2 uses an ASM1062 PCIe controller to provide SATA (dual lane capable, just one lane used). Only 230MB/s with 1M block size would be pretty slow -- see here results also with 'Samsung SSD' and a similar PCIe 2.0 x1 connection on Clearfog: https://forum.armbian.com/index.php?/topic/4845-marvell-based-4-ports-mpci-sata-30/&do=findComment&comment=37740 -- but since SinoVoip's testing methodology is unknown (is the SSD able to exceed 500 MB/s or is it an old and slow one?) and somewhat sucks (only testing sequential speed and this with the wrong tools) maybe R2 is able to achieve normal ASM106x SATA performance behind a single PCIe lane (that's around 380 MB/s). If not maybe PCIe bandwidth is limited (check thread above, that's for example the case with i.MX6 platform)

Ok, I removed the insufficient u-boot patch (we tested yesterday also with the wrong module -- FORESEE and not SanDisk). Are you able to generate a PR against https://github.com/armbian/build with the necessary changes to both u-boot and kernel? BTW: Would be interesting to get output from the following (sample output for 16GB FORESEE eMMC in my Pinebook here: http://sprunge.us/JcZG) git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git cd mmc-utils make ./mmc extcsd read /dev/mmcblk0 | egrep -v '0x00$|0x0000$|0x000000$|0x00]$'

Providing 'armbianmonitor -u' output would help getting a clue what's going on on your board. Then you could check 'lsmod' output and do a 'modinfo rl8xxx' (the module in question serving your dongle) about capabilities. Those RealTek drivers allow for a ton of options and usually you can mask/rename the 2nd interface in such a way: https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/modprobe.d/wifi-rt8723-pine64.conf