Search the Community

I do not have a Rock64 V3, but out of pure curiosity: Does this https://github.com/mrfixit2001/u-boot-1/commit/cbe59e621f83b54b7b463ad69a568fbae4db04a7 do the trick?

Hi, I have installed Armbian and updated everything. I'm running Chromium 73.x and I can't even play 480p youtube videos. What am I doing wrong? I'm on a Rock64 v2.

Hi, i also have low throughputs with wifi. I have a rock64 v2 with 4Gb and i use a 802.11n usb2/wifi adapter (the found on pine64 website). I made some test using iperf. With the Gigabit interface, i get ~800Mbits/sec with both ayfan bionic 4.4.132 on eMMc and with armbian bionic 4.4.174 on a SD card; the throughput seems a little speeder when booting on the eMMC but this is not significant. Always using iperf, the wifi throughput is at least 2 times slower when booting on a SD card . (~40 Mbits/sec on eMMC, and ~15 Mbits/sec on SD). Now concerning the internet throughput, it is always lower than 100 MBits/sec (using gigabit and booting on eMMc) although my internet connection allows 500 Mbits/sec (so 5 times lower), and at least 2 times lower when booting on SD. And the internet throughput using wifi is ~40 Mbits/sec on eMMC, and ~15 Mbits/sec on SD. To resume, the internet throughput is really slow (even with gigabit ethernet), my wifi adaptor is also slow, and booting on a SD reduces by at leasr 2 the throughputs except for gigabit ethernet tranfers. Any comments? regards Pascal

Hey all! Finally got my Rock64 booted up and running. I set up a Samba server and a Plex share so I can access an attached USB3 RAID array as a media server. Initially I was getting speeds of ~3 MB/s write and attributed it to transferring over wifi with an ancient Airport Express Draft-N router. Upgraded to a Netgear R7000P and the issue still persists so I figured it would be worth it to post here. I would've attributed it to the USB3 to eSata converter going to the RAID array but doing some disk speed tests on the Rock64 shows it getting about 130 MB/s read/write speed over the connection so I doubt it's that. Samba setup is stock and my share described below. " read only = no create mask = 0777 directory mask = 0777 follow symlinks = yes wide links = yes browsable = yes " My Rock64 boots up saying it's running 5.65 stable Ubuntu 18.04.1 LTS 4.4.162-rockchip64

Hah, I am in an apartment complex so it's a bit crowded but I try to take the bands where only 2 or 3 people are using them rather than a dozen. Still, WiFi shouldn't be the problem when I can transfer at 20MB/s over a windows share but only do 3MB/s over the Rock64. Something is fishy there but I'm not sure if I need to reflash my board with a different bootloader or really what steps to take right now. Thanks for the info about bumping!

This means it is at high level of software maturity, while Rock64 (and most of the supported boards) can't compete with maturity Cubietruck has. Maturity can only come with age Most of distributions out there doesn't write anything about most important thing - level of hw support. If their nice and shiny distro boots, then it's they support that hardware. We have higher standards and even with them its still hard to say what is supported and what not. Therefore we came up with this https://docs.armbian.com/#what-is-supported Ofc there are less problems in legacy, almost everything works, but problems are since sw support (not just kernel) is not matured. There are many different hw versions, which can make problem only bigger. In general there is overall low coding/maintenance quality in official (Rockchip) legacy kernels. On top of Rockchip there is development specifically for Rock64/RockPro64 which is better, but resources for "fixing everything" are not there. In case you can boot, than you don't have v3 ... I added this note because people think we must support it (without having boards, time and funds) and rush to fix problems after hardware folks failed with their design. This is what it seems happens with V3. Don't know.

Igor, thanks for reply. I see in download section "legacy kernel 4.4.y" -- marked as stable and supported. And I guess you are talking about 4.17+ regarding "mainline". I will start with 4.4 anyway, hope it has docker support... One thing which confuses me a LOT: "Rock64 V3 is not supported". If I booted, installed system to USB hdd (ssd)... Does it mean I'm not on V3 version ? Cannot find any description of V3 vs not-a-v3.

Just remember Rock64 is not there yet. Leave your daily operations on a Cubietruck for a little while at least those problems are not resolved:

"Fixed" at the download page https://www.armbian.com/rock64/ Armbian is 99% sponsored directly from our pockets so I will skip to answer this question.

Didn't see anything from a search of the forums, so ... on a Rock64 with Armbian, I have compiled the 8723bu driver since it is missing. However, when this driver is loaded, only 2G wifi APs are visible. I am trying to connect to a 5G wifi AP. Other devices do not have a problem connecting to this AP. The Armbian install just can't seem to see it. I see the usb wifi in iw and in iwconfig. I'm just not sure how to get the usb wifi to connect to 5G when only 2G wifi APs show up. I've tried the usb wifi in all three different USB ports, and in all cases it still can't see 5G wifi, only 2G. Is there some config file or manual command that I can issue that will support my wifi in seeing 5G wifi APs? Thanks.

I tried the tinkerboard and starting an access point via USB Wifi works just fine there. I've experienced no problems with different computers and phones. Using the same dongle for Wifi to create an access point with the rock64 isn't really as stable.. don't know what the problem might be. Connections are broken for some devices, and sometimes it's impossible to log on to the access point. So for the tinkerboard it works just fine, not so much for the rock64. If the drivers are fine then it's probably some other software related problems. Thanks for the update Igor!

Short answer: No (or: yes you can -- > see long answer) Long answer: what do you expect to change between 5.0 and 5.1? there's not much changed for RK3399 between those two except: New hardware – FriendlyELEC NanoPC-T4 and NanoPi M4, Radxa RockPi 4 means this patch needs to be adjusted: https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/add-board-rockpi4b.patch see which patches else break as well... probably a few others, e.g. every patch modifying the makefile of all the DTS. We don't switch kernels for one board.. we switch it for the whole boardfamily.. which means here rockchip64 with: RockPi, Renegade, Firefly, NanoPis 4 (at least on mainline they share their kernel), Rock64, RockPro64 and maybe a few I forgot.. It doesn't cost money, but it costs time... But you can do it on your own : clone buildscript altering those lines to the 'real mainline source' (we use ayufans mainline branch which currently not switched to 5.1) go through his 60 commits on top of mainline to figure out which of those are still needed (and which need to be fixed).. then apply our ~20 patches for this kernel and fix all the regressions you'll get here.. and if you really want to test something new, not only what has enhanced in the same 'drivers' you had in 5.0, you would need to adjust the config file as well to get the new stuff compiled (e.g. if you want to play around with the new scheduler --> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81a930d3a64a00c5adb2aab28dd1c904045adf57 ).

@TonyMac32 sounds familiar? Sounds like: btw.: https://www.humberg.de/rock64/ Art-Nr. Bezeichnung Beschreibung Amazon 105440 Rock64 4GB B0755RL2D4 links to a pine cluterboard on amazon..

and when browsing the differences between the kernels, I come up with this which looks pretty promising... https://github.com/ayufan-rock64/linux-kernel/commit/063c10147b3cfc326adda195f004b130dbd11ff6 -- scrap that, it's for the 3399 so not related

Hi. You can control the temperature of most SBC's by downclocking them. The Tinker Board overheats too quickly, but you can clock it to 1.6Ghz so it doesn't throttle(quickly). Or you can use a better heatsink. The NanoPi M4 has a maximum temperature of 69°C when clocked at 1.8Ghz/1.4Ghz. While clocked at 2Ghz/1.5Ghz it goes over it's throttle mark of 85°C without a fan. What other trades does the board need? Does it need USB3, gigabit ethernet, must it be raspberry pi compatible gpio's, ...? The most important factor seems to me that it must be stable and well supported. The Tinker Board isn't the best, it's got powering issue's since it's powered with microUSB. And it's the only board that broke(burned out hdmi caps) that I've had. I'm not too gentle with my boards, but the Tinker I had almost never used. I bought a new one and never used that one either. They are also very overpriced. The NanoPi M4 is the best all round board in my opinion. It's got everything a modern SBC should have, and it's very stable. I don't think I ever had mine crash. It depends on what your needs are, but an older well supported board like the Odroid C2 could be good too. It doesn't overheat. At 1.5Ghz it doesn't go over 70°C. It's powered with a barrel jack, it's very stable. But I do not know for how long they will keep selling them. It's an older quad-core SBC, but still the best IMO. It's the fastest when overclocked, doesn't consume too much, and it doesn't overheat. Temperatures Odroid C2 ---------------------- No OC : Idle with fan : 27°C 1.5Ghz Maxed fan : 40°C Idle no fan : 36°C Maxed no fan : 68°C OC : Idle with fan : 27°C 1.75Ghz Maxed out with fan : 42°C Idle no fan : 36°C Maxed out no fan : 71°C There are many companies who make industrial SBC's. But I know little to nothing of those. There are many SBC's, but making the right choice is very important. Most look good on paper, but that's not always the same in practice. The Rock64 for example could be great for your goals. But I haven't had good experiences with it. So I can't advice that. I think the PineH64 model b could become a good one too. But software isn't ready for it, and I don't know/think it's selling well. So the user base will be limited too. It does seem more stable to me than the Rock64 is. And quite a lot faster too.

We are evaluating many boards for Industrial purpose, often fails to pick the right one, form Raspberry PI to other boards, including Tinkerboard. We aim to bring the cost of the SBC to 60 to 100 USD, mainly used for Industrial, within 0-70 Deg C. In fact, I have posted similar questions to find out answers, including Rock64, Olimex etc. Olimex seems to be supporting Industrial temperature, but their A64 seems to have less USB ports. Many SBCs vendor advertise their board for Education, Hobby purpose, I see Nano PC boards, they advertise for robotics, Industrial purpose http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4 with WIKI stating working temperature is 0-70 Deg C, their product page suggest 0-80 deg C. We yet to order one Nano SBC, anyone had exposure with NanoPI M4 boards, readiness for Industrial application? More importantly, it support Raspberry PI pin compatibility and additional PCI and 2 USB hosts in GPIO. I am trying to understand Olimex vs Nano PC for industrial use, excluding -40 to +85 range

Info from "bad" kernel (freshly updated armbian bionic but it's the same for 6 months): https://transfer.nodl.it/fJ3wP/armbianmonitor.bad.txt (used my own transfer side because the one used by default by armbianmonitor -u doesn't show any url after upload) Info from "good" distro (that works on the "bad" boards is): http://ix.io/1HKS (somehow worked on this one) Distribution used is bionic-minimal-rock64-0.8.0rc9-1120-arm64.img.xz from https://github.com/ayufan-rock64/linux-build/releases The kernel is linux-headers-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64 install linux-image-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64 install u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1045-g9922d32c04 install and board package board-package-rock64-0.8-126 install This leads to the correct dependencies: https://github.com/ayufan-rock64/linux-build/releases/download/0.8.0rc9/linux-rock64-0.8.0rc9_arm64.deb please note that the rc10 of ayufan's distro breaks again what rc9 was fixing... Hope that helps

It's probably a matter of updating Armbian's kernel config to reflect ayufan's changes. I cannot test with Rock64 since I don't have one, just a Renegade.

One very quick fix would be switching to beta repository: - apt update and upgrade - armbian-config -> switch to nightly beta builds Kernel in beta repository should be close or identical to Ayufan's latest build ... but its not tested. Its on you to test it. After you switch to beta and if things works as expected, make a freeze (again in armbian-config -> system) and wait until things are properly tested by us and show up in stable repository. Then rather switch back to stable builds. Regarding board samples we have to discuss who is willing to join this debug party. I only have Rock64, IIRC its v1 with 4G. That will take some time to arrange due to ongoing holidays. I am shortly back to the office tomorrow and can check if I can do anything in this matter - in case suggestion to beta won't do any good. For monetary support please kindly use donate page, where its possible to choose between anonymous PayPal donation and invoice issued/billed to the company. In case you want a combination with publicly known amount and donor (forum) name, use https://forum.armbian.com/subscriptions/

Hi, We are using hundreds of Rock64 boards for a project and we are facing a lot of unreliabilities due to the kernel Armbian is currently using. After long discussions with Lukasz, Kamil, and Pine64 support, we concluded that some kernel fixes are necessary to have a reliable operation. These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian (it goes from kernel crash at boot to just some subtle miscalculations during some FPU operations) work perfectly well with his kernel. We are ready to support Armbian by providing v2 and v3 Rock64 4GB boards as well as a monetary support to get a kernel update as quick as possible to "un-brick" the 50-60 boards we currently can't use (and to avoid having to switch to another distribution). Please let us now if you're interested and how we could arrange that.

Thank you Sundry. The ATL (Atlanta, Georgia) Pine64 crashed and burned up (literally) after the heat sinks installed slide off yesterday. I ordered a new TVBox / SD card to replace the dead Pine64 today and it will be there tomorrow and configured by end of business day tomorrow. I shut local Pine64 off (near Chicago here) and switched over to using a TVBox for the mini automation server. Currently moving all of the automation software from the ATL Pine64 to another TVBox there in Atlanta. That said and relating to the Pine64 I had asked about a promised updated to the Rock64 that never materilized for a year so I gave up on them and decided to maybe try the RockPi4 with more features and same size as the Rock64. Posted on the Rock64 forum- yeah I was nagging a bit here... ROCK64 RTC December 3, 2017 Question: Will the RTC be available in the December 12, 2017 Rock64 release? Answer: RTC is working, just lacking battery backup. The battery backup circuit not available on December production, we plan to merge in on January production but not sure will happen. This due to there is super long lead time on PCB manufacturing. January 30, 2018 Question: Wondering if the RTC / battery stuff is available on current Rock54 hardware? If not can I have instructions for soldering in battery posts and utilize the Pine64 battery holder? Answer: Attached is the RTC mod circuit for ROCK64. However, ROCK64 don't support battery charging and no such circuit available. February 9, 2018 Question: Thank you tlimm. So the hardware RTC with battery changes have been abandoned eh? Basically then all I need to do is solder on a battery to the Rock64 board. I have done similar here with my tabletop touchscreens. Answer: The ROCK64 board with RTC battery connector is not abandon. Check out the FOSDEM PINE64 table stand photo and you may able to spot this board. This is just a minor change and we will revise board revision during production run sometimes on Q2 2018 timeframe. May 2, 2018 Question: Curious if the new Rock64 hardware release has the built in RTC battery connections? Answer: This release already on the plan and originally plan release to production on this month. However, due to focus on ROCKPro64 activity, and has push to June/July. June 11, 2018 Posting another couple of requests today. 1 - when will the updated Rock64 with RTC and Battery will be available? 2 - will the Rock64Pro ever have a battery RTC option? (it would be a great little firewall) August 6, 2018 tllim Wrote: already factor into new ROCK64 revision including PoE option and micro SD UHS design. Needs to test all new function first before release and this takes couple months. 02-08-2019, 07:17 AM I do not see any update to using a battery for RTC on newest Rock64 which was going to be utilized as an automation server combo firewall. I have not used the Internet for time in over 15 years now and always used an NTP server with GPS / PPS. Over the years transitioned to using the PFSense box with a serial / PPS connection to a GPS which provides great time for me. I am very particular about automation and time. We are at the two year mark here. Time to give up and move on. The best thing that happened for the Pine64 was Armbian. That said I have moved on now from the Pine64 / Rock64 stuff. I would like to add an RTC / Battery to the TV Box. (icing on the cake)

For some tasks the T3+ is faster. But only tasks that scale well over multiple cores like Blender. Most applications don't do that well and prefere a better single core performance. I indeed menth the Fire3. Too many names. That should be the most powerful for a low price, but indeed not much usb ports. You mentioned the Atomic Pi. Could be a valible option. It's cheap, x86 and very fast for that price. I once made a list of benchmarks of most of my sbc's. It is confusing since there ain't no perfect benchmark tools(and I wanted to show discrepencies). But it gives an idea of what you can expect. 7 zip, single core scores are important(small core-big core). Multi-core doesn't give exact results(not 100% se). Igrnore gtkperf, gimp and sysbench. I only used that to show it was useless. The H3 performs a bit worse than the Rock64 at 1.3Ghz. I should have added one, I've got enough of them but don't like them much except for light data server. You can perform the 7-zip tests yourself on the H3. Install p7zip-full, then 7z b (multicore test) sudo taskset c 0 7z b (single core) I only use decompression numbers since I do not want to mix compression with decompression and get a number of nothing. I also still think the M4 is the best choice. The only sbc that never had issues, and I use it daily.

Hi, and first of all thanks to everyone who's contributed here! By following the procedure in NicoD's excellent video I was able to get 4k video playback working on my rock64 -- truly amazing! However I have occasional segfaults in mpv, which make it unsuitable for regular use. I'd be quite happy to help debug these problems. Also a few questions which may or may not be relevant here: The board, and my monitor, should be able to do 4k@60Hz but I never get more than 4k@30Hz. Any clues why? I have two sound options, one is audio over HDMI which works fine, the other produces no sound. I can also get audio on a USB sound dongle, but never on the onboard 3.5mm jack. Why might that be? If I set the audio sink to HDMI, it reverts to the non-working option after a restart... Guess that's about it for now, thanks again!

It's been over a week and so far the rock64 NIC has been stable. I'll update further if anything changes. Many thanks for all the help.

My English isn't very smooth. First of all I'm sorry. I installed the arbian on a tv box. Model number X88 mini, Rockchip 3328, 2GB RAM, 16GB Flash. I installed version 5.75 Ubuntu rock64. The problem is that the internet does not connect. The WiFi and ethernet card certainly do not recognize. I've also installed and run the same version Debian and slackware onto this device. No one connects to the internet. I know it's a mismatch problem. These versions are designed for rock64. I want to use the X88 mini device as a Linux lover to be able to use. Can you help me? http://wiki.pine64.org/index.php/ROCK64_Main_Page