fossxplorer

That hat is specially for this board. I'll order it when it's out.
For NAS this board is perfect. With an external hd with usb3 or with that sata hat.

@nicoD
Fantastic video you made for this board. I really really want to order one after watching your video!
Thanks a lot!

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.
 
 

Hi all.
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
I've finished my review video about the NanoPi M4.
Again with a great working Armbian. Thank you to everyone who worked on Armbian. Great job.
Greetings.
NicoD
 

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)

Short update... we seem to have kind of network trouble with the 1GbE ethernet port of Odroid C2.
It seems to "die" after some time, more or less the same way on all five Odroids.
Is there any known issue with the network kernel driver?
 
Still investigating the circumstances, and can provide more debugging info if needed.
 
Any help/hint is appreciated.

No compass or GPS. You see a picture from the videostream taken by the ROV, which made optical inspection after deployment and attached cablings afterwards. The ROV uses GPS coordinates from the mother ship, and corrections made by sonar system.
The module itself carries no GPS, as obviously, there is no signal down there - nevertheless, we use a compass chip (MC6470) to measure orientation inside gravitational field or earth and hopefully also inside magnetic field (depends on how well that works inside the Titanium housing).

Hi guys,
some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
 
Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
 
Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
In the picture you just can see the Titanium housing with two glass covers attached to the string.
 
Again, thanks for the fish :)
 
Michael

Just wanted to confirm that everything is working well with ZFS here on ARM64.  Successfully running two MediaRAID 8x eSATA/USB3 enclosures off of a USB3 hub, 16 drives/20TB .. 10+ year old raidz2 pools that has moved between a dozen machines .. VM under Windows, Mac, Linux .. adozen controllers (PMP SATA, eSATA, USB3) survived 7 total drives dying, no data loss.  4GB RAM is plenty for media streaming -- 2.6GB RAM was fine with some tuning (VM in Windows that ran Plex and shared ZFS back to host).
 
Benchmarks eventually .. but downloading with sabnzbd/sonarr, using Chromium, and streaming 1080p to Plex at just under 3GB RAM in use.

I posted my ZFS solution here- able to compile/use the standard zfs-dkms packages with some modifications:
 
 

Very good observation. I bought 4 of these and i can confirm all of them having only 100Mb/s link (booted in Android) when connected to a 1GbE switch.
So Gearbest & co have LIED to us about the spec. I've now claimed full refund from Paypal.
 
 
 
 

Just got my first 2pcs of SCISHION V88 Piano, i will start testing some of the images and report back. Hope to get GbE in the first place and then....really hope the USB3 will work

Tried with ioBroker image and it booted up on my first attempt, WOW! This is the first box to boot on my first attempt.
USB mouse and keyboard work, but there are error messages related to the GbE i think:
stmmac_open hw setup failed + some DMA setup failures
'ip a' shows an interface named eth0, but 'ethtool eth0' gives some errors as well.
Kernel version is 4.4.77-rk3328.
 
Now if we can get the ethernet to work and USB3 (not yet tested), this is gonna rock!
 
Edit1: Some images of the issues for debugging purposes:
https://my.owndrive.com/index.php/s/ycA9lCC1yQSFIH2
 
Edit2: USB3 seems to be working as i get ~90MB/s for reads with a USB memory drive.
 
Now only the ethernet is not working so i hope we can find a pay to patch it.
Still waiting early to get started with my Ceph home lab with these!

Thanks for 'announcing' NEO Core/Core2 now somewhat officially (my scripts monitoring this and that here and there spotted them already some time ago since fortunately you develop in the open).
 
So with Core/Core2 we get a H3/H5 base module that exposes RGMII and all 3 USB host ports on GPIO headers to be combined with this 'Mini shield' providing Gigabit Ethernet, an M.2 SATA 2242 slot behind a JMS567 or JMS578, two USB2 receptacles that do not have to share bandwidth with full mechanical RPi compatibility so RPi enclosures will fit and even many/most RPi HATs relying on the original 26 pin GPIO header. Very well done

To enable USB you can only replace dtb file.

Update TEST images  kernel 4.13.0-next_20170905. In these images there is USB support for S912.

[Disclaimer on]
This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now?
 
Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this?
[Disclaimer off]
 
Let me introduce ROCK64:
 
RK3328 SoC: feature list ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks) Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit) 1GB, 2GB or 4GB PC-18666 LPDDR3 eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper) socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter) 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever) RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth) Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked) I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this) Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)  
Pros:
board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor) board vendor provides dev samples and documents problems devs might run into (see below) chip vendor actively supports mainline Linux and u-boot chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC) SDK/BSP not horribly outdated (RK relies currently on 4.4) almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces) No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook Icenowy already received a dev sample  
Cons:
 
new platform (Rockchip 64-bit) needing more initial work  
Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)
 
My next steps planned:
 
Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks) Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution) ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering) Present results to continue discussion

The current state of the LibreELEC RK3328 build is rather unstable with occasional lockup or crash, there is also no working ethernet or wifi yet, making it very unusable and hard to test new builds.
I see great potential in RK3328 as Rockchip have been very supportive this far and are working on fixes for issues we have reported.
 
I have personally only tested on the Z28 2/16 box but you should be able to build an image using the build command on https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/devices/RK3328 and flash the resulting image to a sd-card.
But in order to boot from the sd-card you will have to erase the current bootloader from emmc, and that is where it gets a little bit tricky unless you are familiar with rockchip maskrom/rockusb mode and have uart connected.
 
I am looking forward to switching to a ROCK64 board for continued RK3328 development