Search the Community

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

Thanks! If you plan to keep them concise, then this https://www.armbian.com/rock64/ is best place. Here you can check what is generally expected. If you agree, you get a password on email, the rest - technical details if needed - are written in the dashboard when you login.

First of all, thanks for sharing your opinions. My shortlist is: 1) Odroid HC-1 - due to known stability 2) Rock64 - it has USB3 on board and recently I purchased USB3 dock for 2 drives. Works nice, uas supported, but no trim. So idea was to connect 2 drives -ssd for system and rotational for data, but looks like trim support is not for me. That's not good, but, well. Nothing stops me for rotational drive for system. Or leave system on _good_ _expensive_ microSD, or make the "read only root", which is promising, but I guess kernel updates will suffer while changing "/boot" data. 3) Orange Pi Prime. Good for it's price, has wifi onboard (hope it supports host mode for hostapd in latest kernel), but no USB 3.0. (2) and (3) are 64bit I guess. Not sure I do have 64 bit tasks (e.g. Apache/nginx large file upload), but still good to have. Also I'm quite sure they both consume less power then HC1. The case is not electricity bill, but requirements for PSU. I run my "rig" from 10A 5V psu, which powers cubie, usb hub, couple of orange pi's (pc2 and pc) without any issues. Probably HC-1 will be ok with this setup also. Personally I really like coming Allwinner H6 boards. They are colder on same Mhz's, but Armbian is in testing stage for them and quite far from stable version.

well is it really cheaper? Assuming the 2gb ram is really a requirement: Board: 35$ Reliable USB-Sata bridge: 10$ you save roughly 5$.. Depending on other requirements, the HC1/HC2 has a lot more horse power and a proper casing solution which is still missing if you opt for the rock64.. If encryption is important maybe a ARMv8 might be a better choice. But then I would probably opt for a RK3399 (support not 100% mature yet) but decent mainline support and more options to bring up SATA than with a RK3328 (and the price for the cheaper RK3399 are quite okay)..

If you want a cheaper solution, maybe a supported board based on rk3328 like rock64 could be a good option since it has usb3 and gigabit ethernet.

Thank you WindySea. Yes just put the hardware sync once on boot. Will disable it. Noticed no time jumps but after ~48 hours the hardware clock is drifting off time sync. I started this little mini automation computer stuff here on RPi's with RTCs (used PiFace RTC shim) and then also on micro OpenWRT routers (made for tinkering with easy to get to GPIO pins) the got a Pine64 (pro bono to ticker with). I waited for over a year for the Rock64 to implement an RTC (it was promised) and I was told it would be in the next production batch....never came to being switched to maybe getting a RockPi4 (still thinking of this one) and meanwhile found out about Armbian and drifted over to getting a TVBox and running Armbian on it. I got in to the NTP stuff in the 1990's tinkering in my home sandbox. So then the nightly upgrade has created a timing issue that you are looking to resolve. Understood. Not sure if you are tinkering with any of the Armbian based TV boxes. Here looking to add a battery backed up RTC in a new automation server based on the S912 Octocore arm tvbox. I have yet to take one apart. Are there schematics out there in internetlandia for any of these devices?

Thanks, I've just made the update to my rock64 and will see how it goes over the next couple of weeks. The NIC is only stable for a maximum of a week.

Don't confuse me : Pine64 != Rock64 ... I don't understand why using Armbian_5.79.190418_Pine64_Ubuntu_bionic_dev_5.0.7.img. On my side, here is "dmesg | grep eth" give : root@pine64:~# dmesg | grep eth [ 4.651697] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 4.662672] dwmac-sun8i 1c30000.ethernet: Linked as a consumer to regulator.6 [ 4.677055] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 6 (expect 0) [ 4.685758] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported [ 4.693011] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported [ 4.700246] dwmac-sun8i 1c30000.ethernet: COE Type 2 [ 4.705231] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported [ 4.712026] dwmac-sun8i 1c30000.ethernet: Normal descriptors [ 4.717702] dwmac-sun8i 1c30000.ethernet: Chain mode enabled [ 18.403292] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found [ 18.403309] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 18.403316] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 31.712399] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 31.712430] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Yes, looks like the script used one of the branches, I do not have one branch with all patches, I tend to group patches into multiple branches to make it easier rebasing and review changes. If you keep the hdmi-sound base as you have and add https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x-hdmi-sound...rockchip-5.x-vpu-v2.patch as a patch you should have both branches. The 1080p H264, VP8 samples I have tested on my tinker board and even my rock64 running libreelec / kodi-gbm seems to play back fine using sw decoding. There are some libreelec test images at http://kwiboo.libreelec.tv/test/ for testing, built out of https://github.com/Kwiboo/LibreELEC.tv/commits/rockchip-5.x

Thank you very much for your answer! I have no problem to install vnc and browsers on linux environment I have problem only with this armbian release and wanted to take a shortcut and not download several dozen versions trying all of them one by one. So I've chosen a latest Ubuntu desktop and everything is fine now, everything working out of the box . And it doesn't call itself Rock64 anymore...

Yes, discussed at length on these forums, ignored by all... There is the tiny barrel jacks like that seen on the Rock64.

Hi all. Here my review video of the new Pine H64 model B. I also compare it with the Orange Pi 3, and it's older brother the Rock64. I hope you'll like it. Thank you. Greetings, NicoD

Thanks jpegxguy , I will try that. What is mkscr? and where does the boot.cmd live? Don't know why my rock64 gets this but i don't see other people discussing this. It's about once a week and the only recovery is to restart it.

HI, thank you very much for the script, working very well, just can't start kodi. It just exits to console, and getting following error: (i'm not running armbian, but the defualt ubuntu, and the script is working great also on ayufan, can watch YT, and videos, all cool) Apr 08 16:42:05 rock64 kernel: rockchip-vop ff370000.vop: [drm:vop_crtc_enable] Update mode to 1280x720p60, type: 11 Apr 08 16:42:13 rock64 kernel: dwhdmi-rockchip ff3c0000.hdmi: failed to get edid Apr 08 16:42:14 rock64 kernel: dwhdmi-rockchip ff3c0000.hdmi: failed to get edid DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS" Linux rock64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux THANKS FOR THE GREAT JOB

I can never seem to get the Rock64 to boot consistently from the SSD. Sometimes it comes up, sometimes it just "hangs". About once out of every 6 or seven times can I SSH into it - this is regardless of distro whether it's Bionic or Stretch. This is totall after flashing it to allow for USB boot. On the Pi, I was able to solve this 100% of the time by using a small microSD card with nothing but "bootcode.bin" and an empty file called "timeout" which tells the boot to hang for a bit while things "spin up" and the SSD (or HD) mass storage come available. Once I did this, all my Pi's work great. In addition with the Pi I am able to do all of this completely "headless" where I can restore an .img onto the SSD, copy over a wpa_supplicant.conf file and touch an ssh file and "boom", I can always get to it consistently without having to prep it by plugging in a monitor and keyboard to make manual changes before booting it headless. Are there any steps to make this a similar possibility with the Rock64? Is there some image I can put on an SD card that will accomplish the same thing and then let bootup happen and continue on the image restored to the SSD that is hanging off the USB 3.0 port? Personally I don't care if it has a microSD in it or not - as long as it boots consistently 100% of the time and all of the real I/O occurs on the SSD drive. Thanks! Ryan

I've read many tutorials and tried many tips on how to change console resolution in Armbian Ubuntu 18.04 on ROCK64 but couldn't find any solution. I'm stuck with 4K resolution and can't reconfigure it down to 1920x1080. armbian-config tool lacks such basic functionality. Is there any way to do resolution change or do I have to get 1080p monitor? It's fucked up doing such simple thing is so complicated. Wasted over 2 hours now researching and no solution yet.