Search the Community

When you did the upgrade, simply reboot and provide the output of 'sudo armbianmonitor -u' afterwards here (I'm especially curious whether the version will be shown since when I ran into update troubles /etc/armbian-release was missing). If I understood correctly you won't loose that much in case update fails since you would then start over with a fresh 5.20 image? Regarding web server use case please take some time and read through posts #1 and #6 here. IMO the best option would be to use mainline/vanilla kernel and btrfs with activated file compression. But yet no OS images available (I've made one but without thermal throttling so I won't share) since we have to wait a bit until Ethernet and dvfs/throttling patches are accepted upstream. But on Orange Pis with eMMC the best place to put the OS on is always there. And in case amount of data allows it I would better choose a 64 GB Samsung EVO than any HDD at the moment (but this is also somewhat tricky to boot from eMMC while SD card is inserted -- in case you think about this get back to us here) Regarding the use of GL830... Xunlong (Orange Pi maker) is pretty good in making hardware but not that great when it's about software. I believe they simply didn't know how bad GL830 performs in reality. And the reason why they developed the 'Plus' with an USB-to-SATA bridge is rather simple. The first 'Orange Pi' was based on Allwinner's A20 which features a real SATA port. Then Xunlong developed a quad-core successor based on Allwinner's A31 (no SATA any more) and after discovering that Allwinner discontinued A31/A31s they chose H3 instead (still no SATA). Providing a 'Plus' model that lacks features is a bit problematic and so they added GL830 (this bridge is also used on the A31 equipped MeLE TV boxes so maybe it just looked as 'best' choice when developing the board?). It took also some time until the first people realized that performance is not that great (applies still to some 'communities' around other SBC, especially Banana Pi M3 which uses the same GL830 in an even more weird and less performant way). At least now we know how performance looks like... and choosing the cheaper Plus 2E and combining with a good USB disk enclosure seems to be the better idea in the meantime.

In case you start from scratch again I would suggest using the most recent image: Armbian_5.20_Orangepiplus_Debian_jessie_3.4.112.7z Please be aware that there's currently a bug influencing upgrade to 5.20. It is strongly recommended to do it this way otherwise you might end up with a bricked installation: http://docs.armbian.com/User-Guide_Getting-Started/#how-to-update I would first check your power supply (able to provide enough voltage and amperage), a 2.5" HDD might need up to 1A additional power when it spins up, in case you use crappy cables this might lead then to an undervoltage situation and system freezes. And I would also refrain from moving the system to a SATA disk (HDDs especially behind the GL830 are slow as hell compared to Orange Pi's eMMC!). And at least what I really like about those SBC is that they consume as less as 1W which somewhat contradicts with using an HDD in 'always spinning' mode. Regarding your use case you can choose any webserver on a H3 device. Even Apache with all modules loaded should be fine or at least your OPi still fast enough to cope with bloated software

I downloaded the following file Armbian_5.14_Orangepiplus_Debian_jessie_3.4.112.7z. Or maybe I can check the system via the shell? Now I can boot from eMMC (disconnecting the HDD was crutial?) For now I try everything for learning purposes - this is my first encounter with SBC. I want to make a Web server to show information from temperature sensors. I also want to control the outputs via web page. I understand the information about speed of the different usb-hdd bridges. Still if I want to use the HDD with inbuilt GL830 what should be my next step? I want to install lighttpd. Is it a good choice?

Which Armbian variant are you using? Vanilla or legacy? Ubuntu or Debian? Then: OPi Plus has no SATA just the slowest USB-to-SATA bridge in the world. GL830 is also known to report wrong drive sizes: https://irclog.whitequark.org/linux-sunxi/2016-06-27#16843360; So the best what you can do with this SATA connector is to avoid it. If you want to use it anyway then put nothing on it where performance is needed. Follow arox' adivce, disconnect the HDD, install Armbian on eMMC using our nana_sata_install script. The eMMC is several times faster regarding sequential transfer speeds than any HDD connected to GL830 and also magnitudes faster if it's about the more important random IO performance. Then please describe your use case. If it's about headless NAS or web serving then I would buy an externally powered drive enclosure with JMS567 and use mainline kernel in the near future since then you can make use of UASP (not possible with onboard GL830)

LOL, really? Ok, this board is not interesting at all, no further test/numbers needed. I was interested in RAID-0 performance since due to the ultra slow GL830 USB-to-SATA bridge limiting real writes/reads to 15/30 MB/s max this mode would be absolutely useless (it's easy to understand but the average customer of this gadget most probably won't believe it until he sees numbers/graphs) BTW: I would never use RAID-1 with a proprietary controller like this until tested how the controller deals with data mismatch between the two drives. Easy test: Create a text file containing "1", then attach both RAID members directly to a SATA port, when the FS is not acessible then it's already time to throw the gadget away. If it's accessible modify the file one time to read "2", on the other disk "3". Then test what you get back when the 2 disks are again RAID members. If it's either "2" or "3" then throw the gadget away. It's really that easy.

BTW: Since it seems you bought already an CT+ and this 'famous' HDD-RAID subboard (a combination that shows worst storage performance ever) would you mind providing performance numbers to this thread: http://forum.armbian.com/index.php/topic/1925-some-storage-benchmarks-on-sbcs/ Simply set up a 'hardware RAID-0' there, create an ext4 FS with default settings and then run the following after doing a cd to the RAID-0: iozone -e -I -a -s 1M -r 1k -r 2k -r 4k -i 0 -i 1 -i 2 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 iozone -a -g 4000m -s 4000m -i 0 -i 1 -r 4K -r 1024K Sequential performance will be bottlenecked by crappy GL830 USB-to-SATA bridge but I wonder how much random IO will suffer with such an insane setup. IMO it's important to provide such numbers to show how much a device that is considered faster (octa-core! Still SATA!) sucks in reality. In case you find the time for this test repeating it with Orange Pi PC running with mainline kernel, btrfs raid-0 and UASP capable disk enclosures would be great (since the cheap and 'slow' H3 device will outperform the overprized CT+ and it's weird RAID card by magnitudes)

Well, you seem somewhat experienced but many people failed with loboris images on OPi Plus since they overread that they must replace both kernel and script.bin since neither Ethernet nor all USB ports work (since the internal USB hub isn't powered on when using the wrong script.bin and Ethernet needs different drivers with his kernel). So in case you tried his images and did use update_kernel.sh already then chances are pretty high that your board is defective regarding GbE (either connection PHY <--> SoC or PHY <--> power). At this point I would give up and ask for a refund since unfortunately the USB ports on Plus and Plus 2 are behind an USB hub so adding an GbE USB adapter (like this) won't show that good performance. Fortunately the USB-to-SATA bridge uses an own USB port (not like on Banana Pi M3 where the 'engineers' put the GL830 also behind the USB hub) but unfortunately this chip is ultra slow (IMO from all H3 based Orange Pi, Plus and Plus 2 are not interesting at all due to lack of IO bandwidth... but as usual: YMMV)

Another update: since I was testing an A20 board today in preparation of Armbian 5.15 release, SATA was mentioned in this thread and I found 2.5" disks I gave it a try and compared NAS performance on an A20 board using SATA, old/slow USB mass storage mode, faster "USB attached SCSI protocol" mode (UAS) and also a RAID-0 between SATA/UAS (to eliminate storage bottlenecks and make the network the limiting factor) I used a pcDuino3 Nano running 4.6.2, at 960MHz clockspeed (performance governor) using 2 identical SpinPoint M7 (same firmware, same useage profile). Single drive tests done with the same drive to show the differences protocol (SATA, UAS, USB Mass Storage) and the bridge chip in the enclosure might make. Drive data according to smartmontools (both USB-to-SATA bridges I used are fully SAT compatible and allow to query SMART data and trigger SMART self tests): Model Family: SAMSUNG SpinPoint M7 Device Model: SAMSUNG HM500JI Firmware Version: 2AC101C4 User Capacity: 500,107,862,016 bytes [500 GB] Sector Size: 512 bytes logical/physical Form Factor: 2.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 6 SATA Version is: SATA 2.6, 3.0 Gb/s SMART support is: Available - device has SMART capability. SMART support is: Enabled The iozone tests used these 3 sets (the first set is our usual test setup to get especially random IO performance, the two last test runs use twice the size of physical DRAM to show real sequential disk throughput without caches/buffers involved): iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 iozone -a -g 2000m -s 2000m -i 0 -i 1 -r 4K iozone -a -g 2000m -s 2000m -i 0 -i 1 -r 1024K Onboard SATA: random random kB reclen write rewrite read reread read write 102400 4 6187 6403 10898 11470 497 5613 102400 16 12819 12422 22983 23358 1921 11974 102400 512 25472 25326 44996 44854 23549 25337 102400 1024 26429 26344 45306 46847 28518 26395 102400 16384 27194 27369 71150 72926 68996 27630 2048000 4 40796 39704 79686 78330 2048000 1024 40106 39322 79919 77556 USB/UAS: lsusb: 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge dmesg: usbcore: registered new interface driver uas random random kB reclen write rewrite read reread read write 102400 4 4709 4825 6402 6599 496 4483 102400 16 12489 12306 15237 15500 1843 12022 102400 512 28286 28193 28422 29075 20617 28278 102400 1024 27861 28110 29240 29541 24940 27897 102400 16384 32088 32230 35944 36109 36408 31965 2048000 4 37538 37318 37074 37188 2048000 1024 37868 36838 37218 37293 USB/BOT (Mass storage): lsusb: 04fc:0c15 Sunplus Technology Co., Ltd SPIF215A SATA bridge dmesg: usbcore: registered new interface driver usb-storage random random kB reclen write rewrite read reread read write 102400 4 3646 3663 4810 5090 484 3485 102400 16 10371 9723 13667 13167 1880 9858 102400 512 26678 26648 26981 27092 19296 26626 102400 1024 27536 27472 27326 27577 21148 27504 102400 16384 34559 34533 32692 33114 33020 34524 2048000 4 32443 31353 32570 32777 2048000 1024 32223 31745 32575 32726 RAID-0 made of one SpinPoint M7 attached to SATA and the other to the UAS capable JMS567 USB enclosure I used btrfs and enabled also LZO compression so iozone results (especially sequential) are pretty worthless. It's just about eliminating storage bottlenecks to get the idea how an A20 based NAS with GbE behaves compared to an 'USB only' NAS as above. mkfs.btrfs -m raid1 -d raid0 /dev/sda1 /dev/sdb1 mount -o compress=lzo /dev/sda1 /mnt/sda/ random random kB reclen write rewrite read reread read write 102400 4 5607 5644 8357 8595 568 5203 102400 16 13339 12873 19534 19906 2026 12318 102400 512 49861 49044 50417 52949 31396 49289 102400 1024 53645 52701 56170 57347 43232 53006 102400 16384 64269 66759 62455 64459 61649 65130 2048000 4 86293 70816 65671 65579 2048000 1024 110122 96309 154940 153801 Simple conclusion USB when used on a device that is 'USB Attached SCSI' capable is not that bad (applies to A20, H3 and most likely also A64 when used with mainline kernel). But it depends also on the USB-to-SATA bridge used in disk enclosures or onboard (unfortunately on all sunxi boards with an USB-to-SATA bridge the horribly slow GL830 is used that's also not UAS capable, so bad news for owners of Orange Pi Plus, Plus 2, Banana Pi M3 or Cubietruck Plus). The Ethernet implementation in the newer Allwinner SoCs also is not that bad as the one used in A20 (here maximum network speeds differs a lot between several GbE capable sunxi boards for still unknown reasons). So when we're able to use mainline kernel on H3 devices performance will further improve (see also the measurements with the USB-GbE dongle above). At least for me SATA isn't a requirement any longer. But in case Olimex is right and Allwinner releases a pin compatible quad core A20 successor later this year it might get interesting again Some background information: http://linux-sunxi.org/USB/UAS http://linux-sunxi.org/SATA http://linux-sunxi.org/Sunxi_devices_as_NAS

Almost forgot: The test of the cheap RTL8153 USB Ethernet dongle was also intended to give our H3 users the idea what to expect from spending additional $7.50 regarding network throughput if your H3 device is only 10/100 Mbits/sec capable (with Fast Ethernet you're limited to ~8 MB/s NAS throughput anyway). The most important detail to consider is whether you're dealing with USB ports that have to share bandwidth or not. H3 features 3 USB2.0 host ports and 1 OTG port (that can be switched to host mode and shows just a little performance drop) but unfortunately some devices use an internal USB hub. The performance numbers for OPi Lite above are only valid for other H3 devices where USB ports do not have to share bandwidth. So in case you own a Beelink X2 for example (2 USB host ports available) you're able to increase NAS performance by adding a GbE USB dongle and connecting an USB disk to the other port. If you own an Orange Pi 2 (or '2 mini') that's not true since the 4 USB ports available there have to share bandwidth since they are behind an internal USB hub. The count of USB ports doesn't matter at all. The question is just whether an internal USB hub (shared bandwidth) is used or not. Back to NAS useage again: That means horrible hardware designs like every Raspberry Pi (only one USB 2.0 port available between SoC and the outside) or moronic stuff like Banana Pi M3 (A83T SoC features two host ports but the 'engineers' chose to use just one of them connecting to an internal USB hub so all external USB ports and the ultra-slow GL830 USB-to-SATA bridge have to share bandwidth) will show worse NAS performance compared to an Orange Pi Lite with external Gbit Ethernet adapter

Steven was open to our suggestions and the main H3 devs already have their boards or they are on their way. Also Foxconn realized (after been poked for ages to start to contribute to community!) that it would help and sent out BPi M2+ boards to some linux-sunxi devs (same with M3/A83T). Regarding your kernel questions linux-sunxi IRC would be a better place. And regarding Xunlong and A31s you might be surprised that Xunlong designed this already: http://www.armbian.com/orange-pi-a31/ The whole story: Foxconn started the Banana Pi journey a while ago and asked Steven/Xunlong to do the ODM work for the original Banana Pi. They contracted then with SinoVoip to let them do manufacturing and with LeMaker that should do support and build up a community around. Then LeMaker got greedy, produced the Banana Pro themselve and applied for the Banana trademarks (which they had to return in the meantime and are more or less out of Banana business now) and Xunlong sold their own Banana Pi compatible A20 boards (the original Orange Pi and Pi Mini). In the meantime Xunlong/Steven developed the A31s based quad core successor but switched to H3 instead since Allwinner discontinued A31/A31s before the product was ready (that's the reason only a few of these A31s based Oranges are existent). According to Steven SinoVoip does then a rip-off (the Banana Pi M2 -- when we remember how software support looked like in the beginning then the whole story sounds plausible). Now Foxconn/SinoVoip did another rip-off, the BPi M2+ (they copied each and every pin mapping from Orange Pis to be as compatible as possible but the stuff they did differently results in problems: eg. the missing programmable voltage regulator being one of the reasons for overheating BPi M2+ is suffering from so badly). Regarding BPi M3's history I've no idea but this board has so many design flaws that it really can not be recommended to anybody. And yes, there it's even worse since SinoVoip/Foxconn decided to use only one single USB port (A83T has two of them) to connect both the ultra slow GL830 USB-to-SATA bridge as well as the internal USB hub so all USB ports and pseudo SATA have to share bandwidth -- that's different on OPi Plus and Plus 2 or on the pretty similar H8 based CubieTruck + that uses one USB port for the SATA bridge and the other one for the USB hub!) Looking into the future I'm curious whether this will become reality or not: https://olimex.wordpress.com/2015/07/09/allwinner-did-it-again-new-quad-core-powerful-chip-pin-to-pin-compatible-with-a10-and-a20/#comment-22806

The bug could be fixed easily if you've an Ubuntu 14.04 virtual machine up and running (you could use Zador's work to patch the M3 BSP linux kernel source). Let's see when/whether they react on the issue I opened. Normally this is stuff that has to be fixed within 24 hours. And regarding 'terrible design'. Yeah, but that's just one of the many design flaws. Using Micro USB for DC-IN on the first production batch was the biggest mistake, the choice of the ultra slow GL830 USB-to-SATA bridge is insane, connecting both internal USB hub and the GL830 to one single USB host port (so that 'SATA disk' and all USB ports have to share bandwidth instead of connecting the GL830 to the 2nd USB host port like Cubietech did on their Cubietruck +) is also close to unbelievable. Also not preparing a heatsink like Hardkernel does it on ODROID C1+/C2 is just moronic with a SoC like A83T. The only real use case for this board could be lightweight web services where the octacora SoC could shine. 2017 when mainline kernel support might be ready. At least the Foxconn people (who started the Banana journey) start to understand. They met up with one of the linux-sunxi devs last week and send out board developer samples to real developers now

BTW: I chose the Orange Pi Plus as an example for a reason. Since this is a device where everyone will get the idea that it's necessary to test stuff individually. When you connect a SATA disk to the Orange Pi Plus which seems the most reasonable choice you probably won't see any performance improvement compared to CubieTruck now. If you use the very same SATA disk, put it in an external enclosure and connect it through USB then performance will improve. Why? Is SATA and USB different on the Orange Pi Plus? No, it's just the H3 SoC features no SATA and the SATA port on the OPi+ has been implemented using the slowest USB-to-SATA bridge in the world (GL830) which isn't able to exceed 15 MB/s write speeds and will be outperformed by any external USB disk not relying on GL830. So refusing to 'benchmark correctly' will just lead to another frustrating situation and a device you might throw into the bin. Measuring all the stuff individually you're able to identify the real bottlenecks and improve the situation. In case you asked me: Sure, you can always loose data as long as you're not doing backups Really, running any sort of real benchmark might put significantly more load on a device which might lead to stability problems caused by an insufficient PSU for example. The 'armbianmonitor -c' check was designed to verify the speed/reliability of SD cards and thumb drives (and no, the tests do not destroy anything, just try to fill the storage in question with test patterns that are verified later) but being used with a disk and insufficient power supply they might lead to data/filesystem corruption. But that's what benchmarks are for (when used in an active approach), identifying bottlenecks be it performance or reliability relevant. In case anyone's interested: We used the linpack high performance benchmark to identify reliability issues caused by undervoltage settings with Pine64 in the past: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-196399188

Not possible. H3 has no SATA capabilities and if the Plus 2 (or 2 Plus? What a naming scheme Xunlong invented! WTF?!) uses the same crappy GL830 USB-to-SATA bridge then that's reason number one to stay away from this device. Regarding GL830 please read from here on: http://linux-sunxi.org/Banana_Pi_M3#SATA

It looks like you can't do that much since the USB-to -SATA bridge used on Orange Pi Plus, Banana Pi M3 and Cubietruck plus (GL830) is simply crap. No one ever achieved more than 15 MB/s write and 30 MB/s read. This might be the slowest USB-to-SATA bridge in the world. Regarding your other benchmarks: just try to understand the various discussions on this topic (also over at CNX -- the comments section and the links therein are the most interesting stuff) and please accept that passive benchmarking is always crap producing huge amounts of numbers without meaning.

Ok, time to stop. 'Team BPi's update mechanism is just a joke and it's not worth the time to play with this stuff. I just put our new armhwinfo.log online to be able to think about board auto detection (GL830 USB-to-SATA bridge and count of cpu cores is interesting -- but this is exactly the same as on Cubietruck Plus, there the GL830 is just not behind the internal USB hub but directly connected to the 2nd USB host ports through HSIC). We'll see -- unless mainline u-boot support for A83T/H8 doesn't improve these boards aren't worth a look

Everything that applies to Banana Pi M3 also applies to the Cubietruck Plus (except DC-IN -- Cubietech uses not the moronic Micro USB connector but a sane power barrel). With these devices you get: great theoretical integer performance (you won't be able to benefit from unless you use heatsink and a fan) worst I/O bandwidth possible due to crappy GL830 USB-to-SATA bridge (but Cubietech wasn't that moronic as 'Team BPi' and used one USB host port for GL830 and used the other for an internal USB hub -- on Banana Pi M3 only 1 USB host port is used and everything is behind the internal USB hub) If you're able to apply the fixes from the Banana people you could make use of GPU acceleration (please keep in mind that H8/A83T/R58 rely on a pretty slow SGX544MP1 GPU) For many use cases the Cubietruck Plus is a real downgrade compared to the older Cubietruck (H8 vs. A20). BTW: The pcDuino8 Uno is also based on H8 but doesn't waste an USB port for a crappy USB-to-SATA bridge. Unfortunately the LinkSprite people don't understand the GPL, do not release their BSP variant and their users are even more lost than unfortunate Banana Pi M3 customers.

To address some of your concerns/questions: The GL830 USB-to-SATA bridge seems to be responsible for the slow SATA performance (15 MB/s write, 30 MB/s read -- it's really weird to realise that the very same crappy IC is also used on Banana Pi M3 and Cubietruck Plus now). If they would've used a better bridge and if mainline kernel could be used then 40 MB/s per USB port are possible. I already suggested to Steven/Xunlong to release such a board (H3, 2 GB RAM, GbE, 3 x JMS567/JMS568) Software/support situation for the H3 based Orange Pis has been very poor in the past. The manufacturer's OS images being broken more or less you would've to rely on 'loboris'. He's done a great job getting everything to work. Unfortunately his settings made use of heavy overclocking/overvolting leading to all sorts of stability and heat problems. In the meantime the situation changed. Many linux-sunxi devs show an interest in Orange Pi PC, sane settings regarding voltage/thermal/clockspeeds have been developed, mainline u-boot/kernel support for H3 improves constantly Igor provided a first useable test image for Orange Pi Plus/PC a few weeks ago (that's still in use here with an Orange Pi PC serving music). And in the meantime he also started to work on combining mainline u-boot with Allwinner's old 3.4.39 kernel -- situation will improve pretty fast. Regarding Orange Pi One/Lite we'll have to see what changed or what software changes are necessary.

If Steven would produce a variant with an external PHY (RTL8211 -- not that expensive) and optional 2 GB RAM that would be the most interesting H3 based board -- at least for me. Since the only other board with these 2 features (the Orange Pi Plus 2) has less available I/O bandwidth (due to a wasted USB port for the ultra-slow GL830 USB-to-SATA bridge) and a useless WiFi module (maybe never supported by mainline kernel). I would believe Xunlong could sell such an OPi PC Plus without all the useless stuff and solely adding GBit Ethernet and an additional GB RAM for $20 if they're able to sell an upcoming Orange Pi One for less than $10 also. BTW: Since a few days an SMP 'hack' is available for Orange Pi PC therefore all 4 CPU cores are already useable: http://pastebin.com/Vj9JYPTn(this is 'fritz' from the orangepi.org forums running his own kernel with Arch Linux)

Correct, http://linux-sunxi.org/Sunxi_devices_as_NAS#Requirements_.2F_which_device_to_choose still applies. If it's about I/O bandwidth the A20 is still the best choice (in Allwinner land, SATA capable SoMs/SBC are also available with Marvell SoCs or i.MX6 -- see link above). If the rumours Olimex spread half a year ago are true we can expect a pin-compatible A20 successor with twice as much CPU cores in the 2nd half of next year. And again H3: this SoC has 4 independent USB ports not just 2 (1 host and 1 dual role) as the octa-core A83T for example or the '64-bit' A64. So if it's really about I/O bandwidth the H3 outperforms these other 'more powerful' easily. Especially if they are combined with ultra-slow USB-to-SATA bridges like the on the Banana Pi M3 (GL830 -- to be avoided!).

Another small update regarding the M3: In SinoVoip's current 'official' forum (time will tell how long it takes until they abandon this and start over with the next one like they did already before) the same question regarding the M3 will be asked again and again "How can i boot from SATA?!". Even via PM again and again. Only by people who aren't willing to accept the only possible answer "You can't. Banana Pi M3 has no SATA". It's that simple: the M3 has no SATA port. Just one single USB port is used to connect all externally available USB ports and a very slow USB-to-SATA bridge through an internal USB hub. It's really that limited. So the question could've be "How can I boot from USB?" instead. And the only valid answer to that is: "Why would you? Are you insane?" Every M3 comes with 8 GB eMMC that is at least twice as fast as the crappy GL830 USB-to-SATA bridge. Storing the rootfs on USB this way means slowing things unnecessarily down. On the M3 your best bet is to boot from eMMC since this is the fastest storage option you have. This is different to other incompatible SBCs that are also called "Banana Pi" that lack eMMC and where you might benefit from the rootfs stored on USB or even SATA (M1). But on the M3 the approach to boot from USB especially using the ultra-slow onboard USB-to-SATA bridge is simply moronic. Next thing: Since it is not SATA but only USB you can never rely on something like 'root=/dev/sda1' since a connected USB thumb drive might be /dev/sda on the next reboot and your rootfs will never be touched since being now /dev/sdb1. To escape from that you've to use partition UUIDs instead. I documented the whole stuff already where it belongs to and won't repeat it here again to prevent uneducated users from doing harm to their installations (again: Booting from USB on the M3 is adopting a strategy suited for different SBCs wrongly). The best strategy to deal with the M3's 'SATA port' is to ignore it. Performance of a connected disk is unnecessarily low (especially writes -- see above) and using the SATA-power connector to power a disk means risking sudden power-offs more often than necessary since the M3 is prone to running in undervoltage/undercurrent situations. It's strongly recommended to turn off every power savings if you try to use a HDD this way since when your M3 is busy and disk spin-up leads to another 1A peak current needed then it's time to pick your solder iron to bypass the crappy micro USB connector unfortunately being used for DC-IN. BTW: I updated my RPi-Monitor template for Banana Pi M3 or let's better say A83T/AXP813 to be able to also monitor the 'cooling states': http://linux-sunxi.org/User:Tkaiser#Preliminary_RPi-Monitor_template_for_A83T If you've installed RPi-Monitor already, it's enough to stop it, then do as root cd /etc/rpimonitor/ && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-A83T.tgz | tar xzf - restart RPi-Monitor, and you're already done (of course you should do this in a two-step process and check the MD5 checksum ef7220daadad5726b32b0d2270d4bffd first)

Now I can since my M3 arrived this noon: It's slow as hell: 13 MB/s write and 23 MB/s read. I will ask whether some Orange Pi Plus users made better experiences (uses also the GL830 but not behind the internal 4-port-USB hub) to confirm this disaster. With mainline kernel and a good USB enclosure you're more than twice as fast and being able to use SATA on A20 boards it's 3.5-10 times the performance (write/read).

Not working as expected: http://forum.banana-pi.org/t/is-sata-working-on-any-of-the-m3-images/776 The GL830 USB-to-SATA bridge used there is the worst choice ever (slow, crappy, obviously with a 2 TB limitation). SinoVoip sends me a review sample and I'll report here soon: https://nolp.dhl.de/nextt-online-public/set_identcodes.do?idc=7214605425 BTW: I started already with a wiki page for this weird device: http://linux-sunxi.org/Banana_Pi_M3