Search the Community

Hi all. I've just finished reviewing the Khadas VIM3. It's an amazing SBC with unmatched performance. It's got the Amlogic A311D SoC. Comparable with the S922X of the Odroid N2. But the 4x A73 cores are clocked at 2.2Ghz and the 2 x A53 cores to 1.8Ghz. So it performs a lot better. It also comes with an NPU, MIPI-DSI and MIPI-CSI. And can be powered with USB type-c from 5V up to 20V. Here my review video. Here all my gathered information. Khadas VIM3 ----------- Ubuntu server - fan over fins ----------------------------- Blender BMW no fan thermal pad : 59m with copper shim : 58m18s with 5V fan : 45m01s with 5V fan over CPU : 43m28s Ubuntu XFCE - fan over CPU, not over fins ----------------------------------------- Blender no fan : 55m22s Blender 3V fan : 43m03s Blender 5V fan : 42m51s Blender with fan : 48m45s Armbian Bionic Small cores @1.9Ghz Big cores @1.7Ghz Blender with fan : 46m29s Armbian Disco Small cores @1.9Ghz Big cores @1.7Ghz Blender with fan : 46m56s Armbian Buster Small cores @1.9Ghz Big cores @1.7Ghz Kdenlive 16m bench 3V lxde : 1h09m (using 1GB zram + 4GB swap file. Not enough ram with 2GB) Video playback -------------- Ubuntu ------ Up to 4K 30fps with MPV. Very slight screen tearing. Anything lower is perfect Youtube playback with Firefox up to 1440p 30fps perfect KODI doesn't work (yet) No VPU acceleration for now. All done by CPU. LibreElec --------- Up to 4K 30fps with MPV. Very slight screen tearing. Anything lower is perfect Wifi doesn't work. power consumption ----------------- Idle no fan : 0.27A 5V (governor set to interactive) Maxed out with fan : 1.4A 5V (fan is 0.15A) Temperatures (fan over CPU, not over fins) ------------------------------------------ Idle No fan : 44°C Maxed out No fan : 75°C heavy throttling. 1Ghz small cores / 1.8Ghz big cores Idle 3V fan : 34°C Maxed out 3V fan : 73°C very light throttle. Takes 5min to reach 70°c. +10min to start throttling Idle 5V fan : 32°C Maxed 5V : 70°C no throttling Transfer speeds --------------- eMMC 16GB : 60 MB/s write : 165.9 MB/s read SSD over USB3 : 380.3 MB/s write : 286.1 MB/s read SSD over USB2 : 40.2 MB/s Samsung EVO plus with on-board sd-reader : 10.2MB/s write 22.1MB/s read with USB3 sd-reader : 31.7MB/s write 88.6MB/s read Ethernet internet speed : 53.9 Mbps 11.5 Mbps Wifi internet speed : 43.7 Mbps 11.2 Mbps Issue's ------- When using a 2.4Ghz dongle for mouse in the right USB3 port, wifi connection is slow. When using a USB3 device in the USB3 port wifi stops working. Use left USB2 port for those. Ubuntu server boots/shuts down slower than XFCE version. Shut down stop job for ifup for eth0 (not in use) 1m30s Boot hangs a while. Can't find the reason. After -> Scanning for Btrfs filesystems. Done. about 30s Can't install Tensorflow khadas@Khadas:~/tensorflow$ pip3 install tensorflow-1.8.0-cp35-none-linux_aarch64.whl tensorflow-1.8.0-cp35-none-linux_aarch64.whl is not a supported wheel on this platform. Android : Can't connect wifi. I can type wifi password, but can't go further. No connect button. Tips ---- Use interactive governor for better thermals and power consumption with low use/idle. Plus/Minus ---------- + Best single core performance + best multi-core performance for an ARM SBC + Nice case + PSU + USB-c cable included + remote + eMMC + Amazing low power consumption / best performance per watt + Can be powered with 5V up to 20V + NPU - Wifi issue with USB3/No 5Ghz wifi. Could have solved the USB3 interference - Placing of the buttons would be better on the back. They often get pressed when plugging a USB device. You do get used to it. - No VPU and X11 drivers (yet) - Slow On-board SD-card reader Greetings, NicoD

-

Hi all. I've made a new review video about the Odroid N2. It an amzaing beast of an SBC. But it ain't perfect for everyone. Geetings, NicoD. https://www.youtube.com/watch?v=dylc0GjeyM8 @balbes150 Tanks for the great image.

Hi all. Here my review video of the new Pine H64 model B. I also compare it with the Orange Pi 3, and it's older brother the Rock64. I hope you'll like it. Thank you. Greetings, NicoD

Hi all. I've made a new review video about the Orange Pi 3 with Linux. I've used Armbian Stretch for this video. Here is my video. Here you can find all the data I've gathered. Greetings, NicoD

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case. This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC. Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together. This allows some freedom on the location of the SoC relative to the lid. First off, same nice packaging the Tinker owners are familiar with: The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production The reason for the weight becomes immediately obvious when pulling the two halves apart: All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless. The extrusion is very thick, over 8mm in places. Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately. Something important to notice in this picture: The Tinker sits on aluminum studs, and does not bolt down. The heat sink block holds it in place. I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter: https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/ I can't verify (no hardware), but the holes are 85mm apart and threaded. Board fits nicely: Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem. This would be my only feedback where I think a different option would have been better: The thumbscrew is located at a position so as to be on center with the SoC. This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around. Not a problem for 90% of people, to be honest. In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled. Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet. My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins. Aesthetically it is a very nice looking product, of course I'd say that should be expected. I'll follow with something a bit more empirical later on.

The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM). I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive) Low end 3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951 They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction). Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection) I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks): Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination High end Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here). You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less) What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days) Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time. And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer. Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

Latest RK3399 arrival in the lab. For now just some q&d photographs: @wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here! A quick preliminary specifications list: RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed

Overview: SinoVoip sent me a few days ago a review sample of their new Banana Pi M2+. It's based on Allwinner's H3 SoC and tries very hard to be a 99% clone of Orange Pi Plus/PC. SinoVoip chose to stay compatible to nearly all pin mappings therefore any OS image that works on Orange Pi Plus will also work on BPi M2+ but some things need adjustments. BPi M2+ features GBit Ethernet, eMMC, 2 USB host ports and one USB OTG that do not have to share bandwidth (no internal USB hub used and H3's 3rd USB host port unused unfortunately), Ampak AP6212 to provide WiFI/BT, fortunately no crappy USB-to-SATA bridge, a CSI interface to be used together with an OV5460 5MP camera module and... no programmable voltage regulator for the SoC. Since it's based on the H3 SoC it's incompatible to all other Banana Pi variants and almost everything you can expect is already known. As usual you find the most recent and comprehensive information for any board based on Allwinner SoCs in the linux-sunxi wiki: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B Compatibility: The SoC's pins are routed to the externals exactly like on Orange Pi Plus/PC so it was pretty easy to create a device tree file for mainline kernel by using everything from Orange Pi Plus and replacing USB definitions with the stuff from Orange Pi PC (deleting the usb3 node since not existent) and here we are: Banana Pi M2+ is supported by mainline kernel with working USB, eMMC, GBit Ethernet and WiFi/BT already and as soon as display support and so on are available for H3 BPi M2+ benefits automagically from it. Situation with kernel 3.4 is the same: In Armbian we support the board already since it was just adoption of SinoVoip's settings (and correction where they're horribly wrong -- see below when it's about performance). Since it's 'just another H3 board' software support will progress nicely and maybe the best news: You are not forced to use OS images from SinoVoip since you can rely on the community's work instead (Armbian for example). Documentation and support provided by vendor: To sum it up: still the usual horrible 'SinoVoip experience' we already know. They still don't get why correct information might matter. 'Documentation' is not written by engineers but instead trainees playing 'copy&paste gone wrong'. According to their website the board is either '55mm square' or 65x65mm, features 'Power led, Status led' (in reality just one led), has a 'CAN bus' (wrong for all their last SBCs, this is still moronic copy&paste from the first Banana Pi whose A20 SoC is CAN capable) and so on... you never know whether the information provided there is information or just the usual copy&paste errors they're famous for. It gets even worse when you look into the vendor's so called 'documentation': There the M2+ is most of the times called M3 ("BPI-M2+ USB interface: BPI-M3 have two USB 2.0 interface on board"), the onboard WiFi chip is sometimes AP6212 and sometimes AP6181, according to the 'BPI-M2+ Quick Start' guide you can power the board through USB OTG (not true) and a '3.5mm jack audio' is available (which is also not true) and so on. And they ask you to download OS images from http://www.banan-pi.org (domain does not exist). Any more questions? If you've to rely on their information or support you're already lost since the vendor simply doesn't give a shit about stuff like this. Software provided by the vendor: Since SinoVoip today released an OS image for M2+ -- they call it Raspbian Jessie(debian 8) BPI-M2P (20160408) -- I thought: let's give it a try. Armbian supports this board already but maybe we missed something. OMFG, what a horrible experience! I burned this Raspbian image to a 8GB SD card and booted. Whole boot log as follows: And then I had an installation with zero free space. You can't do anything with it: Filesystem Size Used Avail Use% Mounted on /dev/root 3.9G 3.7G 0 100% / devtmpfs 373M 0 373M 0% /dev tmpfs 501M 68K 501M 1% /dev/shm tmpfs 501M 6.9M 494M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 501M 0 501M 0% /sys/fs/cgroup /dev/mmcblk0p1 256M 45M 211M 18% /boot tmpfs 101M 4.0K 101M 1% /run/user/1000 /dev/mmcblk1p1 7.2G 145M 6.7G 3% /media/pi/3684f9bd-1ea5-4cd0-a75b-b47af6147d77 tmpfs 101M 0 101M 0% /run/user/0 I quickly used Armbian's tools to resize the partition to the maximum and rebooted just to realise that they really use raspbian.org repositories for this OS image (how moronic is it to use ARMv6 code on a H3 board?!). I tried to get RPi-Monitor installed which didn't work out of the box, wasted almost an hour to fix this stuff and then gave up. Since I simply copied our armbianmonitor tool to the installation I gave up on RPi-Monitor and used armbianmonitor instead to monitor temperatures, CPU clockspeed and so on when running a few benchmarks: The bad news: BPi M2+ is a 99% clone of Orange Pi Plus/PC. Why didn't they do a 100% copy but instead chose to f*ck up the missing one percent? The Orange Pi variants all use a programmable voltage regulator to provide the SoC's VDD_CPUX voltage (lower clockspeeds --> lower voltage --> less heat --> more efficient throttling behaviour if SoC starts to overheat). On BPi M2+ the SoC is always fed with 1.3V which prevents best performance with heavy multithreaded workloads. Be prepared that due to this high voltage even throttling down to half of the maximum clockspeed doesn't help that much: This is a not so demanding benchmark running with Armbian settings. Any Orange Pi variant would reduce voltages when reduding clockspeeds which is responsible for less heat emissions and therefore with the very same settings a H3 used on an Orange Pi would still run with 816, 912 or even 960 MHz due to reduced VDD_CPUX voltage where BPi M2+ remains at 648 MHz. SinoVoip not only tried to copy the hardware very closely, they also use loboris' kernel 3.4 sources developed for Orange Pis (Armbian uses a different code base) and they chose to copy the most important mistake Xunlong made so far (the Orange Pi vendor, that developed also the 1st Banana Pi that has been manufactured by SinoVoip from then on). Their throttling settings prefer killing CPU cores instead of throttling if the SoC starts to overheat. This is the main reason why Orange Pi boards get that bad scores on openbenchmarking.org: Since the multithreaded benchmarks increase temperatures that much that CPU cores are killed and never come back. This is exactly what happens with SinoVoip's software settings: I started an usual run of Phoronix Test Suite, the 1st benchmark already killed cpu3, the next one cpu2 and due to their moronic THS settings the maximum clockspeed is 1008 MHz anyway. So a SBC advertised as 'quad core @ 1.2GHz' is already just a 'dual core @ 1.0GHz' when running a few boring benchmarks: [ 2749.050080] CPU Budget:Try to down cpu 3, cluster0 online 4, limit 3 [ 2749.051406] [hotplug]: cpu(0) try to kill cpu(3) [ 2749.052482] [hotplug]: cpu3 is killed! . [ 4575.080090] CPU Budget:Try to down cpu 2, cluster0 online 3, limit 2 [ 4575.081791] [hotplug]: cpu(0) try to kill cpu(2) [ 4575.081853] [hotplug]: cpu2 is killed! . And benchmark results look as expected: The worst combination is SinoVoip hardware combined with SinoVoip software: http://openbenchmarking.org/result/1604082-GA-1604074GA00 We implemented a special corekeeper service especially for M2+ in Armbian two days ago to help recover from killed CPU cores (since we can't prevent this as long as we've to rely on kernel 3.4 and the M2+'s fixed voltage is a real problem). Be prepared that if you run really demanding workloads on the BPi M2+ with their OS images that you end up with a single core board pretty soon. The good news: Since it's 'just another H3 board' trying very hard to be as compatible as possible to the Oranges you benefit automagically from every software effort made by the community. You don't need to use software from SinoVoip, you don't need to rely on their (non existing) support, you simply can use any of the community's stuff. Mainlining efforts are progressing nicely and by simply mixing device tree stuff from Orange Pi Plus and PC I've been able to get the BPi M2+ with working GBit Ethernet and maximum USB throughput running with kernel 4.6. As a reference iozone measurements of a USB connected HDD (UASP capable enclosure which is responsible for better performance with mainline kernel) and the onboard eMMC: 'SinoVoip' 3.4.39-lobo kernel: USB disk: random random KB reclen write rewrite read reread read write 102400 4 6347 8163 8494 8473 506 1603 102400 16 15420 18110 16543 16674 1885 5445 102400 512 23024 33610 32381 32779 23049 23276 102400 1024 17930 30673 23079 24077 23051 24331 102400 16384 22468 35098 34304 34148 34189 35090 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5323 5683 14130 14135 12028 5573 102400 16 17531 18513 34499 34598 31193 17278 102400 512 24868 24626 61687 61697 61581 23991 102400 1024 25134 24949 66979 67180 67140 24553 102400 16384 26165 25950 76265 76649 76701 25931 4.6.0-rc1: USB disk: random random KB reclen write rewrite read reread read write 102400 4 7760 7917 7845 7868 505 1445 102400 16 17647 20568 20593 20945 1945 4729 102400 512 27334 35579 38033 38553 24980 35320 102400 1024 27419 36866 38764 39026 30661 36766 102400 16384 28267 37358 38540 38558 38988 37542 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5233 5708 14953 14951 12650 5916 102400 16 19776 20609 37958 38023 34206 19403 102400 512 26981 27200 78648 78752 77930 26121 102400 1024 27188 27173 78793 78764 78431 26651 102400 16384 27276 27135 79341 79440 79406 27334 Open questions: The board is designed to be used with an OmniVision OV5460 camera module (Xunlong sells a cheap GalaxyCore gc2035 camera module instead). The very same camera module has already been sold for Banana Pi. And the state of the driver prevented any resolutions above 640x480 (video). So unless someone is able to check the state of the drivers the use of this 'superiour' 5MP module is questionable (at least when you try to run the board with Linux -- Android might be a different story) Conclusion: If the price will be competitive this board is worth a look unlike other SinoVoip boards (M2/M3). It's already fully supported by Armbian so there's no need to use any of the crappy OS images the vendor provides (it's easy to use our Armbian build system to create OS images for non Debian based distros, just read the docs!)

The above is a so called 'Banana Pi M2 Berry' I bought yesterday and will return today to get my money back (due to 'Irreführende Werbung' / false advertising) showing most probably the use case this device will be bought by clueless people: To connect a SATA 2.5" disk to it since 'native SATA'. Of course this doesn't work as expected since the board's power design is an absolute fail. The manufacturer already knows what a shit show using Micro USB for DC-IN is. I simply used the same average USB cable I used to demonstrate the problem a few years ago with the original Banana Pi. With an average USB cable the disk does not even spin up but only produces ugly noise (clicks and motor spinning on/off constantly). Check dmesg output at the bottom of http://sprunge.us/FaFL to see how under-voltage shows up in the logs. When the poor disk made ugly noise I measured on pin 2 and 6 (5V/GND) and saw voltage dropping as low as 4.4V which is definitely way too low for a variety of disks. Check with Hardkernel's findings wrt exactly the same issue: 'We found that Seagate 2TB and HGST/Hitachi 1TB HDDs are quite sensitive to the input voltage level while WD 1TB/500GB, Samsung Momentum and Toshiba HDDs are working well even with 4.4Volt input.' Please note that in the above setup I did not use Gigabit Ethernet. GbE significantly increases consumption and then voltage drops even more. In other words: Depending on the USB cable users choose, the PSU/charger, the type of connected disk and additional load on the board the stuff people buy this board for (NAS use cases) will either work or not. Since all the advertisements for this board are misleading the average buyer of this board must be also clueless -- since if he does some research before he wouldn't buy the board. If Armbian starts to support this board we deal with a user base blaming us for the shitty power design of this board (since not understanding stuff like Ohm's law and talking about instable software where it's just under-voltage/hardware) and also why Armbian is incompatible to Raspberries (omxplayer won't work here, raspivid/raspistill don't work, every graphics stuff for Raspberries doesn't work and the users expect 'spoon feed' mode as known from Raspberry Pi forums). Since I had the board already on my desk and the vendor itself is as usual too lazy or too stupid to provide any performance numbers I checked quickly for myself: The USB design of this board is as shitty as DC-IN: all 4 USB receptacles are behind the same USB hub so all have to share bandwidth (the SoC's 2nd real USB2 host port is not used. Responsible board makers in such situations connect only 3 USB receptacles to the hub and the other real USB host port to the fourth USB receptacle so this port doesn't need to share bandwidth and can be used with another disk for example). Here 'lsusb -t' output from me connecting my test USB disk to each of the 4 receptacles. Some CPU/memory performance numbers: https://pastebin.com/gANnaQJ5 (please keep in mind that you need to understand the influence of compiler/OS version to interpret sysbench numbers) Some storage performance made with a good 20AWG rated USB cable between board and my 5V/2A PSU (USB performance shitty since only USB2 and no UAS available with SinoVoip OS images, SATA performance shitty due to Allwinner's SATA implementation being slow): https://pastebin.com/24tTn05L Gigabit Ethernet performance: 654 Mbits/sec in TX direction and 866 Mbits/sec in RX direction (I did not try to tune settings but simply used the stupid SinoVoip defaults). Same shit show as with A20 on the older Bananas: networking is faster in RX direction while with SATA it's the opposite. So in NAS use cases when you need both Ethernet and storage bandwidth at the same time you're always bottlenecked by one of the two): https://pastebin.com/UTT9v9wN Wi-Fi performance not overwhelming (TX 26.6 Mbits/sec, RX 33.5 Mbits/sec, board 1m away from AP), the onboard antenna they use doesn't perform as good as the one on RPi Zero W or RPi 3 (you can't attach an external antenna since SinoVoip's technical documentation consists more or less only of lies like this): https://pastebin.com/AzMtYbFQ The board's advertising consists mostly of lies ('fully compatible to Raspberries and all Raspberry Pi accessories'), same can be said about the 'technical documentation', the hardware vendor doesn't support his own boards (just check the forum: http://forum.banana-pi.org/latest), while the board is already sold they still don't provide schematics (and if they'll provide schematics anytime most probably they cripple them as they did with their R2 board) and the manufacturer also still refuses to merge these pull requests providing tons of security fixes for BPi M2 Ultra and this Berry here. In other words: customers of this hardware must be absolutely clueless to buy it (trusting in false advertising and not doing any research before) while open source developers must even be stupid starting to work on this hardware given the above problems. Final remarks: V40 SoC without heatsink idles at +55°C which seems reasonable verifying with 'thumb test', running heavy loads like cpuminer temperature exceeded 80°C but throttling with SinoVoip's OS image is configured to jump in later. DRAM frequency is not 733 MHz as claimed but 576 MHz max (will be lowered by legacy kernel throttling code at high temperatures and can be read out using /sys/devices/1c62000.dramfreq/devfreq/dramfreq/cur_freq), average load of SinoVoip's OS image never goes below 1 as usual (they really repeat every single mistake with every new board again and again) and if you're unfortunate enough to have bought this poor design you should be aware that on their OS image the first 60 seconds the below process is occupying a single CPU core fully: root@bpi-iot-ros-ai:~# ps auxwww | grep brcm_patchram_plus root 3812 0.0 0.0 3744 548 ? S 15:48 0:00 /usr/bin/timeout 60s /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212/bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1 root 3813 100 0.0 1444 252 ? R 15:48 0:49 /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212 bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1 The PMIC theoretically exposes under-voltage readouts but for whatever reason 0 is the reported value (so 3rd parties trying to support this board and its users can't identify under-voltage situations. This device is a support nightmare with a 2.5" disk connected): root@bpi-iot-ros-ai:~# find /sys -name "*_now" | while read ; do > echo -e "${REPLY}: $(cat "${REPLY}")" > done /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/voltage_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/voltage_now: 0 Will now take the board back to the seller asking to refund me since the claim 'fully compatible to Raspberry Pi' is just a bold lie. Will take a RPi camera with me to show the staff that it's impossible to use RPi accessories like cameras due to different physical FPC connector.

UPDATE: You'll find a preliminary performance overview at the end of the thread. Click here. This is NOT an ODROID N1 review since it's way too early for this and the following will focus on just a very small amount of use cases the board might be used for: server stuff and everything that focuses on network, IO and internal limitations. If you want the hype instead better join Hardkernel's vendor community over there: https://forum.odroid.com/viewforum.php?f=148 All numbers you find below are PRELIMINARY since it's way too early to benchmark this board. This is just the try to get some baseline numbers to better understand for which use cases the device might be appropriate, where to look further into and which settings might need improvements. Background info first ODROID N1 is based on the Rockchip RK3399 SoC so we know already a lot since RK3399 isn't really new (see Chromebooks, countless TV boxes with this chip and dev boards like Firefly RK3399, ROCK960 and a lot of others... and there will be a lot more devices coming in 2018 like another board from China soon with a M.2 key M slot exposing all PCIe lanes). What we already know is that the SoC is one of Rockchip's 'open source SoCs' so software support is already pretty good and the chip vendor itself actively upstreams software support. We also know RK3399 is not the greatest choice for compiling code (use case bottlenecked by memory bandwidth and only 2 fast cores combined with 4 slow ones, for this use case 4 x A15 or A17 cores perform much better), that ARMv8 crypto extensions are supported (see few posts below), that the SoC performs nicely with Android and 'Desktop Linux' stuff (think about GPU and VPU acceleration). We also know that this SoC has 2 USB3 ports and implements PCIe 2.1 with a four lane interface. But so far we don't know how the internal bottlenecks look like so let's focus on this now. The PCIe 2.1 x4 interface is said to support both Gen1 and Gen2 link speeds (2.5 vs. 5GT/s) but there was recently a change in RK3399 datasheet (downgrade from Gen2 to Gen1) and some mainline kernel patch descriptions seem to indicate that RK3399 is not always able to train for Gen2 link speeds. On ODROID N1 there's a x1 PCIe link used configured as either Gen1 or Gen2 to which a dual-port SATA adapter is connected. The Asmedia ASM1061 was the obvious choice since while being a somewhat old design (AFAIK from 2010) it's cheap and 'fast enough' at least when combined with one or even two HDD. Since the PCIe implementation on this early N1 dev samples is fixed and limited we need to choose other RK3399 devices to get a clue about PCIe limitations (RockPro64, ROCK960 or the yet not announced other board from China). So let's focus on SATA and USB3 instead. While SATA on 'development boards' isn't nothing new, it's often done with (sometimes really crappy) USB2 SATA bridges, recently sometimes with good USB3 SATA bridges (see ODROID HC1/HC2, Cloudmedia Transformer or Swiftboard) and sometimes it's even 'true' SATA: Allwinner A10/A20/R40/V40 (many SBC) AM572x Sitara (eg. BeagleBoard-X15 with 1 x eSATA and 1 x SATA on Expansion header) Marvell Armada 38x (Clearfog Base, Clearfog Pro, Helios4) Marvell Armada 37x0 (EspressoBin) NXP i.MX6 (Cubox-i, the various Hummingboard, versions, same with Wandboard and so on) All the above SoC families do 'native SATA' (the SoC itself implements SATA protocols and connectivity) but performance differs a lot with 'Allwinner SATA' being the worst and only the Marvell implementations performing as expected (+500 MB/s sequential and also very high random IO performance which is what you're looking after when using SSDs). As Armbian user you already know: this stuff is documented in detail, just read through this and that. RK3399 is not SATA capable and we're talking here about PCIe attached SATA which has 2 disadvantages: slightly bottlenecking performance while increasing overall consumption. N1's SATA implementation and how it's 'advertised' (rootfs on SATA) pose another challenge but this is something for a later post (the sh*tshow known from 'SD cards' the last years now arriving at a different product category called 'SSD'). Benchmarking storage performance is challenging and most 'reviews' done on SBCs use inappropriate tools (see this nice bonnie/bonnie++ example), inappropriate settings (see all those dd and hdparm numbers testing partially filesystems buffers and caches and not storage) or focus only on irrelevant stuff (eg. sequential performance in 'worst case testing mode' only looking at one direction). Some USB3 tests first All SSDs I use for the test are powered externally and not by N1 since I ran more than one time in situations with board powered SSDs that performance dropped a lot when some sorts of underpowering occured. The 2 USB3 enclosures above are powered by a separate 5V rail and the SATA attached SSDs by the dual-voltage PSU behind. As expected USB3 storage can use the much faster UAS protocol (we know this from RK3328 devices like ROCK64 already which uses same XHCI controller and most probably nearly identical kernel) and also performance numbers match (with large block and file sizes we get close to 400 MB/s). We chose iozone for the simple reason to be able to compare with previous numbers but a more thorough benchmark would need some fio testing with different test sets. But it's only about getting a baseline now. Tests done with Hardkernel's Debian Stretch image with some tweaks applied. The image relies on Rockchip's 4.4 BSP kernel (4.4.112) with some Hardkernel tweaks and I adjusted the following: First set both cpufreq governors to performance to be not affected by potentially wrong/weird cpufreq scaling behaviour. Then do static IRQ distribution for USB3 and PCIe on cpu1, cpu2 and cpu3 (all little cores but while checking CPU utilization none of the cores was fully saturated so A53@1.5GHz is fine): echo 2 >/proc/irq/226/smp_affinity echo 4 >/proc/irq/227/smp_affinity echo 8 >/proc/irq/228/smp_affinity To avoid CPU core collissions the benchmark task itself has been sent to one of the two A72 cores: taskset -c 5 iozone -e -I -a -s 100M -r 1k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Unfortunately currently I've only crappy SSDs lying around (all cheap consumer SSDs: Samsung EVO 840 and 750, a Samsung PM851 and a Intel 540). So we need to take the results with a grain of salt since those SSDs suck especially with continuous write tests (sequential write performance drops down a lot after a short period of time). First test is to determine whether USB3 ports behave differently (AFAIK one of the two could also be configured as an OTG port and with some SBC I've seen serious performance drops in such a mode). But nope, they perform identical: EVO840 behind JMS567 (UAS active) on lower USB3 port (xhci-hcd:usb7, IRQ 228): random random kB reclen write rewrite read reread read write 102400 1 6200 6569 7523 7512 4897 6584 102400 4 23065 25349 34612 34813 23978 25231 102400 16 78836 87689 105249 106777 78658 88240 102400 512 302757 314163 292206 300964 292599 321848 102400 1024 338803 346394 327101 339218 329792 351382 102400 16384 357991 376834 371308 384247 383501 377039 EVO840 behind JMS567 (UAS active) on upper USB3 port (xhci-hcd:usb5, IRQ 227): random random kB reclen write rewrite read reread read write 102400 1 6195 6545 7383 7383 4816 6518 102400 4 23191 25114 34370 34716 23580 25199 102400 16 78727 86695 104957 106634 76359 87610 102400 512 307469 315243 293077 302678 293442 321779 102400 1024 335772 336833 326940 339128 330298 350271 102400 16384 366465 376863 371193 384503 383297 379898 Now attaching an EVO750 (not that fast) that performs pretty identical behind the XHCI host controller and the JMS567 controller inside the enclosure: EVO750 behind JMS567 (UAS active) on lower USB3 port (xhci-hcd:usb7, IRQ 228): random random kB reclen write rewrite read reread read write 102400 1 6200 6569 7523 7512 4897 6584 102400 4 23065 25349 34612 34813 23978 25231 102400 16 78836 87689 105249 106777 78658 88240 102400 512 302757 314163 292206 300964 292599 321848 102400 1024 338803 346394 327101 339218 329792 351382 102400 16384 357991 376834 371308 384247 383501 377039 (so USB3 is the bottleneck here, especially with random IO an EVO840 is much much faster than an EVO750 but here they perform identical due to the massive USB protocol overhead) Let's try both USB3 ports at the same time First quick try was a BTRFS RAID-0 made with 'mkfs.btrfs -f -m raid0 -d raid0 /dev/sda1 /dev/sdb1'. Please note that BTRFS is not the best choice here since all (over)writes with blocksizes lower than btrfs' internal blocksize (4K default) are way slower compared to non CoW filesystems: random random kB reclen write rewrite read reread read write 102400 1 2659 1680 189424 621860 435196 1663 102400 4 21943 18762 24206 24034 18107 17505 102400 16 41983 46379 62235 60665 52517 42925 102400 512 180106 170002 143494 149187 138185 180238 102400 1024 170757 185623 159296 156870 156869 179560 102400 16384 231366 247201 340649 351774 353245 231721 That's BS numbers, let's forget about them. Now trying the same with mdraid/ext4 configuring a RAID 0 and putting an ext4 on it and... N1 simply powered down when executing mkfs.ext4. Adding 'coherent_pool=2M' to bootargs seems to do the job (and I created the mdraid0 in between with both SSDs connected through SATA) random random kB reclen write rewrite read reread read write 102400 4 25133 29444 38340 38490 23403 27947 102400 16 85036 97638 113992 114834 79505 95274 102400 512 306492 314124 295266 305411 289393 322493 102400 1024 344588 343012 322018 332545 316320 357040 102400 16384 384689 392707 371415 384741 388054 388908 Seems we're talking here already about one real bottleneck? We see nice improvements with small blocksizes which is an indication that RAID0 is doing its job. But with larger blocksizes we're not able to exceed the 400MB/s barrier so it seems both USB3 ports have to share bandwidth (comparable to the situation on ODROID XU4 where the two USB3 receptacles are connected to an internal USB3 hub which is connected to one USB3 port of the Exynos SoC) Edit: @Xalius used these results to look into RK3399 TRM (technical reference manual). Quoting ROCK64 IRC:

[update 12/2017 at bottom] Possibly late, but I would like to put everything we know in one place for anyone who might think of buying this board. Overview: This is a form factor and (mostly) I/O clone of the Raspberry Pi 3 with a much more powerful quad-core Cortex-A17 Rockchip rk3288. It supports HDMI 2.0, has 2 GB RAM, Gigabit Ethernet, Wifi and BT on board, etc: https://www.asus.com/us/Single-Board-Computer/Tinker-Board/ As numerous other sites have covered all the typical performance metrics and extolled the power and so forth of this board, I'm going to go ahead and give you the less exciting information and the tradeoffs/problems. Mainline: Getting the mainline kernel to boot on this machine was pretty straightforward, mainline support for the hardware, including WiFi, makes for less patching and allows a lot of functionality from the mainline kernel without excessive patching. That said, so far Bluetooth and squashing a reboot bug have not been successful (I'm under the impression the rk3288 was never truly intended to boot solely from external sdmmc devices) Important Hardware Considerations: Power Solution: This board is equipped with a micro-USB connector as it's power input. Micro-USB is only rated for 1.8 Amps, no matter how big the numbers on your power supply are. It is entirely possible, even likely, that you will hang this board by plugging in peripherals to the USB 2 slots. Micro-USB is a terrible method of providing power to a single board computer, and is the most serious problem with this device. This device should be powered via the GPIO header using a filtered supply if you wish to have any semblance of stability. Heat: The rk3288 is not a low-power chip, and the heat sink supplied (pictured above), is not adequate for any CPU-intensive activity, quickly throttling performance when it gets too hot. USB throughput: I have not empirically tested this, mostly because it is unnecessary. For some reason the 4 USB 2.0 ports on the board are all routed through a single USB Hub as on the Raspberry Pi. Not incredibly useful, other than not having to buy an external hub to make the one exposed USB port into 4. (unless of course those devices use power, then you need a powered hub anyway) In case you are wondering, there are 2 USB2 ports available on the SoC, however the dev team for this board decided to dedicate one to an "HD Audio codec" instead of using the dedicated I2S/PCM output to do that job. Undocumented pins: The 4 pin header next to the micro-USB power serve no documented purpose. One pair is definitely the power button as references in the device tree for the board, I've determined (and have seen others likewise verify) that the pins closest to the edge are the power button input. The other is not documented at all, and I've not wanted to tempt fate by shorting it out. Software/Support Considerations: The Documentation for this board is terrible. Incomplete, non-existent, etc. The Official ASUS image is a series of workarounds and, until release 1.6, was not properly available to the community. Even then, development does not appear to be occurring publicly (if it is that means development has stopped). Rockchip representatives (seemingly not the ones working on the Tinker Board) have at least come forward to provide some helpful hints concerning issues, but ASUS has been entirely silent. My opinion after use/development: This is a very powerful board. Unfortunately I had to build an adapter to power it over GPIO so it would run properly with any moderately demanding USB peripherals, I added a larger heat sink to stabilize the thermal situation, and am currently trying to find a way to get the board to reset properly without using what the Tinker Board source code itself labels a "HACK". I can not recommend this board to a new buyer. It's a shame, really, this board had every opportunity to be a really good solution. If the prospective buyer wants nothing more than a 4K media player, there are other options that will serve that niche better, including a small mountain of inexpensive TV boxes. This board is not ideal for a NAS due to the USB Hub (unless you want to test the limits of the SD card interface). CPU intensive operations will throttle the device to under 1 GHz with the factory cooler, so without modification you are limited there. Powering peripherals through the board is simply not possible out of the box due to the Micro-USB power solution. Powering through GPIO is the only sane option. Raspberry Pi compatibility is not absolute. The GPIO libraries (WiringPi, etc) are not exact, some of the pins serve multiple purposes on the header, etc. This board may be adequate as a small kiosk linux desktop, it is fast enough to provide a snappy interface, and will fit in many of the available cases for the RPi. I would still recommend GPIO power and probably improved cooling in case a lot of video/etc are needed. [update] I've been running the Tinker Board as a daily driver for over a week, powering it via micro USB with my normal peripherals (mouse/keybd, wireless active, touchscreen attached) My findings are what would be expected: Power supplied to micro USB port: 5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port: 4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop. Now, you might be saying "I run my Tinker on micro USB all the time and don't have any issues" You're right, and you're wrong all at once. The processor/RAM use much lower voltages provided by the RK808 PMIC, so the system doesn't fold up and crash when the input voltage gets too low. HOWEVER, here is a snippet from my dmesg: What you're seeing here is my little wireless mouse receiver giving up the ghost because of voltage starvation. More or less, when I get these voltage dips, anything that needs 5 volts (like USB peripherals, say that external HDD, webcam, card reader, mouse) shut down and/or could be damaged/corrupted. I have not had a single system failure, however were I to be reading/writing external media (or running this off of a flash drive for some reason) I'd have experienced some real problems.

ODROID HC1 Mini Review ODROID XU4 is one of the most powerful boards Armbian supports (due to being a big.LITTLE design with 4 x A15@2GHz and 4 x A7@1.4GHz). Though the SoC is a bit old performance is still impressive, the SoC features 2 independent USB3 ports (on XU3/XU4 one is connected to an USB Gigabit Ethernet chip, the other to an internal USB3 hub providing 2 USB3 receptacles) but in the past many users had troubles with USB3 due to cable/connector problems (the USB3-A receptacle specification/design is a total fail IMO, unfortunately we've still not USB-C everywhere) underpowering problems with Hardkernel's Cloudshell 1 or XU4 powered disk enclosures and also some real UAS issues with 4.9 kernel (UAS --> USB Attached SCSI, a way more efficient method to access USB storage compared to the old MassStorage protocol) Hardkernel's answer to these issues was a stripped down XU4 version dropping the internal USB hub, display and GPIO support but adding instead a great performing and UAS capable USB-to-SATA bridge (JMS578) directly to the PCB so no more cable/contact issues, no more underpowering and no more UAS hassles with some disk enclosures (that contain a broken SATA bridge or combine a working UAS capable chip with a branded/broken firmware). Thanks to Hardkernel I received a developer sample a week ago and could test/optimize already. I skip posting nice pictures and general information since as usual everything available at CNX already: just take a look here and there (especially take the additional hour to read through comments!). So let's focus on stuff not already covered: On the bottom side of the PCB in this area the Exynos 5422 SoC is located and attached with thermal paste to the black aluminium enclosure acting as a giant heatsink. While this works pretty well the octa-core SoC also dissipates heat into the PCB so if you plan to continously let this board run under full load better check temperature of the SD card slot if you're concerned about the temperature range of the SD card used Green led used by JMS578, starts to blink with disk activity and might be better located next to SD card slot on a future PCB revision for stacked/cluster use cases Blue led used as heartbeat signal by default (adjustable --> /sys/class/leds/blue/trigger but only none, mmc1 and heartbeat available, no always-on) Red led (power, lights solid when board is powered on) Drilled hole to fix a connected 2.5" disk. I didn't find a screw of the necessary length -- few more mm are needed than normal -- so I hope Hardkernels adds one when shipping HC1 to securely mount disks (7mm - 15mm disk height supported) Not an issue (was only one for me)! Hardkernel responded: 'We’ve been shipping the HC1 with a machine screw (M3 x 8mm) except for several early engineering samples. So all new users will receive the screw and they can fasten the HDD/SSD out of the box.' In my tests I found it a bit surprising that position of the heatsink fins doesn't matter that much (one would think with heatsink fins on top as shown on the right above reported temperatures would be a lot lower compared to the left position but that's not the case -- maybe 1°C difference -- which is also good news since the HC1 is stackable). The whole enclosure gets warm so heat disspation works really efficient here and when running some demanding benchmarks on HC1 and XU4 in parallel HC1 always performed better since throttling started later and was not that aggressive. I had a few network problems in my lab the last days but could resolve them and while testing with optimal settings I decided also to move the usb5 interrupt (handling the USB3 port to which the USB Gigabit Ethernet adapter on ODROID XU3/XU4/HC1/HC2/MC1 is connected) from cpu3 (little) to cpu7 (big core): As a quick comparison performance with same OS image but with XU4 and same SSD in an external JMS576 enclosure this time: Tested with our Armbian based OMV image, kernel 4.9.37, ondemand cpufreq governor (clocking little/big cores down to 600 MHz when idle and allowing 1400/2000 MHz under full load), some ondemand tweaks (io_is_busy being the most important one) and latest IRQ affinity tweak. The disk I tested with is my usual Samsung EVO840 (so results are comparable with numbers for other Armbian supported devices -- see here). When combining HC1 with spinning rust (especially with older notebook HDDs) it's always worth considering adjusting cpufreq settings since most HDDs aren't that fast anyway so you could adjust /etc/default/cpufrequtils and configure there for example 1400 MHz max limiting also the big cluster to 1.4 GHz max which won't hurt performance with HDDs anyway but you'll have ~3W less consumption with full performance NAS workloads. While this is stuff for another review it should be noted that DVFS (dynamic voltage frequency scaling) has a huge impact on consumption especially with higher clockspeeds (allowing the cores to clock down to 200 MHz instead of 600 MHz somewhat destroys overall performance but saves you only ~0.1W on idle consumption while limiting the big cluster's maximum cpufreq from 2000 MHz down to 1400 MHz saves you ~3W under full load while retaining same NAS performance at least when using HDDs). Also HDD temperature is a consideration since the giant heatsink also transfers some heat back into a connected disk though with my tests this led to a maximum increase of 7°C (SSD temperature read out via SMART after running a heavy benchmark on HC1 comparing temperatures on SSD attached to HC1 and attached to a XU4 where SSD was lying next to the board). People who want to run other stuff on HC1 in parallel might think about letting Ethernet IRQs being handled by a little core again (reverting my latest change to move usb5 interrupts from cpu3 to cpu7) since this only slightly affects top NAS write performance while leaving the powerful big cores free to do other stuff in parallel. IRQ/SMP/HMP affinity might become a matter of use case on HC1 so it's not easy to find settings that work perfect everywhere. To test through all this stuff in detail and to really give good advises wrt overall consumption savings I lack the necessary equipment (would need some sort of 'smart powermeter' that can feed the results in my monitoring system) so I'll leave these tests for others. So let's finish with first preliminary conclusions: HC1 is a very nice design addressing a few of XU3/XU4 former USB3 issues (mostly related to 'hardware' issues like cable/contact problems with USB3-A or underpowering) Heat dissipation works very well (and combining this enclosure design with a huge, slow and therefore silent fan is always an option, Hardkernel evens sells a large fan suitable for 4 HC1 or MC1 units) The used JMS578 bridge chip to provide SATA access is a really good choice since this IC does not only support UAS (USB Attached SCSI, way more efficient than the older MassStorage protocol and also the reason why SSDs perform twice as fast on HC1 now with 4.x kernel) but also SAT ('SCSI / ATA Translation') so you can make use of tools like hdparm/hdidle without any issues and also TRIM (though software support is lacking at least in 4.9 kernel tested with) Dealing with attached SATA disks is way more reliable than on other 'USB only' platforms since connection/underpowering problems are solved Only downside is the age/generation of the Exynos 5422 SoC since being an ARMv7 design it's lacking for example 'ARM crypto extensions' compared to some more recent ARM SoCs which can do stuff like AES encryption a lot more efficient/faster Almost forgot: Software support efforts needed for HC1 (or the other variants MC1 or HC2) are zero since Hardkernel kept everything 100% compatible to ODROID XU4 Edit: Updated 'screw situation' after Hardkernel explained they ship with an M3/8mm screw by default

Anyone ever dealt with OpenMediaVault (OMV) on SBC? Great piece of software but pretty slow, right? One of the many reasons why that happened are outdated crappy kernels and bad settings. I looked at an OMV image for A20 based boards like Banana Pi Pro recently, ended up here http://simplenas.com/download/bananas-simple-system and simply thought: Are you kidding me? Your stable release is based on horribly outdated Debian Wheezy, a kernel 3.4.something and a 2.x OMV release?! What a mess... Igor had an OMV install routine since a long time in his Debian-micro-home-server post-processing script but since an Armbian user evaluated using Armbian's build system to generate OMV images we thought... why not integrating it in Armbian? We started yesterday to prepare all kernels for the Ethernet equipped boards to meet the OMV requirements (just Quota/ACL/NFS stuff) and then played around with an installation routine that can be used from our image customization script to generate OMV images without the need to tamper with them manually later (one of Armbian's design goals). A first preview is now available. All that's needed to create a fresh OMV image from scratch is checking out Armbian build system as outlined in the docs and then use the new customize-image.sh.template as userpatches/customize-image.sh, uncomment the InstallOpenMediaVault line and then create an Debian Jessie Armbian image that will be a full OMV 3 release afterwards. This will take some time but then you have an OS image that can be booted on your device of choice, needs 2-3 minutes for housekeeping (finishing the installation -- network connection required!), reboots and will then be accessible through http://openmediavault.local (if your router's DHCP server is not broken then http://openmediavault will also work). No need to use any smelly OMV images you find in dark corners of the Internet. Just create one yourself if needed or ping your hardware vendor of choice to look into the possibilities he gets when relying on a solid foundation for creating OS images. Quick performance test with the beefiest device we currently support (Solid-Run's Clearfog Pro): 86/98 MB/s (write/read) over a wired connection isn't that bad but with other/slower devices we've seen that there's some room for improvement. I will join openmediavault forum soon to discuss stuff there. Especially that Armbian's cpufreq scaling settings get overwritten (/etc/defaults/cpufrequtils) is a bad thing since the settings OMV uses are ok for x86 boxes but not for those small SBC. All quick tests looked good. I tried hard to destroy configurations on OrangePi Plus 2E, Banana Pi Pro, Clearfog Pro and Pine64+... but to no avail. Even nasty things like creating btrfs stripes on the command line (USB3+SATA with kernel 4.10) and then importing into OMV worked flawlessly, Armbian's nand-sata-install mechanism executed while OMV running to transfer the installation to a SATA disk worked and even downgrading the above btrfs stripe to 4.4.59 and moving the USB3 connected disk out of its enclosure and behind an ASM1062 PCIe SATA controller worked flawlessly (though performance sucks for whatever reasons). I'm pretty impressed by OMV No need to fiddle around with the command line, everything can be configured through a browser... nice. This is how the interface looks like:

With USB camera and Bluetooth headset, mouse and keyboard.

Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong. The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning. Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus'). The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub") In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs). The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably. Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below. Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki. Getting started To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery) In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!) Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well) On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair: If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI). Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me. I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!) Consumption/temperatures in headless mode: The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC. Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores: 240 MHz: not exceeding 2.0W, 25°C above ambient temperature 600 MHz: not exceeding 2.5W, 32°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50°C above ambient temperature 2 CPU cores deactivated and testing again: 240 MHz: not exceeding 1.9W, 23°C above ambient temperature 600 MHz: not exceeding 2.1W, 29°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40°C above ambient temperature The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense. Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed. Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago. Camera module Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module: The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion. Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz) For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy. Other use cases Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely: OpenELEC HW accelerated video decoding RPi-Monitor I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums. All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot: cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.

The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown. Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One The most important differences between One and PC as follows: Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store. So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer. The Orange Pi PC fits exactly: And that's how it looks with the One: You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180° rotation). Different voltage regulator and the consequences: Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity. Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC. On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board). Fex/script.bin fixes necessary when using OS images for PC: When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this: [ARISC ERROR] :message process error [ARISC ERROR] :message addr : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr : 2 [ARISC ERROR] :message type : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment. So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values. How does voltage switching works on the One? So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state: pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same: pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read: pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important. Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues. Final chapter: Software support for the Orange Pi One: First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too. In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!) Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One) It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time. And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working. EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress.

Clearfog PRO with R1 in the back After a day of playing, I am running full featured Armbian, Debian Wheezy, built with Armbian script from sources. We had to fix few things in U-boot and upgraded kernel to .82 but generally it was easy to boot the board. Of course SolidRun also provide some basic images. Three(3) phys, USB and PCI is detected in kernel 3.10.82 - I don't have much hardware to plug in so I can't do much tests at this point. There is no CPU governor (yet?), so I assume it's running full speed (1.6Ghz) all the time. There are dip switches on the board to set cpu / dram speed ... ____ _ __ / ___| | ___ __ _ _ __ / _| ___ __ _ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |___| | __/ (_| | | | _| (_) | (_| | \____|_|\___|\__,_|_| |_| \___/ \__, | |___/ Welcome to ARMBIAN (Debian wheezy 3.10.94-marvell) Last login: Sat Jan 9 10:11:28 2016 from desktop Load: 0.00, 0.01, 0.05 - Board: 64.6°C - Memory: 973Mb root@armada:~# Waiting for: I decided to drop idea to put an AC card into the board since it's simply too problematic and expensive (66USD). This card doesn't have support in legacy kernel, in 4.4 have no idea if everything else already works + I have only one AC device in the lab. The Wireless card I choose is not fresh new but it's cheap (14USD) and reported working on Linux: Atheros AR5BXB112 AR9380 450Mbps. If I get stability and around real 300Mbps is good enough. M2 drive. I'll put one 128G INSSD128GM.26M2242 TRANSCEND MTS400 128GB SSD SATA3 M.2 2242 TS128GMTS400 which should be big enough for most cases. Mpci2sata for one ordinary SATA. SFP module. Haven't found the proper one yet. With Armbian tools it's possible to build (I collect and fix all patches) and should be possible to boot kernel 4.3.3 and 4.4 - next. Network performance (over TP link switch). Windows desktop -> Clearfog [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec [ 3] 0.0-10.0 sec 1.07 GBytes 922 Mbits/sec [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec Clearfog -> Windows desktop [ 4] 0.0-10.0 sec 1.04 GBytes 889 Mbits/sec [ 5] 0.0-10.0 sec 1.02 GBytes 878 Mbits/sec [ 4] 0.0-10.0 sec 1.03 GBytes 882 Mbits/sec To be continued ... Edit #1: Board boots with 4.3.3 / Eth: no, USB: yes, mPci: yes Edit #2: Jessie image download Edit #3: Legacy kernel upgraded to 3.10.94 Edit #4: Network performance Edit #5: If eth0 connected to gigabit, + cca. 2°C more heat on CPU in idle Edit #6: mSATA is working with patched U-boot Edit #7: mSATA and mPCI can be enabled in any combination. Tested one wireless card ... Edit #8: boot time when installed to low performance 32Gb mSATA, power -> Login prompt <= 10s, (-3s waiting at u-boot) = cca. 7sec Edit #9: I2C working out of the box. Tested with display, communication is slow. Perhaps only the settings Edit #10: USB somehow buggy on current legacy kernel. I was trying to use Temper to collect temperature ... it worked once, next reading hang the device and I need to unplug / plug. Haven't debug. USB flash memory working normal. Edit #11: Added cpu freq scalling 800/1600Mhz -> less heat in idle Edit #12: Kernel 4.3.3 & 4.4 / Eth: yes, USB: yes, mPci: yes, mSata: yes ... and doing preliminary testing with Atheros AR9380 N wireless card // Kernel not ready yet Edit:#13: Added mSATA to SATA card, patch a driver to unlock cheap - (consumer grade!, 13 USD shipped) AR9380 AR5BXB112 wireless card to operate at 5Ghz. Running STABLE Edit:#14: Booting from m2 120G SATA drive Edit:#15: Measuring temperature on the edge of heatsink = 39-42 while ambient is around 20. Edit:#16: Added external 2.5 inch mechanical SATA drive powered from Clearfog +5V from header

Here is a list of Tech watch links, feel free to add useful links please. News Single Board Computers and Virtual Private Servers CNXSoft Embedded Systems News Orange Pi facebook group YouTubers MickMake GreatScott EEVblog kicker22004 Brian Greul David Watts Kaspars Dambis