TheLinuxBug

Some quick tests of a 2.5" 1TB SATA drive via USB 3.0 enclosure attached to the USB 3.0 port on the ESPRESSOBin:
 
Iperf tests between my 2 ESPRESSOBins, both linked at gigabit:

Board Running Armbian/OMV:

Board Running Ubuntu 16.04LTS image with custom compiled kernel:
 
There are probably some better tools to use, but at least this will give an idea.  Looks like the drivers for the NIC in my customer kernel may be a bit faster?
 
Shameless plug: If you get bored and have Allwinner H3 device, check out H3droid - an Android image developed specifically to work on Allwinner H3 devices!
 
Cheers!

Okay, FINALLY I have had time to test this...
 
@tkaiser @Andrius @lanefu
 
The issues are as follows:
1. You are lacking the dtb file in /boot (armada-3720-community.dtb)
2. Once the kernel boots it disables UART which is a huge pain
3. Requires manual changes to uboot config at startup (you need serial connection at boot time)

To get it to boot:
1. Copied the armada-3720-community.dtb into /boot on the SDcard
2. stopped uboot during start up and entered the following:
Marvell>> setenv image_name boot/Image Marvell>> setenv fdt_name boot/armada-3720-community.dtb Marvell>> setenv bootmmc 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p1 rw rootwait; booti $kernel_addr - $fdt_addr' Marvell>> save Saving Environment to SPI Flash... SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB Erasing SPI flash...Writing to SPI flash...done Marvell>> run bootmmc
While the UART serial console no longer works, the board is online:
 
 
 
Sorry for such a long delay!  I will see if I can let this run for a bit and do some performance testing to see the difference between the Armbian kernel and the one I compiled my self.
 
Have a great weekend all!
 
Shameless plug: If you get bored and have Allwinner H3 device, check out H3droid - an Android image developed specifically to work on Allwinner H3 devices!
 
Cheers!

Hopefully I can get a chance to test it before then, works been ridiculously crazy and been also working on the H3Droid project so just haven't had time yet.  I do fully intend to test though and if needed I will switch out the kernel also for the one I compiled and see if this allows it to run.
 
Just don't go deleting it before I get time to download it ;p
 
Cheers!

Yeah I realize now I should have just purchased an 32GB SATA SSD instead of goofing around with m.2 and converters and such, however, at this point I figured it cheaper to cut my losses by buying the m.2 to sata adapter than still buying another drive.  Hopefully this adapter arrives and everything works (and I don't find my issues were caused by a bad SSD module).
 
As far as testing on the ESPRESSOBin:
 
Unfortunately the first one I ordered is already in production -- One of the reasons I wanted the SSD was to provide a little bit of high speed swap without chancing killing off an SDcard.  The board its self runs like a champ and it is easily my favorite headless board I own.   While some of their documentation is lacking. it does seem like they actually spent some time thinking about the board and creating docs which actually teach(force) you to compile your own kernel and use the USB to serial console and some things other board vendors don't really make you do.  I have enjoyed the experience of setting it up, learning the in and outs and working with it in general, so far (other than this issue with m.2).
 
Now, I have another ESPRESSOBin I had ordered, which they said would start shipping 'soon' so as soon as the second one arrives, I will make OMV my first test with it.  Sorry I can't be more helpful right now.
 
Maybe if I can afford some downtime of the appliance its running this weekend I will see if I can test, but I won't make any promises at this time.
 
@tkaiser  thanks again for taking time out to answer my questions as well as all the time and hard work you put in to keep Armbian the awesome distro it is!  
 
Cheers!

@Igor, thanks I will look up for the ongoing change related to the clearfog.

That's super great to read that you guys think it's a cool board. I had the strong feeling that I wasn't the only one looking for a board that's finally address the need to build a proper NAS on a fully open source ARM board. Coz yes it's the intention, if the campaign is a success, the whole hardware design will be released as open source (Open Hardware).
 
Haha, well believe it or not, I'm not doing it for the money...If it was really only $$$ that drives this project, I don't think it will actually worth it. My goal is to make it a product that the community likes and adopt...it will be my ultimate satisfaction. But ok deal, if it the campaign succeed, you will get your box of beers ;-)

Regarding the price point, I hope people will first understand that this a high performance SoC... it can't come as dirt cheap as some Pi-like boards. And that obviously I won't be manufacturing tens of thousands units. My target is 1000 units.

As briefly explained, I will principally offer it as a full kit (AC/DC adapter 12V 8A, casing, complete cabling, fans and a little oled screen). My assumption is that if you set it up a NAS, you don't want a messy setup with HDDs hanging around. You want something neat and clean...and sweet to look at Anyway there will also be the barebone option.

The price of the full kit will be in the range of 170 - 200 USD.

I'm fully aware of the competition (Synology, WD, etc...) and I can confidently say that apple to apple specs comparison is way cheaper.

Here as some pictures of what it looks like with the casing. (note : this is the casing without the oled screen).
 




 
 
No. It's non-ECC memory. The SoM supports ECC though, but it will bump the price quite a bit. However it could be a stretch goal or an additional option. I don't wish to open here a discussion on ECC memory in the context of NAS, there are already plenty of years old ongoing threads on [non-]ECC memory for RAID or ZFS. While Helios-4 board is clearly not targeting mission critical application, the likeliness of corrupted data due to bit rot + existing "mitigation" feature (beside doing backups), doesn't in my opinion worth the premium of ECC memory for the scope of this board.
Any opinion are much welcome ;-)

Cheers.

Gauthier.