Igor_K

As NAS the Hardkernel Odroid HC-1 (for 2.5") or HC-2 (for 3.5") seems to be for me a good choice at this time

HC-1:
https://www.hardkernel.com/main/products/prdt_info.php?g_code=G150229074080
HC-2:
https://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472

Armbian HC-1/HC-2:
https://www.armbian.com/odroid-hc1/

Anyone catching the irony to keep Micro USB for powering? Guess it all depends on your target audience...

Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.
 
 

Just to have some sort of comparison to x86 based SBC I benchmarked my UP Board (lying in the drawer for years) right now:
 
As can be seen the Intel Atom x5-Z8300 CPU will be outperformed by an RK3399 or even an el cheapo NanoPi Fire3 pretty easily: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
 
Onboard eMMC performance (16GB on my model) also not that impressive (random IO ok, but sequential write performance below SD card level at just ~20 MB/s):
Internal 32 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 2959 3431 16319 16706 11944 3400 102400 16 6710 6162 23026 23813 21143 6775 102400 512 15525 20512 100141 97841 98877 20622 102400 1024 20925 21024 102145 105088 100305 17150 102400 16384 20425 20749 106923 107996 108337 20844 1024000 16384 18512 19994 106359 106060 103988 20007 I backed this board in the beginning to check it with NAS usage in mind but never managed to attach fast storage since UP Board (just like LeMaker's Guitar back then) uses the crappy Micro-B USB3 receptacle (designed for OTG/device and not host mode -- you need an UEFI update and a special cable to be able to attach USB3 SuperSpeed peripherals to this board).
 
BTW: kernel situation as crappy as with a lot of ARM boards (or maybe the board now fully works also with mainline kernel -- I don't know). At least the official kernel enabling majority of board features is a 4.9.45 that received zero fixes for over a year now: https://github.com/emutex/ubilinux-kernel

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

It is already in the friendlyelec shop to buy!

Ok, so it's confirmed:
 
Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
 
If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

Well, then I would prefer to use ODROID design since the NAS case for NEO/NEO2 unfortunately does not attach the SoC to the enclosure to efficiently dissipate heat away.
 
(still waiting for someone designing a RK3399 'NAS board' with a JMS561 attached to each USB3 port to provide 4 SATA ports for spinning rust and a M.2 key M slot for a fast NVMe SSD or alternatively something like this to provide another 4 SATA ports)

Not the final version.

 
Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector  will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.

Aliexpress and FriendlyELEC? Usually not a good idea unless you want to pay more for no reason: https://aliexpress.com/item/NanoPi-K2-Development-Board-Quad-core-Cortex-A53-1-5GHz-WiFi-Bluetooth-USB-Cable-RC100-Remote/32813030887.html vs. 
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=186
 
Those Amlogic SoCs support ABFC so 'raw' memory bandwidth is not that much of an issue. Another comparison between S905 and S905X: http://www.stane1983.com/index.php/2017/08/18/some-thoughts-on-amlogic-part-2/
 
In case it's not known already: https://fosdem.org/2018/schedule/event/kodi/attachments/slides/2166/export/events/attachments/kodi/slides/2166/FOSDEM_Presentation_2018___Lukas_Rusak.pdf

I answered on my phone earlier, thread with benchmark: 
 

I am going to call the K2 I have a "close enough" to C2 board (both are Amlogic gxb dev boards in Pi form factor).
 
I would say that today, right this second that the switch would not be a great one in the case of either board.  That said, I only support/work with mainline kernels, and an RFC patchset has just been submitted for review to enable the video decoder hardware.  With that and the Mali driver you'd have a superior solution to the RPi in either case, hands down.  
 
As to the board vs board situation:
 
Le potato is lacking GbE, wifi.  It is, however, not incredibly expensive and has quite impressive memory performance compared to the C2. (Benchmarking thread has details).  That will be important for 4k video.
 
The C2 is the only Amlogic based device on the market that does not lie about it's current clock speed.  This has to do with some ugly history and past claims of "2.0 GHz" operation.  There is a whole thread here somewhere talking about clockspeed cheating.  As an HTPC that's not as important, and RPi is guilty of it as well, if not even worse depending on the board.
 
With the hardware support in mainline maturing so quickly, I'd guess the Amlogic devices will be a good bet for that use case very soon.  If you want wifi and GbE you'll want a C2/K2, if you want faster memory for potentially smoother playback go Le Potato.
 

You could easily do that with any SBC discussed in this forum, e.g. k1plus dual screen + bluetooth keyboard, or a zero plus 2 h5, 5 inch hdmi + bluetooh keyboard, or a pi zero with double 18650 batteries and a 2.4" screen
 

Another one: https://forum.pine64.org/showthread.php?tid=6288
 

 
What can be seen at the enclosure top is a L shaped rail to be combined with thermal pads to dissipate heat away from SoC (and DRAM most probably too?) to the enclosure top cover. I think on this prototype the height of the rail is not sufficient but hey... it's a prototype most probably to check position of this rail thing (if you check the post carefully you see that it's designed for more than one board  )

@guidol has a good looking case mentioned in the NanoPi K1+ thread:
 
 
 
 

I must admit I don't really know what to do with my sbc's.  After getting them set up there is nothing more I could think of to use them for.  I guess part of the fun is in getting them set up, and to run them cool during native kernel builds.  Just so it's not a complete waste of money,  I spent more (though not a lot) to add dual screens to some of them. Any ideas what else I could use them for? I already have music players (a lot of them, DACs), NAS, home control, security camera, what else do you use them for? I haven't left any of them outside in the sun yet to try out solar power.
 
So, I added dual screens to these ones (left to right,  counter clockwise) nanopi neo core, bananapi m1 (original banana pi),  pcduino 4 nano (same as nanopi m1), bananapi m2 (a31s),  and raspberry pi 3. All of them have two separate SPI channels, it was fun in making them, getting videos to play in dual screens (though not accelerated, but still ran fine in software), but now what?
 
 

 
Almost forgot, all of them are running Armbian next (except the raspberry) and thanks for the good work here!!!.

Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).
 
 
 

 

The fundraising campaign has just started https://www.indiegogo.com/projects/renegade-elite-the-revolutionary-mini-computer-computers-pc/x/19044630#/ 

Still being designed but photos attached. Big enough for you? @tkaiser 

Wow, even cnxsoft points out that BPi doesn't even know the specs to the thing they're selling.  

I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.
 
The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.
 
I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.
 
Here is the information about Rockchip source code:
- Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;
- Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 
- Rockchip kernel is now 4.4, and will update to next LTS;    
  We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.
- Rockchip kernel is used for Android and Linux OS;
- Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP
     * that's why we not able to merge the pull request, we have to review all the source code internally;
     * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;
- Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;
- Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.
    We will fix issues really need to fix, people don't want to get a kernel always have the same issue.
- We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.
 
    About the common kernel for community, here is my suggestion:
- Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;
- Developing, apply patches for new board support, switch some of module to upstream driver, and so on;
- Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;
- If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;
- maybe a mailing list is needed for better communication?

NanoPi-M4 is RK3399 based too, just no eMMC on board, and no so many interface as NanoPC-T4 So a little lower cost.
 
 

Had a little time to test this today, as expected, it's junk.  Being copper it moves heat quickly, having no real fins or the like it simply has nowhere to move it to.  It can handle "smoothing out" the heavy thermal loads, but it simply can't move enough heat.

The NanoPi K1 Plus:
 
[  ] armbian good support - not yet
[x] 2+GB ram - yes
[x] fast cpu - yes and 64bits
[x] Gigabit Ethernet - yes
[x] eMMC support could be nice for fast OS - yes
[x] it will run headless - yes 
[  ]- docker support - yes when armbiam come
[  ]- USB 3 support could be nice, otherwise USB 2 is ok - USB2.0
 
 

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...