Search the Community

Compare against the cheapest possible solution isn't really smart.. I think you should compare it again boards which are in the same price class... Espressobin, Hummingboard 2 and Clearfog PRO will outperform it.. or the ROCK64 with usb sata bridge... Without a -I in your iozone tests..... I would recommend that you do more or less the same tests which are done on other armbian devices.. A classical one for iozone is this one: 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' As you can see... This board led to horrible discussions here.. We had to close a thread cause it runned out of control. I appreciate your efforts to deliver some data, but it would be nice if they are comparable with the data, we have from other boards. Do you have a possibility to test the boards USB3 capability? In the beginnings speed there was a little bit low.. Would be nice to see if they made improvements or not.

Oh, to my surprise since I was still using Ayufan image on my Rock64, it seems that current Dev build, although building properly, isn't booting and get stuck at "starting kernel" ... Anyone got the Dev working ? Then, I've built Default version, and this one is working ... It is maybe question of DT itself or U-Boot, I will need to investigate more.

... But, I will do the task for Rock64 ...

@martinayotte Tinkerboard images are not compatible with Rock64 ones, so there are no Ayufan's images for it

He's definitely making progress. I haven't checked the new release, but from what he said on irc I don't think it's working properly with the 64G sandisk on pinebook. Apparently it works great on the rock64. I've been looking at the code changes in the new release and one in particular has let me make a bit more progress - I can now successfully switch into hs200 mode, which is a necessary step to full speed. The next thing is to run auto-tuning in hs200 mode, without it the host<->mmc communications don't work reliably at 200MHz. Unfortunately the normal code path is via function pointer that hasn't been set, so I have to do some searching to try and find where the routine is. For giggles I tried running hs200 at 100MHz which seems to work fine. It's currently running in sdr mode and it has almost identical performance to 50MHz/ddr, which makes sense. Baby steps...

So disks behind the JMS578 on HC1 are reported to spin down after 3 minutes of inactivity. I've not noticed this before, just booted latest OMV image on HC1 with a 500GB disk. Still not an issue (SMART is not enabled in OMV). On the other hand the disk activity led is constantly blinking which seems wrong to me. If I would come accross this issue with spinning rust then most probably I would either let a cronjob do a 'touch/sync' every 2 minutes or even better install smartmontools, configure smartd and let it run with '-i 179' (querying the disk every 179 seconds and thereby preventing it from spinning down while getting some health data logged or even notifications if the disk shows critical SMART values). Edit: For whatever reasons the 'disk activity led' stopped blinking ~20 minutes after I mounted the fs on the disk, then the disk stopped spinning shortly after That means I can also confirm. And there's something wrong since 'hdparm -C /dev/sda' to check the state of the disk (idle|active|standby|sleeping) wakes up the disk (shouldn't do this) and produces this output: /dev/sda: SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown Anyway: Mounting the disk in OMV and then using this ends up with that keeping the disk spinning root@odroidxu4:~# ps auxww | grep smart root 4149 0.2 0.1 3924 2380 ? Ss 11:17 0:00 /usr/sbin/smartd -n --quit=never --interval=179 Edit 2: Nope, doesn't work either while touch+sync do the job. Kinda annoying Seems like Hardkernel isn't that lucky combining JMicron ICs with JMicron firmware... Edit 3: Since I've another JMS578 lying around I used same HC1 with same HDD this time connected to USB2 port using the ROCK64 SATA cable. Same behaviour though, hdparm -C throws same error and disks spins down after short time. Here 'hdparm -I' output for onboard JMS578 and for external (only difference is 'Advanced power management level': 254 vs. 128)

Yeah puzzled by the community images as the git repo's seem to be there for the Rockchip graphics framework. Just trying to use libmali and get glamour going for X11 and sort of given in. The status matrix sort of looks like a solution can be compiled even though mainline is still a WIP http://opensource.rock-chips.com/wiki_Status_Matrix libmali-rk-utgard-2th-r7p0 - The mali library for Rockchip RK3328 (32bit) either doesn't like the kernel space driver or the xserver / mali / kernel is somewhere out of sink. Xorg & kernel logs don't tell me a lot apart from I bang out with a segmentation fault. [ 10.987] (II) xfree86: Adding drm device (/dev/dri/card0) [ 10.988] (II) no primary bus or device found [ 10.988] falling back to /sys/devices/platform/display-subsystem/drm/card0 [ 10.988] (II) LoadModule: "glx" [ 10.988] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 10.992] (II) Module glx: vendor="X.Org Foundation" [ 10.992] compiled for 1.19.3, module version = 1.0.0 [ 10.992] ABI class: X.Org Server Extension, version 10.0 [ 10.992] (II) LoadModule: "modesetting" [ 10.993] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 10.993] (II) Module modesetting: vendor="X.Org Foundation" [ 10.993] compiled for 1.19.3, module version = 1.19.3 [ 10.993] Module class: X.Org Video Driver [ 10.993] ABI class: X.Org Video Driver, version 23.0 [ 10.993] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 10.994] (II) modeset(0): using drv /dev/dri/card0 [ 10.994] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 10.994] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 10.994] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 10.994] (**) modeset(0): Option "AccelMethod" "glamor" [ 10.994] (==) modeset(0): RGB weight 888 [ 10.994] (==) modeset(0): Default visual is TrueColor [ 10.995] (II) Loading sub module "glamoregl" [ 10.995] (II) LoadModule: "glamoregl" [ 10.995] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 11.014] (II) Module glamoregl: vendor="X.Org Foundation" [ 11.014] compiled for 1.19.3, module version = 1.0.0 [ 11.014] ABI class: X.Org ANSI C Emulation, version 0.4 [ 11.014] (II) glamor: OpenGL accelerated X.org driver based. [ 11.049] (EE) [ 11.049] (EE) Backtrace: [ 11.049] (EE) [ 11.049] (EE) Segmentation fault at address 0x10 [ 11.049] (EE) Fatal server error: [ 11.049] (EE) Caught signal 11 (Segmentation fault). Server aborting But the kernel is loading and libmali-rk-utgard-2th-r7p0 is installed but is grabbing from the glx module Oct 6 04:19:00 rock64 kernel: [ 3.984499] mali-utgard ff300000.gpu: resource[4].start = 0x0x0000000000000013 Oct 6 04:19:00 rock64 kernel: [ 3.990333] mali-utgard ff300000.gpu: resource[5].start = 0x0x0000000000000014 Oct 6 04:19:00 rock64 kernel: [ 3.996105] mali-utgard ff300000.gpu: resource[6].start = 0x0x0000000000000015 Oct 6 04:19:00 rock64 kernel: [ 4.001815] mali-utgard ff300000.gpu: resource[7].start = 0x0x0000000000000016 Oct 6 04:19:00 rock64 kernel: [ 4.007480] mali-utgard ff300000.gpu: resource[8].start = 0x0x0000000000000017 Oct 6 04:19:00 rock64 kernel: [ 4.013018] D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali. Oct 6 04:19:00 rock64 kernel: [ 4.019593] mali-utgard ff300000.gpu: Looking up mali-supply from device tree Oct 6 04:19:00 rock64 kernel: [ 4.021553] Mali: Mali device driver loaded Oct 6 04:19:00 rock64 kernel: [ 4.028062] ALSA device list: Oct 6 04:19:00 rock64 kernel: [ 4.033448] #0: HDMI Oct 6 04:19:00 rock64 kernel: [ 4.038635] #1: I2S Oct 6 04:19:00 rock64 kernel: [ 4.043777] #2: SPDIF Oct 6 04:19:00 rock64 kernel: [ 4.049603] Freeing unused kernel memory: 1152K (ffffff8008fb0000 - ffffff80090d0000) aint a clue to what D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali. is supposed to mean mali450 but maybe that is just generic.

/usr/lib/dri/rockchip_dri.so just doesn't exist but not really sure if the xorg package is the xenial one or rockchip one. If it is the rockchip one then for some reason rockchip_dri.so isn't being built. On a startx it gives it a good go but always drops out to software rendering because its missing the above.

I think my needs/goals with the ROCK64 or an RK3399 would ultimately fit into this list: - Stability - Fast enough storage to saturate gigabit ethernet/WiFi - Two ports with port multiplier support (prefer SATA/SATA via PCI Express, but two USB 3.0 is ~OK) - Low enough latency to satisfy user experience (large git repo, traversing filesystem normally, general responsiveness) -- i.e. prefer to avoid overhead of USB3-to-SATA and feel this affects the experience more than the raw throughput possible - ZFS -- I have tested a dozen PCI/PCI Express SATA/USB3/motherboard controllers and many years of ZFS implementations, good and bad, completely abused these two arrays and would never willingly go back to MDRAID or trust a single drive - ~5 watt or less SBC idle with USB device attached (not counting power of drives/external controller) I am currently at around 160MB/sec average or so on two 8x spinning disk arrays currently connected via an old Silicon Image 3132 PCI Express x1 controller - rated for 2.5 Gbps .. it has been the most stable controller combo for the JMicron USB3/SATA combo port multiplier chipset built into the array chassis. USB3 (yes, 8 drives over 1x USB 3.0) has actually been more stable over the years depending on the USB3 controller used -- in terms of dropouts and performance consistency, but the latency on file operations for that performance is consistently abysmal.. I don't see much of a use case here for the high end of SSD throughput .. unless you are editing 4k video. RED Raw 4k is 162MB/sec at 30fps. But I think that will have to wait a generation here. But of course there are other advantages .. I suppose I would prefer an SSD that was 2x the size and 4x slower max throughput for the power advantages alone. It would be interesting to put an additional (n-tier?) caching file system layer over attached storage that caches to eMMC.

No, please check https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 USB3 is there on more recent ARM SoCs since they can license USB3 IP blocks now and have not to pay too much for this any more. Same with PCIe, it's there, you can connect stuff to it, it allows the IDH who do the job to be creative and add peripherals they couldn't in the past due to not enough high speed buses but that's it. A TV box SoC like RK3328 shows surprisignly an insanely great USB3 performance (and RK3399 will do the same since [1]) but why should this be the same with PCIe on a tablet SoC like the RK3399? Look at the link above and i.MX6: Native SATA II: native transfer rate of 3.0 Gbit/s that, when accounted for the 8b/10b encoding scheme, equals to the maximum uncoded transfer rate of 2.4 Gbit/s (300 MB/s). In reality it's a third we get. But SATA II is an improvement over SATA I (limited to 150 MB/s) since it defined NCQ so workloads with many small disk accesses could benefit greatly from this feature (never tested in detail since i.MX6 is boring slow for my use cases) Native Gigabit Ethernet: Standard talks about a 1Gbit/s signal rate and all we get with i.MX6 when using the internal GbE implementation are ~400Mbits/sec at the IP layer and not ~940 MBits/sec as it should be. Only using the single PCIe 2.0 lane and a good PCIe GbE adapter exceeding 900 Mbits/sec is possible (never tested in detail since i.MX6 is boring slow for my use cases) Native PCIe 2.x: This standard talks about 5 GT/s per lane again with 8b/10b encoding applied so maximum bandwidth would be 500 MB/s not counting any protocol overhead and funnily leaving out all performance issues that are related to (high) latency issues. The result: lowest performance again (check the Hummingboard numbers). There's a SoC made for a specific market, there are some lowspeed and some highspeed interfaces connected to and there are some specifications talking about signal or line rates. This is all not related to real-world performance. An EspressoBin with a dual-core SoC running at just 800 MHz will outperform any tablet or phone SoC when it's about network and/or storage. Since 'made for the job'. I'm not that stupid (any more) to expect from an RK3399 with its PCIe 2.x x4 interface anything near the theoretical 2000MB/s (and focusing on bandwidth only is already stupid like hell anyway ). [1] Talking to an RK engineer few months ago about USB3 issues with ROCK64: 'still confused about this issue, because I test the USB3 drive on my RK3399 SDK (use the same xHCI host controller as RK3328 but different USB3 PHY), and I am surprised to find that it works well on RK3399.'

Appreciate the responses. Going with the Rock64 for now due to the support available. That N54L looks really interesting. Tuning ARC/cache will help -- I have been successfully dual-booting Windows/Linux with ZFS and arch, using a VM in Windows to access/share ZFS back with good enough performance for my needs (~100MB/sec, Plex server) on a 2.5GB RAM instance after tuning ARC and a few other things, so I think it's going to come down to the stability of the USB3 chipset. (or SATA FIS) https://wiki.freebsd.org/ZFSTuningGuide The Firefly RK3399 has a PCIe M.2 to SATA board available with two ports on an ASMedia ASM1061 card which I believe supports FIS -- http://shop.t-firefly.com/goods.php?id=52 -- but once you figure additional time needed on the RK3399 to get things going currently, it seems like it's much more expensive than simply $199 vs ~$60.. I will be experimenting with a few setups on the storage end, but ultimately this will be a portable NAS/Plex/mobile office server briefcase boombox build using a $20 Lepai amplifier, powered by LiFePO4 batteries (https://www.amazon.com/dp/B01M4P35Z9 ), charged by solar (https://www.amazon.com/dp/B074G1CN6N ) and can be used as speakers/media server for a portable DLP/Android projector. Moving off-grid/tiny cabin next year and downsizing/combining functionality. A second briefcase will be an LTE receiver/repeater/WiFi hotspot that can be positioned independently where there is a better line to a tower -- LTE with the Firefly seems interesting but need to confirm that it will work with Verizon and Sprint. Something like this for the form factor:

I would have a look at a Rock64 or oDroid almost a quarter of the RK3399 price. It would be great for someone to do a really good RK3399 dev board as it has 4 PCIe 2.1 lanes that seem untapped apart from sole use for LTE. I think the Firefly has a 2xSata - PCIe optional card dunno about videostrong as the SDK and software offerings are supposedly flakey at best. As a SoC the RK3399 is pretty amazeballs and sure its price will drop as more qty's are pushed, not sure about the dev boards though and don't think anyone has really cracked it. There are 2 RK3399 tv-boxes that do have Sata VorkeZ3 & Nagrace NT-V9 that are much cheaper than the dev boards but still pretty dear and best of luck with a linux image for them.

Yeah what is really interesting you got it working good job and +10 from me. Dunno about reboot but you have access to start hacking why. The ethernet "Mac address" change can be read about on the Rock64 forum as the early images where the same. The rock64 has 128Mb SPIflash which with my dodgy memory is where the mac is being stored but prob doesn't exist on the z28. Guess just hardwired mac address /etc/init.d/networking stop ifconfig eth0 hw ether 02:01:02:03:04:08 /etc/init.d/networking start or is it /etc/init.d/network stop ip link set eth0 address 02:01:02:03:04:08 /etc/init.d/network start I get all confussed what debian & ubuntu are using now. Or create a permanent entry in /etc/network/interfaces hwaddress ether 02:01:02:03:04:08 Apparently linux-image-4.13.0-rockchip-ayufan-130-g4f68418_0.5.13_arm64.deb will not load from eMMC but SD works prob due to the EVB inclusions in 4.12 dunno if that helps with those who are trying to load Linux.

thanks for all links. I will browse them. rock64@rock64:~$ uname -a Linux rock64 4.4.77-rockchip-ayufan-118 #1 SMP Thu Sep 14 21:59:24 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux I forgot to mention what works and what don't on the image I used, even though, I upgraded using the "apt-get" commands. 1. "reboot" does not work. It hangs, and a power off is required to restart. 2. Ethernet does not work, and "MAC address" changes on each reboot. 3. "Wi-Fi" is really bad, I need to place box close to the Router ( AP ). Something no more then 5m ( Chip is 8188 ).

Ram is a prob with the Pi http://docs.ceph.com/docs/hammer/start/hardware-recommendations/ so post on your findings. I agree about glusterFS extremeFS is actually active but using the Rock64 with 4Gb LizardFS seemed simpler than Ceph. I would get in there IRC chat and see what they say.

@rosimildo http://wiki.pine64.org/index.php/ROCK64_Main_Page#ROCK64_Software_Images has it with links to github. https://github.com/Raybuntu/LibreELEC.tv/releases has much done with the work from kwiboo, longchair & omegamoon The majority is inplace and they aim to have it complete for the introduction of Kodi Leia. http://linux-sunxi.org/Mali_binary_driver or https://developer.arm.com/products/software/mali-drivers PS did you guys just disable the eMMC? Is it an easy job as if SD0 doesn't exist it should boot from SD1 like on the Rock64 or is it more involved. The TV box that really interests me is the Bqeel MVR9 (NT-N9) as there is also a 4Gb version but finding it anywhere on sale apart from toaboa.com is another matter. The teardown specs look really good. https://www.cnx-software.com/2017/07/14/bqeel-mvr9-tv-box-review-part-1-specifications-unboxing-and-teardown/

Hi, do you plan to add Desktop images for Rock64 ? Anyway thanks for your great job. Armbian is wonderful!

With regard to Rock64 as a NAS... As I had my share of struggles with RAID, I'm walking around with the idea to get started on the following project: Instead of having a server with multiple disks, why not have multiple servers in fail-over configuration. With a cheap-ass Rock64, this will not cost much more... Hardware, 2 identical sets consisting of the following: Rock64 with its 5V/3A PSU, USB3.0 storage (SSD or HDD), mSDcard for the root file system Software, on each: Armbian, Samba, CTDB, DNS, DHCP, all in failover configuration with common GlusterFS shared storage. Additionally, OpenVPN on each (no fail-over, just on 2 different WAN ports) to have remote access to my home network. IMO, this should have the potential to work and achieve a reasonable performance, and with rclone to AWS S3 you would be disaster-proof as well... What do you think, can it fly, should I re-consider, or should I bail-out ...

@Da Alchemist Have you tried raybuntu's libreelec as he has been grabbing and mixing some of the work done by Kwiboo, Longchair & omegamoon https://github.com/Raybuntu/LibreELEC.tv https://github.com/Raybuntu/LibreELEC.tv/releases/download/rb-krypton18/LibreELEC-ROCK64.arm-8.2-rb-krypton18.img.gz Thats a z28 & not pro which has more similar layout to the Rock64 and maybe would have the network, anyone with a pro given it a go? http://kszaq.libreelec.tv/sources/ssv6xxx-1041e7d.tar.gz?

What do we know now? Not much -- most importantly that some details will change and 'board available soon'. We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them ) So all we know is really just: H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo) One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

Did an another test this morning with xenial-minimal-rock64-0.5.10-118-arm64.img.xz from ayufans github. It is not working on my z28 (XJH-ZY168-V00) , burned with etcher. To test the SD card i took Kwiboos Openelec Image LibreELEC-ROCK64.aarch64-8.2-devel-20170818172941-r26033-ge19c7b5.img and burned it to the same card. Apart from no network and the annoying Heartbeat Led, this image is working.

Hi! Other way to may be possible boot, i have seen SV6051 wifi on Z28 Pro and MX9 MAX 2G 16G (a litle cheaper). SV6051P can be easyly desoldered and give access to all pin for sdcard connector. Do you know when the rock64 bootloader will change for more open? Now i understand it's work only in Maskroom mode. Rock64 start to be mainline, so maybe it's not just an other chineese box

I have wrote some manuals in russian language, you can use it if you can translate it - http://4pda.ru/forum/index.php?showtopic=819860&st=340#entry63238627 xenial-mate-rock64-0.5.10-118-arm64.img

Just as information, the latest ayufan images are not running on z28 and because rock64 armbian is based on ayufans work it will also not boot. So I would not recommend to buy such box at all, it is just another cheap chinese TV Box.

Getting back to development related news - basic Rock64 support was added to the mainline tree starting with 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts?h=v4.14-rc1&id=955bebde057e71b6f29b97b78c027efdd596e62d