Search the Community

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

Waiting for a Rock64 but the Z28 pro has been on my shopping list. Not sure as its the RK3328 that I think dictates boot from SD0 so not sure how the others are working. https://www.gearbest.com/tv-box-mini-pc/pp_640682.html?vip=2663187&gclid=EAIaIQobChMImaXhqt2r1gIVr7_tCh2_0QHUEAAYASAAEgL32fD_BwE is the 1 I have been eyeing up with 2gb 8gb rom. On the Rock64 if the eMMC isn't avail at sd0 then it will boot from the sd card at sd1 (I think) Not sure how you can maybe short out or disable the eMMC if you can then it will prob boot from SD card.

Guess question between Z28 or Z28 pro is Fast ethernet or Gig. If I was going armbian and tinkering then Z28 pro and presuming there is little difference between this and the Rock64? Kwiboo & Longchair have made great inroads with the rockchip VOP & MALI the LibreElec guys have almost got it cracked but they are aiming for Leia for completion but much is working already. https://forum.libreelec.tv/thread/4248-libreelec-krypton-leia-agile-build-for-odroid-c2-rock64-wetek-hub-wetek-play2/?pageNo=10 If you guys get armbian going on that for £26.25 wow that would be amazing bang for buck.

Sorry, I'm a nob, but maybe it's not so complicated to use the script from ayufan. I put it in the directory like in his github repo (/etc/network/if-up.d/rock64-offload) and made it executable. But it's not working on my rock64 (Version 2.0, 2 GB). Can anyone help me? Or is there a possibility to solve the ethernet problem with one of the next nightly builds. That woud be great :-)

Interesting. Are you able to repeat the test without the mSATA SSD being present (me assuming that then the JMS578 not tries to register itself on the USB bus and you being able to enjoy a working card reader)? Wrt JMS578 behaviour: On ODROID HC1 the JMS578 is always present on USB bus even when no SATA device is connected to it. With Pine's ROCK64 SATA cable and 'my' Xunlong NAS Expansion board it's different so I would assume that's configurable behaviour (maybe depending on JMS578 firmware or toggled by GPIO settings). Maybe this is also important. But I've not the slightest idea how to query the JMS578 for firmware version (in Hardkernel/ODROID forum they provided a firmware flashing tool a while ago but not from 'official' JMicron sources since they forbit providing end users with this stuff but from a server 'somewhere on the Internet')

Read that 4.14 will have additional ARM Board Support including some Banana Pi products .. Among the new ARM boards supported are for the Beaglebone X15 Rev C (TI AM57xx), Raspberry Pi Zero W, D-Link DIR-685 router (Gemini-based), Banana Pi R2 (MT7623), Cubietruck Plus, Banana Pi M3/M2M/M64, NanoPi A64, A64-OLinuXino, Pine64, Rockchip RK3328 Pine64/Rock64 support, ZTE ZX296718 PCBOX Board, and others. link: https://www.phoronix.com/scan.php?page=news_item&px=ARM-Hardware-Linux-4.14

And fixed image for Rock64 was just rebuilt. https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z

No, I didn't use a serial console. I use a hdmi screen and a usb keyboard. I boot the board, the login screen appears and I try to login. But the system doesn't accept "root" as user, the error message is "incorrect login", the "password" prompt doesn't appear. It's possible to tape "rock64", than the password prompt appears.

At least as long as the interface is not controlled by NM it works (tested 20 days ago when I benchmarked my first Armbian build on ROCK64). So we might add a NM hook too but since their way of doing things isn't that persistent a systemd service might be the better idea... What about this in the meantime? diff --git a/packages/bsp/common/etc/init.d/armhwinfo b/packages/bsp/common/etc/init.d/armhwinfo index 96345fa..1900085 100755 --- a/packages/bsp/common/etc/init.d/armhwinfo +++ b/packages/bsp/common/etc/init.d/armhwinfo @@ -253,6 +253,8 @@ prepare_board() { echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt + # preliminary rx/tx offloading workaround + /sbin/ethtool -K eth0 rx off tx off ;; nanopim3) # dw-mci on cpu1, USB host on cpu2, GbE on cpu3, USB OTG on cpu4, video-codec on cpu5 for i in $(awk -F':' '/dw-mci/{print $1}' </proc/interrupts | sed 's/\ //g'); do

Hmm... and what about simply re-using what's known to work: https://github.com/ayufan-rock64/linux-build/blob/master/package/root/etc/network/if-up.d/rock64-offload?

Yes, ayufan said he had problems with Ethernet -- we talked today in #ROCK64 channel and I tested with 1GB production board (and offloading active): https://pastebin.com/aAzkEYEB (somewhat low performance in one direction but IMO not critical) and then next batch of boards got DRAM 'downgraded' which seems to cause problems for him. Anyway: I tested with production board and without tx/rx offloading fix/workaround Ethernet stopped to work after ~30 seconds as it's the case with the pre-production boards too.

Nope, this shit https://forum.armbian.com/index.php?/topic/5098-mini-review-rock64-sata-cable/&tab=comments#comment-38798 happens way too often. An insanely shitty software called invision sitting in my browser and destroying things I want to share). That's it. As soon as the Armbian forum can be accessed without this interactive CRAP (using BBcode or $whatever sane option) I'm back. And no, I don't want to consult their sales clerks!

No time wasted! I thought today a little bit about why Armbian ships with such an anachronistic default configuration and whether it would be worth a try with more recent kernels to switch from swap to zram (and adjust vm swappiness since with vm.swappiness=0 most probably no one will ever see a difference). An interesting test would be sed -i 's/vm.swappiness=0/vm.swappiness=60/' /etc/sysctl.conf FILE=$(mktemp) wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb -qO $FILE && dpkg -i $FILE reboot But I've to admit that I don't know how to test whether something changes since I know swapping only as problem of the past. I've now 3 ROCK64 with different DRAM sizes. Maybe someone has an idea how a useful 'benchmark' could look like comparing different DRAM sizes?

The barrel jack on the Rock64 is tiny, I've not found one that size rated more than 1.5 Amps. (Not saying they don't exist, only that it is very small) I'll do some testing to see voltage drops/current consumption on mine and put it in the proper thread. I'm doing the same with "Le Potato", I may begin a matrix. Was the drive powering through the USB?

HK's kernel is in sync since 10 hours: https://github.com/hardkernel/linux/commits/odroidxu4-4.9.y BTW: with my EVO840 I get 240MB/s write on both XU4 and HC1 (with an UAS capable USB-to-SATA bridge of course! JMS567, JMS578 and ASM1153 successfully tested). If performance is that low as the 120MB/s you reported I would check 'lsusb -t' output whether you're using UAS or not and I would also check dmesg output for underpowering symptoms. I prepared a test with the fastest USB3 thingie we currently support (ROCK64) where we usually get +380 MB/s with fast SSDs random random kB reclen write rewrite read reread read write 102400 4 698 2538 1457 1577 1052 30803 102400 16 2732 84156 2697 3284 74365 572 102400 512 255254 265324 270608 279494 271598 1382 102400 1024 274236 1377 288145 296826 285552 1387 102400 16384 298959 298371 318954 326778 326171 1000 My test setup was an external VIA812B hub with an integrated RTL8153 Ethernet chip, to one hub port a JMS578 with EVO840 connected to another port a JMS578 with a Transcend TS120GMTS420 connected) and when I started the usual iozone benchmark underpowering (this time I would suspect undercurrent and not undervoltage as it's usual with XU4) happened. Problems/benchmark started at '239.752135': http://sprunge.us/JOMC (these are no UAS problems but just the usual symptoms of underpowering with loaded uas driver)

Currently yes... there is a difference since the dedicated OMV images contain a lot more tweaks. But that's the reason why I spent some minutes to prepare https://pastebin.com/ctLWTq2Q for Igor (he only has to find a solution wrt log2ram vs folder2ram, the 1 minute cron job that improves IO snappiness especially on slow boards and the Cloudshell 2 support stuff from Hardkernel). And no... users won't complain since average users aren't able to realize the difference 20 MB/s more or less make or whether handling of small files improves or not. Surprisingly people buy slow boards like Banana Pis with pleasure since 'native SATA' (slow as hell) and try to avoid fast NAS boards like HC1, ROCK64 since 'USB but no native SATA'. Direct comparison: https://forum.armbian.com/index.php?/topic/5036-looking-for-board-for-nas/&do=findComment&comment=38363

And another update, this time on USB3 performance. Since today a small M.2 SSD arrived I immediately tested with native SATA on a Clearfog Pro and I also gave it a try in a tiny JMS578 enclosure now with ROCK64 (details for both SSD and enclosure). Storage performance measured with the usual iozone call with SATA (to show the SSD's performance) and then attached to ROCK64's USB3 port, first with BSP kernel (4.4.77), then mainline 4.13-rc1: TS120GMTS420 SATA Clearfog random random kB reclen write rewrite read reread read write 102400 4 86865 124684 140973 140224 32522 101844 102400 16 206105 251838 293776 282729 84623 202503 102400 512 363707 377155 409380 401946 358966 372971 102400 1024 364578 358095 402539 404249 387812 376067 102400 16384 310808 407947 500231 497107 470879 398703 3072000 16384 420958 403649 509368 507120 469027 405752 TS120GMTS420 JMS578 ROCK64 4.4.77 1296 MHz random random kB reclen write rewrite read reread read write 102400 4 25793 31181 36545 38058 19837 32840 102400 16 74689 87314 127011 127494 62706 88478 102400 512 298948 322459 323666 325943 304947 311285 102400 1024 333159 343551 348576 351217 329950 344678 102400 16384 369142 377884 377184 380461 362302 359235 3072000 16384 374446 380254 382541 381844 363431 379725 TS120GMTS420 JMS578 ROCK64 4.13.0-rc1 random random kB reclen write rewrite read reread read write 102400 4 18098 22215 22757 22750 17104 21932 102400 16 61487 73079 75408 75522 56182 73369 102400 512 287554 299840 281735 283843 283678 300074 102400 1024 299159 314982 295748 297612 297422 305827 102400 16384 249205 357761 341508 343535 343730 346455 3072000 16384 350303 346587 346114 346187 346233 341654 As expected USB3 performance numbers lower compared to native SATA on the Clearfog Pro. But why do the mainline kernel results look that bad? Since no cpufreq scaling is working here and we're running the SoC with just 600 MHz set by u-boot. Now let's test again with BSP kernel limiting here cpufreq also to 600 MHz instead of 1296 MHz: TS120GMTS420 JMS578 ROCK64 4.4.77 600 MHz random random kB reclen write rewrite read reread read write 102400 4 15937 21334 25571 25576 17430 21122 102400 16 53353 65892 86114 85993 50773 65037 102400 512 273837 288669 276365 278220 261956 290194 102400 1024 296038 321502 309817 311969 293723 321893 102400 16384 363437 374665 344870 350489 345225 372353 3072000 16384 357195 367268 364944 365021 344555 367027 Now the above 4.13 numbers look a lot better!

It would be helpful if you stated why do you want to change or upgrade your current setup (i.e. are you looking for better performance or not) and what is "cheap" for you. Also don't know why are you looking for a credit card format board because it will limit your options. I would recommend looking at least at these 3 options: NanoPi NEO + NAS kit v1.2 Odroid HC1 Rock64 + any good USB3-SATA adapter

The used SBC has an influence since it bottlenecks the tests by card interface and maybe also CPU. The used OS has an influence since it bottlenecks the tests by default cpufreq scaling settings. That's the reason the numbers on page 1 were all done with the same device and same settings (performance governor, everything explained in the 1st post in 'Preparations' section at the top). Most SBC (all Allwinner based) show a transfer speed limitation due to SDIO interface between SoC and card (so sequential transfer speeds are limited to ~23MB/s anyway and this same limitation also bottlenecks random performance number of very fast cards). But since most SBC are bottlenecked by this interface limitation numbers are also quite realistic. The exceptions to this rule are Raspberries (where you can 'overclock' the SD card interface if you hate your data), the Tinkerboard, almost all ODROIDs and in general most newer boards like ROCK64. But as usual settings matter a lot, see this example here with different minimum cpufreq settings (affecting cpufreq scaling latency to reach higher clockspeeds which are needed for good IO performance): https://tinkerboarding.co.uk/forum/thread-310.html In other words: Most user contributed numbers here are for the bin if they're not accompanied by a clearly documented test procedure (which board, which kernel variant, which cpufreq governor -- everything else than performance and the numbers don't tell anything about the SD card or eMMC any more -- and which cpufreq scaling limits)

I repeated this test yesterday after I found why my H5 openssl benchmark scores were that low: since I was testing there with an armhf userland and not an arm64 one (32-bit vs. 64-bit but in this case more importantly: compiler switches forbid the use of ARMv8 crypto extensions when building armhf binaries). I also set up my 'monitoring PSU' stuff (letting a Banana Pro provide power to ROCK64 to be able to measure consumption without PSU being involved) and get the following consumption/performance numbers (on a 4GB pre-production sample -- there are some significant changes on production boards so idle / Ethernet consumption might differ!): idle @ 408 MHz / legacy kernel: 1450 mW When switching GbE to Fast Ethernet: 1100 mW (the usual 350mW drop) after poweroff: 580 mW (so there's currently some stuff missing and the board does not really power off cleanly) Testing with armhf userland walking through 408, 816 and 1200 MHz DVFS operating points: armhf 408 MHz: 52,000k / 1360mW --> 260 mW armhf 816 MHz: 104,000k / 1710mW --> 610 mW armhf 1200 MHz: 153,000k / 2790mW --> 1690 mW Now with arm64 (and Debian Stretch and different idle consumption since Gigabit is enabled): arm64 408 MHz: 730,000k / 1730mW --> 280 mW arm64 816 MHz: 1,508,000k / 2170mW --> 720 mW arm64 1200 MHz: 2,200,000k / 3340mW --> 1890 mW With ARMv8 crypto extensions active we see a slight increase in consumption (and temperature -- with armhf temp maxed out at 76"C at 1200 MHz while the arm64 tests triggered some throttling after 6 minutes since no heatsink applied to RK3328 and SoC temp exceeded 80°C at an ambient temp of 26°C). But the performance increase is massive (14 times faster).

Another small update on why settings/details matter. FriendlyELEC's NanoPi M3 isn't the best choice for a NAS since while featuring Gigabit Ethernet (+940 Mbits/sec possible) it has only USB2/Hi-Speed as potential storage interface and all USB2 receptacles are behind an internal USB hub (and have to share bandwidth therefore). So we're talking about 37MB/s max anyway with the MassStorage/BOT protocol and maybe up to 42-43 MB/s if USB Attached SCSI (UAS) would be available. I tested a bit around with NanoPi M3 last year but since storage performance was already way too low (26.5/31 MB/s write/read) I didn't test NAS performance. Since we're in the meantime able to run this board with mainline kernel I gave it a try again: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=38120 Now we get a nice performance increase when testing storage locally: 26.5/31 MB/s write/read back then, now 35/37.5 MB/s (or 8.5/6.5 MB/s more). I had to make a minor correction to our build system to get decent storage performance with our chosen ondemand cpufreq governor too and the other important difference compared to situation with M3's 3.4 kernel is that with the old kernel IRQs are processed on all CPU cores in parallel while we can now choose fixed IRQ affinity (letting interrupts for various stuff be always processed on the same CPU core): https://github.com/armbian/build/blob/4f08c97d745892b6d664b96f8a4f84f48ee1f53f/packages/bsp/common/etc/init.d/armhwinfo#L255-L267 Without that fix it would look like this since all IRQs are processed on cpu0: After fixing IRQ affinity and with the ondemand tweaks active (to get the CPU cores clocking up from 400 MHz to 1400 MHz instantly as soon as IO activity is happening) we're talking about: This is not that impressive as with ROCK64 above where we get 15-20 MB/s more just by taking care of settings but it's a nice little performance boost we get for free (just by taking time and care of settings). What's missing is UAS support, given the Nexell SoC's USB IP can be UAS enabled (requires most probably changes to the USB host controller driver) we would get an additional ~5 MB/s in both directions. Then we would talk about 20/25 MB/s NAS throughput with the old kernel (and active IRQ balancing and inappopriate settings) vs. 38/39 (or even 39/40) MB/s with mainline kernel, fixed/optimized IRQ affinity and UAS. Settings matter

A noob question. Rock64 has a usb3 port, and there is possibility to attach a SATA-USB adapter there, like that one, Pine64 sells in their store. Hardkernel has added such a bridge right into the board with their new HC1. I am wondering (since I have no possibility to check this directly), how these bridges represent themselves to the host - more specifically - do they expose themselves as AHCI/SATA controllers, the same way as their x86 brothers sitting on PCIe do? Everybody is talking about UAS here, so probably they don't expose their SATA nature (more then that SAT thing), but I am a total ignorant with respect to USB internals yet, so I might be wrong presuming that if they exposed themselves as SATA controllers sitting on a USB bus, there were no need in UAS with them. If they don't act as pci-ide, ahci x86 counterparts, then why? why a SATA controller put on the SoC interconnect or PCIe bus can be a "native SATA", but not when put on USB?