Search the Community

You can install Armbian from sd-card to eMMC with sudo armbian-config The Rock64 does not support booting from USB only I believe.

I was wondering if there is a solution to boot from a USB thumb drive and flash the OS to an eMMC. Currently I´m running ARMbian on a Rock64 with an eMMC module installed. Since I´m still trying to figure out how to set up the device I keep reinstalling the OS. So it would be nice to have a way without opening the case, take out the eMMC, hook it up to the PC to flash and reinserting. Thanks in advance.

What about ROCK64? Featuring USB3 and GBE. 25$ for the 1GB RAM board.

locally on rockpro64 i have done this but no dtb generated.. $ make INSTALL_DTBS_PATH=$PWD/../output/dtb dtbs CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh make[1]: 'include/generated/vdso-offsets.h' is up to date. CHK scripts/mod/devicetable-offsets.h $ ls -la ../output total 8 drwxr-xr-x 2 labros labros 4096 May 23 08:10 . drwxr-xr-x 6 labros labros 4096 May 23 08:10 .. but is found this in custom kernel. Can i copy this dir manually in /boot and make symlink ? $ ls arch/arm64/boot/dts/rockchip Makefile rk3308-evb-amic-v11.dtb rk3328-box-liantong-avb.dts rk3368-px5-evb.dtb rk3399-evb-rev1-cros.dtb rk3399-opp.dtsi modules.order rk3308-evb-amic-v11.dts rk3328-box-liantong.dtb rk3368-px5-evb.dts rk3399-evb-rev1-cros.dts rk3399pro.dtsi px30-ad-d6-anx6345.dtb rk3308-evb-dmic-i2s-v10.dtb rk3328-box-liantong.dts rk3368-r88-dcdc.dtb rk3399-evb-rev1.dtsi rk3399pro-evb-v10.dtb px30-ad-d6-anx6345.dts rk3308-evb-dmic-i2s-v10.dts rk3328-box-liantong.dtsi rk3368-r88-dcdc.dts rk3399-evb-rev2-android-6.0.dtb rk3399pro-evb-v10.dts px30-ad-r35-mb-rk618-dual-lvds.dtb rk3308-evb-dmic-i2s-v11.dtb rk3328-box-plus-dram-timing.dtsi rk3368-r88.dtb rk3399-evb-rev2-android-6.0.dts rk3399pro-evb-v11.dtb px30-ad-r35-mb-rk618-dual-lvds.dts rk3308-evb-dmic-i2s-v11.dts rk3328-dram-2layer-timing.dtsi rk3368-r88.dts rk3399-evb-rev2-android.dtb rk3399pro-evb-v11.dts px30-ad-r35-mb-rk618-hdmi.dtb rk3308-evb-dmic-pdm-v10.dtb rk3328-dram-default-timing.dtsi rk3368-sheep.dtb rk3399-evb-rev2-android.dts rk3399pro-npu.dtsi px30-ad-r35-mb-rk618-hdmi.dts rk3308-evb-dmic-pdm-v10.dts rk3328.dtsi rk3368-sheep.dts rk3399-evb-rev2-cros.dtb rk3399pro-npu-evb-v10.dtb px30-ad-r35-mb-rk618-hdmi-lvds.dtb rk3308-evb-dmic-pdm-v11.dtb rk3328-evb-android-avb.dtb rk3368-sheep-lvds.dtb rk3399-evb-rev2-cros.dts rk3399pro-npu-evb-v10.dts px30-ad-r35-mb-rk618-hdmi-lvds.dts rk3308-evb-dmic-pdm-v11.dts rk3328-evb-android-avb.dts rk3368-sheep-lvds.dts rk3399-evb-rev2.dtsi rk3399-rock960-ab.dtb px30-ad-r35-mb-rk618-lvds.dtb rk3308-evb-ext-v10.dtsi rk3328-evb-android.dtb rk3368-sziauto-rk618.dtb rk3399-evb-rev3-android-6.0.dtb rk3399-rock960-ab.dts px30-ad-r35-mb-rk618-lvds.dts rk3308-evb-v10.dtsi rk3328-evb-android.dts rk3368-sziauto-rk618.dts rk3399-evb-rev3-android-6.0.dts rk3399-rockpro64.dtb px30-android.dtsi rk3308-evb-v11.dtsi rk3328-evb-android.dtsi rk3368-xikp-avb.dts rk3399-evb-rev3-android-6.0-edp.dtb rk3399-rockpro64.dts px30-dram-default-timing.dtsi rk3308-fpga.dtb rk3328-evb.dtb rk3368-xikp.dtb rk3399-evb-rev3-android-6.0-edp.dts rk3399-rv1-android.dtb px30.dtsi rk3308-fpga.dts rk3328-evb.dts rk3368-xikp.dts rk3399-evb-rev3-android.dtb rk3399-rv1-android.dts px30-evb-ddr3-lvds-v10.dtb rk3308k.dtsi rk3328-rock64-android-avb.dtb rk3368-xikp.dtsi rk3399-evb-rev3-android.dts rk3399-sapphire.dtsi px30-evb-ddr3-lvds-v10.dts rk3308-voice-module-board-v10.dtb rk3328-rock64-android-avb.dts rk3399-android-6.0.dtsi rk3399-evb-rev3-android-edp.dtb rk3399-sapphire-excavator-box-android-6.0.dtb px30-evb-ddr3-v10.dtb rk3308-voice-module-board-v10.dts rk3328-rock64-android.dtb rk3399-android.dtsi rk3399-evb-rev3-android-edp.dts rk3399-sapphire-excavator-box-android-6.0.dts px30-evb-ddr3-v10.dts rk3326-863-cif-sensor.dtsi rk3328-rock64-android.dts rk3399-box-808-android-6.0.dtb rk3399-evb-rev3-android-lp4.dtb rk3399-sapphire-excavator-box.dtb px30-evb-ddr3-v10-linux.dtb rk3326-863-lp3-v10-avb.dtb rk3328-rock64-android.dtsi rk3399-box-808-android-6.0.dts rk3399-evb-rev3-android-lp4.dts rk3399-sapphire-excavator-box.dts px30-evb-ddr3-v10-linux.dts rk3326-863-lp3-v10-avb.dts rk3328-rock64.dtb rk3399-box-android-6.0.dtsi rk3399-evb-rev3-android-mipi-edp.dtb rk3399-sapphire-excavator-disvr.dtb px30-evb-ddr4-v10.dtb rk3326-863-lp3-v10.dtb rk3328-rock64.dts rk3399-box.dtsi rk3399-evb-rev3-android-mipi-edp.dts rk3399-sapphire-excavator-disvr.dts px30-evb-ddr4-v10.dts rk3326-863-lp3-v10.dts rk3366-android-6.0.dtsi rk3399-box-rev1-android-6.0.dtb rk3399-evb-rev3-cros.dtb rk3399-sapphire-excavator-edp-android-6.0.dtb px30-evb-ext-rk618.dtb rk3326-863-lp3-v10.dtsi rk3366-android.dtsi rk3399-box-rev1-android-6.0.dts rk3399-evb-rev3-cros.dts rk3399-sapphire-excavator-edp-android-6.0.dts px30-evb-ext-rk618.dts rk3326-86v-v10.dtb rk3366.dtsi rk3399-box-rev1-disvr.dtb rk3399-evb-rev3.dtsi rk3399-sapphire-excavator-edp-avb.dtb px30-z7-a0-rk618-dsi.dtb rk3326-86v-v10.dts rk3366-fpga.dtb rk3399-box-rev1-disvr.dts rk3399-excavator-sapphire.dtsi rk3399-sapphire-excavator-edp-avb.dts px30-z7-a0-rk618-dsi.dts rk3326.dtsi rk3366-fpga.dts rk3399-box-rev1.dtb rk3399-firefly-android.dtb rk3399-sapphire-excavator-edp.dtb rk1808-dram-default-timing.dtsi rk3326-evb-ai-va-v10.dtb rk3366-sheep.dtb rk3399-box-rev1.dts rk3399-firefly-android.dts rk3399-sapphire-excavator-edp.dts rk1808.dtsi rk3326-evb-ai-va-v10.dts rk3366-sheep.dts rk3399-box-rev2-android-6.0.dtb rk3399-firefly-linux.dtb rk3399-sapphire-excavator-edp.dtsi rk1808-evb.dtsi rk3326-evb-ai-va-v11.dtb rk3366-tb.dts rk3399-box-rev2-android-6.0.dts rk3399-firefly-linux.dts rk3399-sapphire-excavator-linux.dtb rk1808-evb-v10.dtb rk3326-evb-ai-va-v11.dts rk3368-android.dtsi rk3399-box-rev2-disvr.dtb rk3399-fpga.dtb rk3399-sapphire-excavator-linux.dts rk1808-evb-v10.dts rk3326-evb-ai-va-v11-i2s-dmic.dtb rk3368-cif-sensor.dtsi rk3399-box-rev2-disvr.dts rk3399-fpga.dts rk3399-sched-energy.dtsi rk1808-evb-x4.dtb rk3326-evb-ai-va-v11-i2s-dmic.dts rk3368-dram-default-timing.dtsi rk3399-box-rev2.dtb rk3399-gru.dtsi rk3399-tve1030g-avb.dtb rk1808-evb-x4.dts rk3326-evb-lp3-v10-avb.dtb rk3368.dtsi rk3399-box-rev2.dts rk3399-gru-gru.dtb rk3399-tve1030g-avb.dts rk1808-fpga.dtb rk3326-evb-lp3-v10-avb.dts rk3368-evb-act8846.dtb rk3399-disvr-android.dtb rk3399-gru-gru.dts rk3399-tve1030g.dtb rk1808-fpga.dts rk3326-evb-lp3-v10.dtb rk3368-evb-act8846.dts rk3399-disvr-android.dts rk3399-gru-kevin-r0.dtb rk3399-tve1030g.dts rk3308-ai-va-v10.dtb rk3326-evb-lp3-v10.dts rk3368-evb.dtsi rk3399-dram-default-timing.dtsi rk3399-gru-kevin-r0.dts rk3399-tve1030g.dtsi rk3308-ai-va-v10.dts rk3326-evb-lp3-v10.dtsi rk3368-geekbox.dtb rk3399.dtsi rk3399-gru-kevin-r1.dtb rk3399-tve1205g.dtb rk3308b-evb-amic-v10.dtb rk3326-evb-lp3-v10-linux.dtb rk3368-geekbox.dts rk3399-early-opp.dtsi rk3399-gru-kevin-r1.dts rk3399-tve1205g.dts rk3308b-evb-amic-v10.dts rk3326-evb-lp3-v10-linux.dts rk3368-p9-avb.dts rk3399-evb-cros.dtsi rk3399k-opp.dtsi rk3399-videostrong-linux.dtb rk3308b-evb-ext-v10.dtsi rk3326-evb-lp3-v10-robot-linux.dtb rk3368-p9.dtb rk3399-evb.dtsi rk3399-linux.dtsi rk3399-videostrong-linux.dts rk3308b-evb-v10.dtsi rk3326-evb-lp3-v10-robot-linux.dts rk3368-p9.dts rk3399-evb-rev1-android-6.0.dtb rk3399-mid-818-android-6.0.dtb rk3399-vop-clk-set.dtsi rk3308.dtsi rk3326-linux.dtsi rk3368-p9.dtsi rk3399-evb-rev1-android-6.0.dts rk3399-mid-818-android-6.0.dts rk3399-vr-android.dtb rk3308-evb-amic-v10.dtb rk3328-android.dtsi rk3368-px5-evb-android.dtb rk3399-evb-rev1-android.dtb rk3399-mid-818-android.dtb rk3399-vr-android.dts rk3308-evb-amic-v10.dts rk3328-box-liantong-avb.dtb rk3368-px5-evb-android.dts rk3399-evb-rev1-android.dts rk3399-mid-818-android.dts

Only choose system. And no other options. Then glamour I think. That installs the drivers for Chromium. Streaming is a 32-bit Chromium running in Docker. So that you don't need. Please also tell your experiences with it. I've sometimes got Chromium crashing. I'm not sure if it's with all Rock64's.

Just to add to this: root@rock64:/home/rock64/Desktop# glxgears libGL error: unable to load driver: rockchip_dri.so libGL error: driver pointer missing libGL error: failed to load driver: rockchip but under es2_info: GL_RENDERER: Mali-4 Help?!

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?

From the media script thread: Chromium is unusable right now. I'm having to use Firefox. EDIT1: I ran the media-script .sh and it auto installed the default selection and I also ticked "streaming" which I know is Chromium... EDIT2: I'm on the latest Chromium for Ubuntu bionic... 73.x EDIT3: This is what Chromium says under "chrome://gpu": What am I doing wrong? es2_info: and glxgears:

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.

I have a Rock64 v2. For my project I wish to connect the board to an MCP3008 ADC chip via SPI so I can read some analog sensors. Pretty straightforward. But when I look at /lib/modules/4.4.178-rockchip64/kernel/drivers I see there are modules for i2c, usb, one wire, GPIO ... everything but SPI. Am I out of luck? ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 4.4.178-rockchip64

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

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:

Hi all. In download section i do see "large heatsink required" for Rock64. Can anyone post any links to eamples of good heatsink with proper size ? I will be migrating "home server" from Cubieboard2 to Rock64 and chasing long-term stable operation. When board just booted and "does nothing", cpu remains pretty cool. However i'd better be prepared. thanks in advance for tips.

"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.

Hello all! I bought a Rock64 V3 and it wouldn't boot Armbian, not any other GNU/Linux based OS that I tried, I got in touch with Pine64 and they said: >The issue on the SD boot on the ROCK64 SBC is the GPIO0_D6 (SDMMC0_PWREN) default needs to set high instead of lets this pin floating at Linux DT (Device Tree). The ROCK64 V3 has the high speed SD access design which can double boost up with proper software driver. We will advise developer to update the OS build (stock Android already implemented) accordingly. >Please refer to ROCK64 SBC v3.0 Change Notice, http://files.pine64.org/doc/rock64/Rock64%20Ver%203%20change%20notice.pdf >Now the developer is work on it. When the OS ready, the developer will update at Pine64 Forum. Please check on Pine64 Forum (https://forum.pine64.org/forumdisplay.php?fid=85) When is they estimate for when Armbian will support this new driver? Thank you, Joe.

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 ).

Sorry if this in the wrong spot. I need a bit of help here, I once or twice updated the kernel on the Rock64 from older versions but I've always ran into an issue where it just wouldn't boot anymore and needed to be re-flashed. I run a always up server that has to have little to no downtime and I wish to avoid having to re-flash again. So I want to know if its safe or not to upgrade to 4.4.174 from 4.4.167 I can provide more info if needed. Thanks

@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..

I have seen many problems with the Rock64 v3 in the last few days. Many customers have told me that existing Rock64 images suddenly no longer boot in v3. We have verified this and found that apparently v3 can not cope with many SD cards. The booting of eMMC goes without problems. If a customer has bought a new v3 and nothing works, contact us, we will send you an emmc card for the purchase price without any profit. markus@humberg.de

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.