valant

No USB3/PCIE. This makes this board not interesting at all. I think people should wait for Orange Pi 3 (I think 3 Plus may also have also some problem) or Pine H64.
 
P.S. The DRAM chip is branded "Allwinner". (noted by TL Lim)

I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
 
Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.

Because it tries to use (i.e. store and execute the next stage bootloader) DRAM that doesn't work properly?
 
You can try clicking on dram_*.c files here and find something like this, if it explains anything 
 
No, DRAM init code and its configuration has to be provided by bootloader/SPL. SPD is just an additional EEPROM on removable memory modules and it doesn't make much sense to use this for something that is soldered on the same board as the CPU/SoC.

it's hot here

I don't get it, why they advertize it as suitable for H3 boards? H5 boards cannot speak LCD/HDMI or what?
Interesting thingy, definitely, probably I'll buy it someday. But now I have a 21" HDMI capable monitor bought specifically for my "playing" with SBCs.

eBay is not the best place to purchase OPis ...
Xunlong sell them directly (without reseller) thru AliExpress.
https://aliexpress.com/item/Orange-Pi-R1-H2-256MB-Quad-Core-Cortex-A7-Open-source-development-board-beyond-Raspberry-Pi/32827494728.html

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)

Now a real world example showing where you end up with the usual 'benchmarking gone wrong' approach. Imagine you need to set up a web server for static contents only. 100 GB of pure text files (not that realistic but just to show you how important it is to look closer). The server will be behind a leased line limited to 100 Mbits/sec. Which SBC to choose?
 
The usual benchmark approaches tell you to measure sequential transfer speeds and nothing else (which is OK for streaming use cases when DVD images several GB each in size are provided but which is absolutely useless when we're talking about accessing 100 GB of small files in a random fashion -- the 'web server use case'). Then the usual benchmark tells you to measure throughput with iperf (web serving small files is about latency, that's quite the opposite) and some silly moronic stuff to measure how fast your web server is using the loopback interface of your server and test tool on the same machine not testing network at all (how does that translate to any real world web server usage? Exactly: not at all).
 
If we rely on the passive benchmarking numbers and have in mind that we have to serve 100 GB at a reasonable cost we end up thinking about an externally connected HDD and a board with GbE (since iperf numbers look many times faster than Fast Ethernet) and a board that shows the highest page request numbers testing on the local machine (when the whole 'benchmark' turns into a multi-threaded CPU test and has nothing to do with web serving at all). Please don't laugh, but that's how usual SBC comparisons deal with this.
 
So you choose from the list above as storage implementation an external 500 GB HDD since USB performance looks ok-ish with all boards  (+30 MB/s), and NanoPi M3 since iperf numbers look nice (GbE) and most importantly it will perform the best on the loopback interface since it has the most and the fastest CPU cores.
 
This way you end up with a really slow implementation since accessing files is more or less only random IO. The usual 2.5" notebook HDD you use on the USB port achieves less than 100 IOPS (see above result for USB HDD on Banana Pro with UASP incapable enclosure). By looking at iperf performance on the GbE interface you also overlooked that your web server is bottlenecked by the leased line to 100 Mbits/sec anyway.
 
What to do? Use HTTP transport stream compression since text documents show a compression ratio of more than 1:3, many even 1:10, (every modern web server and most browsers support this). With this activated NanoPi now reads the text documents from disk and compresses it on the fly and based on a 1:3 compression ratio we can stream 300 Mbits/sec through our 100 Mbits/sec line. Initially accessing files is still slow as hell (lowest random IO performance possible by choosing USB HDD) but at least once the file has been read from disk it can saturate the leased line.
 
So relying on passive benchmarking we chose a combination of devices (NanoPi M3 + 500 GB HDD) that costs +100$ considering also shipping/taxes and is slow as hell for the use case in question.
 
If we stop relying on passive benchmarking, really look at our use case and switch on our brain we can not only save a lots of money but also improve performance by magnitudes. With an active benchmarking approach we identify the bottlenecks first:
Leased line with 100 Mbits/sec only: we need to use HTTP content-stream compression to overcome this limitation Random access to many files: we need to take care of random IO more than sequential transfer speeds We need to tune our network settings to make the most out of the sitiuation. Being able to use the most recent kernel version is important! We're on a SBC and have to take care of CPU ressources: so we use a web server with minimum ressources and should find a way to avoid reading uncompressed contents from disk to immediately compress it on the fly since this wastes CPU ressources So let's take an approach that would look horribly slow in the usual benchmarks but improves performance a lot: An Orange Pi One together with a Samsung EVO 64 GB as hardware, mainline kernel + btrfs + nginx + gzip_static configuration. Why and how does this work?
Orange Pi One has only Fast Ethernet and not GbE. Does this matter? Nope, since our leased line is limited to 100 Mbits/sec anyway we know that the cheap EVO/EVO+ with 32/64 GB perform excellent when it's about random reads. At 4K we get 875 IOPS (3500 KB/s, see comparison of results), that's 8 times faster than using an external USB HDD we use pre-compressed contents: that means a cron job compresses each and every of our static files and creates a compressed version with .gz suffix, if nginx communicates with browsers capable of that it delivers the already compressed contents directly (no CPU cylces wasted, if we configure nginx with sendfile option not even time in userspace wasted since the kernel shoves the file directly to the network interface!). Combine the sequential read limitation of SD cards on most boards (~23MB/s) with an 1:3 compression ratio and you end up at ~70MB/s with this trick. Twice as fast as uncompressed contents on an USB disk unfortunately we would also need the uncompressed data on disk since some browsers (behind proxies) do not support content compression. How to deal with that? Using mainline kernel, btrfs and btrfs' own transparent file compression. So the 'uncompressed' files are also compressed but at a lower layer and while we now have each and every file twice on disk (SD card in fact) we only need 50 GB storage capacity for 100 GB original contents based on an 1:3 compression ratio. The increase in sequential read performance is still twice as fast since decompression happens on the fly. Not directly related to the filesystem but by tweaking network settings for low latency and many concurrent connections we might be able to improve requests per seconds when many clients access in parallel also by factor 2 compared to an old smelly Android 3.x kernel we still have to use on many SBC (relationship with storage: If we do tune network settings this way we need storage with high IOPS even more) An Orange Pi One together with an EVO 64GB costs a fraction of NanoPi M3 + USB HDD, consumes nearly nothing while being magnitudes faster for the 'static files web server' use case if set up correctly. While the usual moronic benchmarks testing CPU horsepower, GbE throughput and sequential speeds would show exactly the opposite.
 
And you get this reduction in costs and this increase in performance just by stopping to believe in all these 'benchmarking gone wrong' numbers spread everywhere and switching to active benchmarking: testing the stuff that really matters, checking how that correlates with reality (your use case and the average workload) and then setting up things the right way.
 
Final note: Of course an Orange Pi One is not the perfect web server due to low amount of DRAM. The best way to overcome slow storage is to avoid access to it. As soon as files are in Linux' filesystem cache the speed of the storage implementation doesn't matter any more.
 
So having our web server use case in mind: If we do further active benchmarking and identify a set of files that are accessed most frequently we could add another Orange Pi One and a Pine64+ with 2GB. The new OPi One acts as load balancer and SSL accelerator for the second OPi One, the Pine64+ does SSL encryption on his own and holds the most frequently accessed 1.7 GB in RAM ('grep -r foobar /var/www' at startup in the background -- please keep in mind that it's still +5 GB in reality if we're talking about a 1:3 compression ratio. Simply by switching on our brain we get 5GB contents cached in memory on a device that features only 2 GB physical RAM!). And the best: both new boards do not even need local storage since they can be FEL booted from our first OPi One.

Until Rockchip finished the SPL+DRAM init code for RK3328 we have to use the ddr+miniloader blobs to start u-boot, https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh#L48-L77 generates working idbloader.img, uboot.img and trust.img using tools and blobs from the rkbin repo.
The BootROM will look for idbloader.img at 0x40 on SPI/eMMC/SD, and the miniloader will expect uboot.img+trust.img at 0x4000 and 0x6000 on the same device it loaded idbloader.img from, the miniloader before v2.43 had a bug that would always load uboot+trust from eMMC (or possibly SPI).
http://opensource.rock-chips.com/wiki_Boot_option have some details on the boot process.

if some of you guys are still interested, the saphirre board is back in stock in the taobao website, but more expensive now (580CNY).
 

Example from lshw for an UAS capable USB to SATA bridge:
*-usb description: Mass storage device product: USB to ATA/ATAPI Bridge vendor: JMicron physical id: 2 bus info: usb@1:2 logical name: scsi5 version: 81.05 serial: [REMOVED] capabilities: usb-2.10 scsi configuration: driver=uas maxpower=500mA speed=480Mbit/s  
Usually if it doesn't have any bugs (like some GL* controllers), passes trough SMART data and SCSI commands and has UAS capabilities (not blacklisted anywhere), it's good enough and who cares about how exactly it is represented.
 
AFAIK their nature should be interpreted as "devices that implement (a subset of) SCSI". USB BOT hides that nature under the "block device" abstraction, and UAS uses the SCSI command set. I think you can make a controller that would bypass SATA and instead of "storage->SATA->SCSI over USB/UAS" you would get "storage->SCSI over USB/UAS", so exposing their SATA nature is not mandatory.

The more ignorant of those internals you are, the happier your life will be.  I wrote some simple drivers in assembly language for USB 2, and being totally honest, I kind of wish that standard would have sunk to the bottom of the ocean in the late 90's before it hit revision 2.0.
 
USB has some special bus modes to handle mass data traffic (UAS), all data on USB is of a "type", it doesn't easily have a type-agnostic transfer like PCI(e).  If it were exposed as a SATA device, this would be a software layer translating to do so, and would most likely be less efficient.  Now, the experts will know more and (most probably) make me look foolish, but it's part of the job. 

Any of you have such a beautiful problem?
They like Orange Pi's, they are hot !
 
 
 
 

Short update on the 16 GB eMMC in my 14" variant: http://sprunge.us/bHZW (search for 'mmc2:0001', it's oemid: 0x0103, manfid: 0x000088) 
 
Google search for '0x0103 0x000088' found just a few hits (one in Armbian forum, this thing has also been used in Beelink X2). Iozone numbers:
random random kB reclen write rewrite read reread read write 102400 4 3893 4021 20855 20681 13244 3223 102400 16 18059 18444 51219 50298 39452 13805 102400 512 54907 55186 85896 84475 82634 50187 102400 1024 56220 56011 85560 85681 85800 52369 102400 16384 55816 55464 86533 86408 86711 55289 OEM ID points to FORESEE and this link -- is this vendor trustworthy? First two hits when searching for 'oemid 0103' were failure reports and @longsleepalso already reported that the eMMC in his Pinebook was DOA.
 
I've seen eMMC from them only in these Beelink X2 before: eg. http://linux-sunxi.org/File:Beelink_X2_AP6181_Heatpad.jpg or https://forum.armbian.com/uploads/monthly_09_2016/post-1183-0-96913400-1474264138.jpg
 
Edit: FORESEE eMMC is used quite a lot on Chinese gadgets: foresee emmc site:www.cnx-software.com
 
Edit 2: ayufan measured eMMC on a pre-production unit 3 months ago: https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075
 
Edit 3: According to what's silkscreened on the 16 GB module it's 'FORESEE; NCEMBSF9-16G: 01L 1608032589; 1633' -- picture now also available: http://linux-sunxi.org/File:16GB_NCEMBSF9-16G_eMMC.jpg

No hibernation, not even ACPI (this is not an x86 design -- if you want that, choose the sibling but currently both aren't available due to supply chain issues and the 11" panel is unavailable for the next 2 to 3 months). With latest community builds suspend/resume (to RAM) works and I would recommend to use only community release version 0.5 or above (or Armbian soon  )
 
Back to the technical aspects: eMMC is not soldered but replaceable and uses the same mechanical connector as Hardkernel uses for their ODROIDs. So even if it wears out it can be replaced and since boot priority always is 'SD card first' you don't even need that, just get an SD card following the new A1 or A2 specifications then (in a year they should be affordable).
 
Wrt swap:
ubuntu@pinebook:~$ free total used free shared buff/cache available Mem: 2037388 153692 1134912 13424 748784 1834044 Swap: 1018688 0 1018688 1 GB defined, nothing used. I neither fear swapping nor 'hibernation' wrt eMMC longevity but something else. One of the challenges we face with this device will be browsing (which has some pretty high memory requirements and due to the common browsers hammering storage with IO requests can be also considered a storage benchmark on such devices like the Pinebook). We already talked about that: http://irc.pine64.uk --> 03-05-2017 --> search for 'graysky'.
 
I think especially with Pinebook it will get interesting how to intelligently use the DRAM (tmpfs for example without further compression always seems like a waste of ressources to me).

I am new to single board computers and have previously used Microsoft Windows computers or Android TV dongle/box.
 
I do find it a bit odd that everyone seems to be working on their own versions of operating systems.  It would be a bit like Intel coding their own Windows and AMD coding their own version of windows too.
 
Now while people have different aims and software needs it is I think a shame all the different programmers and groups cannot come together more on software.
 
You have the various
 
Linuxs
 
Then all the soc variations.
 
Now Armbian seems a step in the right direction and you have various Socs and SBC computers, it is just a pity Xapple, Lemaker, Banana , Orange etc cannot pull together as well as the various programmers.  
 
Build like Windows etc one operating system that just loads the drivers for the hardware differences and components.  
 
I guess I am just to naive about the way things really are.