Search the Community

The USB3 controller on RK3328 (Rock64/...) can be more or less saturated with a SSD using UAS. I got about 380MB/s (theoretical maximum for UAS is just over 400MB/s) using iozone, and since RK3399 uses the same DW IP block, I would guess that RK3399 is similar...

IMO, minimizing complexity and subsequently saving energy should be a recurrent activity. Its so simple to get lost in a pile of code, projects and tasks. Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count. When a board can come to a support list: - if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server. - if there is at least one stable kernel, - if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1 - what else? From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? BTW. There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative. Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? There are many uncertainties and it’s a hit and miss game per se. Or rather push here and there – only our initiative is anyway not enough – and move the board among supported, when we have enough "ifs" on the table? In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon. Reasonable minimal OS images, exactly. Perhaps we have to look on this more from the user side. But we face a big variety, from »I am new to Linux« down to kernel hackers. Well, first ones take a lot of time and ask stupid questions, while others don’t ask much, but when they do, sometimes is not possible to answer – because of quantity, complexity or we simply don’t know the answers. Cleaning is a very good idea but its some work. Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes. Nevertheless, how big changes are, we have to tell people, where we can help and for what we ask people that is better to use a Google or ask elsewhere. This makes me think to do some changes to a forum (at once) and remove »Common issues« since they are nothing but a generic Debian/Ubuntu problems (which should not be our problem) and merge them with »Peer to peer«. There we add a sticky where and how to search. Also move all nontechnical stuff from »General chit chat« as well. I hardly catch up on topics and can't moderate forum content. If this is too much for current moderator team, it should expand. New WEB is under construction and the person who is doing the actual work - from UX and design perspective - is doing this on biased limited input. Old WEB, the way it looks now, is a patch over patch over patch. Affiliate Amazon links are added value content, but since it’s tied to a kernel only, it might not show up completely correctly. This problem is being considered in the new database design. Current WEB is not a representation of what I or what we wanted to show. That’s the reason something is going on in this field. A basic logical concept of WEB is already standing, without any content. It's possible to add direct comments and check actual navigations - currently, only me and Tido were added comments and if anyone wants to participate in the process, send me a PM and we will ger credentials. Currently, we have a basic frame, UX is getting better and database/web management is designing from scratch. It's a stereotype which won't just go away. We can only send those who come up with such questions to the place where all those common things, like power supply, SD cards, ... essentially to the "Getting started"/"welcome to forum" and simply stating that Armbian is a generic Linux distribution and we don’t cover such special cases. KODI might work, but most likely won't and you better look after a special multimedia distributions like Openelec, Librelec, … In any case, users must be aware how to find such information from a very first page. Such questions are considered in a UX redesign over and over again.

Has the rx/tx delay been tuned on the Tinkerboard? Since we did that for Pine64/Rock64 most of the GbE issues have gone away. Ayufan made an automated script that uses configfs/dt-overlays to iterate through all the values without rebooting each time, based on tkaiser's scripts... https://github.com/ayufan-rock64/linux-build/tree/master/recipes/gmac-delays-test This resulted in a small patch that did wonders for GbE performance: https://patchwork.kernel.org/patch/10178969/ Worked both for BSP and mainline...

Yes firmware+u-boot are on the SPI flash, only the rootfs is on USB or network... check https://github.com/ayufan-rock64/linux-build/releases https://github.com/ayufan-rock64/linux-build/releases/download/0.6.16/u-boot-flash-spi.img.xz is a sdcard image that writes the bits to SPI https://github.com/aw/linux-build/blob/2fec6745b584c2bbc5fbe15d4cbaacd62c096b24/recipes/flash-spi.md for the how-to

As I understand it now, that's why Rock64 has not (yet) received a mainline kernel. Correct? Then build the Mainline Kernel brings nothing. or?

Hey, sorry for the mistake. I had it wrong in my mind. I have seen that the Mainline Linux kernel supports Rock64. https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts At least that's how I understand it, but I can be wrong again.

I can't give you much on the Rock64, development has been slow. In general I'd expect the a53 cores of the Rock64 to come in behind the 8-core HMP setup, unless memory bandwidth is significantly better on the Rock64 / you have 4GB and need it. Kernel support is far better for the XU4 at this point, IMHO.

@TonyMac32 could you compare Rock64 and Odroid XU4 please. I see both in your signature.

Thank you for sharing. I like the tower what is the enclosure? HC-1 and XU4 have the same hardware so there is no difference almost. A full node needs storage the size of bitcoin transaction data is more than 150Gb now. IMO HC1 is just more convenient because of its form factor. what about CPU performance? Rock64 vs HC/XU4 ?

After some research on the forum I think the best option is Odroid HC1 1) Great support from the community and the vendor 2) Good CPU performance 3) It has no "power over micro-USB" issue 4) Good HDD performance Rock64 is the second candidate, 4 GB RAM looks appealing. I'm not sure about CPU performance thou' Please share your thoughts.

It seems like the board files for the ROCK64 mostly introduce some scripts (maybe would work?), a wip file that points to various ROCK64 info resources, references to kernel trees that are (at least in the default case) only a few commits away from off-the-shelf rockchip kernel sources, boot scripts, some kernel build configs, and defines some URLs for device-specific details. Based in all that and given the RK3328(not ROCK64) naming in that stuff it seems to at least be trying to be pretty generic. The present lack of any Libre-provided kernel sources suggesting any additional device-specific intricacies makes it seem like there should be a reasonable chance of success. It seems like the boot and post install scripts are the most likely stuff to need changes, and even that stuff seems more RK3328 specific than ROCK64 specific I guess I'll give it a go whenever the board decides to come. If all goes well, it seems like the board may be a wip file away from experimental support. --Matt

Can you explain how you achieved this? I have tried a couple of steps including https://obihoernchen.net/1416/odroid-xu4-tune-network-and-usb-speed it doesn't seem to affect performance significantly when copying files from Win to HC1 through 1GE. It averages 55Mbytes/s which is think is too low. The same disk connected to my Odroid, I used with an USB/SATA cable before attached to my Win machine, the disk takes easily 130MBytes/s. I have tried that same disk with a rock64 (no tuning) and that same USB/SATA cable and Samba, it was twice as fast. I timed copying the same ~100GB of files.

There's nothing special. Simply stay away from all proprietary crypto modules and choose an ARMv8 SoC with support for ARM's crypto extensions. Reasons why: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829

It's possible. I don't have one, probably should look into getting one, and spend some time with it and the Rock64. Currently mainline isn't very exciting, so it needs the 4.4 kernel to truly operate properly.

I ordered one of these the other day. Not sure when it'll be shipped or anything, but I was curious about the level of support it might have at this point. The only Linux image I see for it anywhere is a 32-bit Ubuntu image on the Firefly site. Any chance this would boot/run on a rock64 image, or anything like that, until a targeted install is available? --Matt

So RK805 PMIC like Rock64 and IIRC Renegade Looks like a SPI flash (25lq128), U-boot SPL might actually live there. Asmedia ASM1351 sata bridge Room for more RAMS

Just installed this image based on armbian burning it to internal emmc using sudo ./flash_tool.sh -c rk3328 -p system -i image/ioBroker_Image_Rock64_20171211_xenial.img I connected to youtube using my mobile as a usb modem. It seems to have hw acceleration, at least youtube videos play way better than ayufan images. I got to install xubuntu-destop as it comes with no desktop. This image is made by a german company named iobroker over the armbian beta for rock64. Cinnamon or Unity does not complain about software rendering, ethernet seems unconfigured. Remove nodejs and everything on the /opt/iobroker folder. Check it http://www.iobroker.net/docu/?p=7736&lang=en

Hi. The "usb to serial ttl bridge adapter" arrived yesterday, and I tried the 20/11/2017 armbian Rock64 image. This is the output of the console and it loops on " x0 : ... x2 : ... ... x28: ... Resetting CPU ... " I hope that this can help. Thanks.

They don't use the same processor. Tinkerboard: RK3288: fast 32-bit Cortex-A17 Rock64: RK3328: average 64-bit Cortex-A53 The Tinkerboard actually is faster even though it's a 32-bit CPU compared to the ROCK64's 64-bit CPU

I'm looking for current and upcoming PXE bootable SBCs. I guess if it has uboot on a SPI chip (like ROCK64, PINE64, espressobin, opi r1 ...) this is already a good indicator that it will support PXE boot. But I'm not 100% sure if PXE will really work, it seems to be rarely used for such boards. The only board I know which does not have uboot but can boot via PXE is the rpi 3. Maybe there are other ones. Some other boards like the nanopi duo could boot via a SPI chip attached to the respective GPIO pins. Maybe someone here knows other boards with PXE boot support or has tested it already?

Pine H64 claims to follow the same price with Rock64 with the same DRAM capacity. (Note: the 4GiB version of Pine H64 can only address 3GiB DRAM due to restriction of Allwinner chips).

it's not really an answer to your problem but i'll mention that for headless server oriented devices with good performance for the price, i have moved to rockchip and specifically rk3328 devices (same as rock64 board) which (should) have good Gbe and usb3. The rk3328 is not more powerful than a s905 (i don't care about hw decoder and 3D stuff) but it has a crypto extension module that works fine and will almost saturate a Gbe openvpn link, i bought a 2g/16g + bt/802ac (not working in linux yet) for around 35e, it's the alfawise z28 pro, here's a thread about it https://forum.armbian.com/topic/4708-z28-rk3328-18/ Read the thread carefully it has some serious caveats (can't boot from sdcard which it could, but no on that particular board) so it may not be a device for everyone and we are currently waiting for other box reviews to see if another one has less "linux install" problems.. i've been using a linux mainline kernel (17.04 server) on it for a month and i don't think i'll need a device more fully featured that this one for quite some time..

I am hoping that the community can enlighten me on how the Armbian development process works. I just purchased a Rock 64 board to use for a NextCloud box at home. I am seeing that Armbian seems to be the "best" OS solution for this. I also see that the Armbian release for Rock64 is still in "testing" phase. I would really prefer to run a "stable" release for this application. So my question is how does Armbian for Rock64 move from testing to stable. What is the process, what still needs to be done? I am not a developer or linux expert by any means. I am wondering how the process works so the I can see if I might be able to assist in any way. Thanks!

Ok, that sounds reasonable. Just waiting on my eMMC card for the Rock64. Once that arrives, I'll give Armbian a try. How should I go about my results?

Same HC1 used, same SSD (EVO840), JMS578 on the board vs. JMS578 connected to USB 2.0 port (ROCK64 SATA cable), same firmware version on both JMS578 (JMS578_Hardkernel_v173.01.00.01.bin), same benchmark test: 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2': JMS578 via USB 3.0 random random kB reclen write rewrite read reread read write 102400 4 13592 14530 18712 18744 14664 14514 102400 16 46857 49586 59322 59665 50182 49651 102400 512 204547 217732 200402 205359 201479 217830 102400 1024 233728 239458 237045 247595 241844 245813 102400 16384 224437 276093 308294 317705 317230 274902 JMS578 via USB 2.0 random random kB reclen write rewrite read reread read write 102400 4 7960 7967 7995 7999 7993 7977 102400 16 15040 15643 15984 15998 15984 15930 102400 512 21761 21874 22360 22411 22416 21884 102400 1024 22332 22866 22509 22585 22582 22421 102400 16384 22476 22912 22801 22864 22765 22879 Above tests were made with performance governor... and obviously performance sucks (I've seen much better numbers already). I flashed the external JMS578 with v0.4.0.5 firmware again and tested: JMS578 with v0.4.0.5 firmware via USB 2.0 random random kB reclen write rewrite read reread read write 102400 4 7318 7967 7994 7999 7988 7976 102400 16 15584 15904 15982 15998 15984 15938 102400 512 22059 22787 22400 22442 22436 22170 102400 1024 22508 22875 22524 22586 22583 22558 102400 16384 22554 23002 22810 22853 22760 22956 So most probably this is a kernel issue and something slowing down USB has been commited to Hardkernel's 4.9LTS kernel in the meantime. Please direct all your questions at Hardkernel over in ODROID forum, I'm simply too tired to deal any more with this constant mess...