Search the Community

Add me to the list. Currently I've reluctantly solved by moving the SSD to the USB2 port, which nulls one of the main reasons for having chosen the Rock64. However, I have this idea that the problem is not the kernel, but u-boot which does not properly initialize the USB3 port. It is a fact that sometime you are able to boot from USB3, as long as you have no other current-dragging devices connected (included the HDMI cable). It is still a shot in the dark, i.e. will mostly fail, but if you have other devices connected, in my own experience, there is 0% possibility that the boot from USB3 succeeds. And no, using an USB3 hub does not make any difference, I agree.

I have left it running now for a few weeks and it runs fine. It did error out on one update and I rebooted it and updated it again and it is fine. NOTE: this is only for the T95Z Max S912 TVBox. Thinking though of freezing the updates now on it.... _____ ___ ____ _____ ____ ___ _ ____ |_ _/ _ \| ___|__ / / ___|/ _ \/ |___ \ | || (_) |___ \ / / \___ \ (_) | | __) | | | \__, |___) / /_ ___) \__, | |/ __/ |_| /_/|____/____| |____/ /_/|_|_____| Welcome to ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 3.14.29 System load: 1.45 1.29 1.22 Up time: 18:57 hours Memory usage: 10 % of 2733MB IP: 192.168.244.250 CPU temp: 35°C Usage of /: 29% of 29G [ Menu-driven system configuration (beta): sudo apt update && sudo apt install armbian-config ] Last login: Wed Jul 3 20:46:17 2019 from 192.168.244.232 root@HS3-ATL:~# Note that I updated the release version to indicate that it is a S912 as it kept going to showing a Rock64 on the update. I also found that I had a bad SD card running for a while which caused me much grief. This box is running Home Assistant, HomeSeer, Node Red, Mosquitto, Leviton OmniLinkBridge (MQTT) and testing with a Digi 8 port edgeport. So in addition it is running a connection to a UPB controller, ethernet ZWave, RFID. I am testing a LoRa RFID connection via two transievers with a range of 8 Km. I do not know what dtb file it is using cuz it is not in the uEnv.ini file such that it is using defaults. root@HS3-ATL:/boot# ls aml_autoscript fan.sh aml_autoscript.zip hdmi.sh armbianEnv.txt Image armbianEnv.txt.out initrd.img-4.4.182-rockchip64 armbian_first_run.txt.template s905_autoscript boot.cmd s905_autoscript.cmd boot.scr System.map-4.4.182-rockchip64 config-4.4.182-rockchip64 uEnv.ini dtb uInitrd dtb-3.14.29.old zImage dtb.old root@HS3-ATL:/boot# cat uEnv.ini bootargs=root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyS0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 mac=${mac} It just works fine as an Ubuntu server for automation. I have no keyboard, mouse or HDMI monitor connected to it. Note that the kernel is old: root@HS3-ATL:/boot# uname -a Linux HS3-ATL 3.14.29 #26 SMP PREEMPT Sun Jul 29 11:26:15 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux It is only for this model TVBox S912. Rest of the S912 boxes are running with newest kernels just fine. IE: when trying a new kernel on this one the Gb NIC wasn't working and only wireless and bluetooth worked. Download and install this build for this box to work. (note that I never tried WLAN or Bluetooth with it and do not need it). It is listed as Armbian_5.44_S9xxx_Ubuntu_bionic_3.14.29_server_20180729.img.xz dated 07292018. Going to kernels 4.X and 5.X did not work for me with this specific device. Never did boot it to Android or even looked. Maybe my approach was wrong? Any guidance on updating Android and extracting DTB file for use with Armbian would be appreciated. Just purchased a second BeeLink BT3 Pro here. NOT for TV rather just for Automation. Got the first one new for $65 and second one for $100. It is not worth the $150 that Amazon is selling them for. I do now see a similiar to BeeLink BT3 pro with an SSD card slow underneath for around $100. For KODI use have settled on using CoreElec with an old kernel just for the HD 4K features. For server use and no video have settled on currently posted kernel. Still liking the footprint versus the RPi (even the RPi 4).

@Igor :-/ @arox speaking personally (not "for Armbian") the Rock64 is a troubled piece of hardware, there are 3 revisions in the wild, each one with differences not addressed by the vendor to work together. Other options with more consistency and a bit more conservative release approach will yield better results.

Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z LibreELEC-RK3328.arm-9.1.001-rock64.img.gz Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump. One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board !

Hello, I received a Rock64 board 2G two days ago and suffered the most impressive failure ever : panic, freeze, failed restart, segfault ... I tried all I was able 2 think off : 3 different PSU, 3 SD card and an USB drive, 3 armbian version (and the last from yesterday) and an openelec image ... Someone got an idea - an old kernel ? - or should I consider the board defective and throw it away ? The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...)

I have tested it today and it still does not work. I get "Warning communications lost with UPS". It works on Rock64. Both Odroid C2 and Rock64 use latest Armbian Ubuntu 18.04. It looks like something is not quite right with the Odroid C2 image.

Impatiently I tested with the Balbes image, as soon as I start ./flash.sh it says "The device does not support this operation!" Is the script/sw written for an A5XMax and does not work on A5XMax+ ? Needless to say the box did not boot when powered up, I also tried the Rock64 image, same result. Label on my box says A5Xmax+432183702296

No, disabling the eMMC on Rock64 isn't done thru DTB, but by shorting 2 pins jumper nearby the recovery button. EDIT : Oh ! I´ve just saw that you were talking about "a55 tv box.Rk3328", not your Rock64 ... So, my answer isn't related ...

If I have a little time I will write a description and upload the image. You can flash the Balbes image too with the script, maybe it will work. But a few things will certainly not work, eg wifi, led display. I don't know exactly, I didn't tried. My first try was the official rock64 image. Basic functions works with that.

Thanks for proposal.... but .... root@srv-rock64-130:~# apt-get update --no-allow-insecure-repositories Ign:1 http://ftp.debian.org/debian stretch InRelease Atteint:2 http://security.debian.org stretch/updates InRelease Atteint:3 http://ftp.fr.debian.org/debian stretch-backports InRelease Atteint:4 http://ftp.debian.org/debian buster InRelease Atteint:5 http://ftp.fr.debian.org/debian stretch-updates InRelease Réception de:6 http://deb.ayufan.eu/orgs/ayufan-rock64/releases InRelease [1 339 B] Atteint:8 http://ftp.debian.org/debian stretch Release Réception de:9 http://deb.ayufan.eu/orgs/ayufan-rock64/pre-releases InRelease [1 339 B] Ign:7 https://apt.armbian.com stretch InRelease Err:10 https://apt.armbian.com stretch Release server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Lecture des listes de paquets... Fait E: The repository 'http://apt.armbian.com stretch Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. root@srv-rock64-130:~# echo $? 100 So that this solution is not possible for me because apt management is done accross Ansible tools in a production board ....

Yet another answer to myself. According to this (valued opinion of @tkaiser) - USB3@ARM SBC + USB3 Hub is totally bad idea: https://forum.openmediavault.org/index.php/Thread/24145-OMV-rock64-problem-with-USB-Hub/ Still yet another problem with USB2. Both ports works ok with directly connected devices. Attaching usb2 hub to lower USB - still ok. To upper USB - gives a lot of errors in dmesg with periodic device reset. Actually attaching usb voltmeter to hub showed BIG undervoltage (4.4v). Powering USB hub partially resolves situation, but still errors if using upper port. Older usb hubs (let's say before-AliExpress-era) work slightly better. In my opinion, it's not a problem of kernel, but hardware itself. Situation is much more clear now. I need to connect 2 HDD drives (one for system + one for data). Time to give up SSD idea, since my box ( 8882:009d http://en.sharkoon.com/product/1686/10066) does not pass "TRIM" command, which is probably vital for SSD.

Update... It was guilty USB3 hub. I'm willing to have more than one USB3 port on rock64, but look... Hub works fine on standart PC, but adding it to Rock64 gives this weird effect. Can anyone confirm, that USB3 HUB is not recommended to use for connecting boot USB3 SSD ? It's not a question of power - I'm using good PSU. And drive is SSD (consumes not too much). Thanks in advance.

I currently run an Odroid XU4, Odroid HC1 and Rock64 all 24x7. I never have any problems with them. They all run from decent power supplies though, connected to a UPS. The only board I've have stability issues with is an Espressobin. I've also got a Tinkerboard, a couple of Pine64's, Raspberry Pi 2 and 3 and an old Cubietruck. They've all been stable too. Sounds like you need to sort out your power supply problems first.

I'm not sure what will and won't be a worthy overlay to put directly into Armbian itself with the current script structure, I intend to document the ones I add here, @martinayotte may as well if he's bored. :-P I will be focusing on RPi GPIO compatibles, since those are nice pre-packaged devices in general. I have Tinker, RockPi 4, Le Potato/K2/C2, Tritium H2+/3/5, Rock64, Renegade, and some others. Everything here is a placeholder at the moment. Status Tinker Le Potato Meson64 Renegade Tritium Automation Hat Generic DAC (Pi) MCC 118 DAQ MicroDot PHAT Inky WHAT (e-ink) ENC28J60 for Pi

Support for Rock64 is not matured - probably we labelled it "supported" too quickly. There are three revisions out there and all seems to have issues ... Moved from forum "Board doesn't start" to RK3328 forum where such discussions take place.

That indeed isn't good at all. I'm from Europe so I haven't got a clue where to buy when you're from South-America. It's this PSU. https://www.cloudmedia.com/?product=rock64-pinebook-pine-h64-5v-3a-switching-power-supply I'm using a different one for it, a 4A EU PSU. But 3A should be sufficient. This is what you need to look for : 5V (at least) 3A Type H 3.5mm OD/1.35mm ID barrel ‘coaxial’ type I'd trow away that PSU you've got before it damages anything(hd/sd-card). I've seen a lot of undervolting in my times but under 4V is very rare. With a good PSU/cable you should never go under 4.8V. (tell that to the raspberry pi foundation) Good luck, greetings.

I just did this test and saw that the voltage is below 5V (around 4,4 and 4,6) when the Rock64 is using a USB2.0 HDD connected to its USB3.0 port (the only method that works until now, with bad write performance). Also, there's oscillation to under 4V, even if there's a small load. If the power supply were good we should see steady 5V or more, right? Can anyone point me to a legit power supply in Aliexpress? Or maybe some seller on ebay that ships to South America?

From what I've heard, this USB 3.0 drive I have (650mA) consumes less than the 2.0 drive I'm using now (850mA). Developers say that the Rock64 outputs up to 950mA on the USB 3.0 port. Should be enough, so that's why I'm trying to test the power supply.

To be future proof USB 3.0 is better. But all mine are USB2. Transfer rates are a lot higher with USB3, so I expect it to consume a bit more. Dit you try it on the USB2 ports of the Rock64? Did you try other storage devices on the Rock64? Do they mount ok? I should have a 2.5" drive laying around and I've got a usb3 to sata adapter. If I find time I'll try it out. Can't promise anything.

"Stable Armbian" being the version from February here https://dl.armbian.com/rock64/ ??

Armbian nightly? I didn't realise it was getting built, off to check I go! :d The latest ayufan pre release suggests memory speed locked to 1600? For rockpro64 I guess? https://github.com/ayufan-rock64/linux-build/releases

Try using a usb voltage meter on the USB3 port of your Rock64 and see what voltage it is. With undervoltage you've got problems with mechanical hard drives.

The PineH64 model B is a bit better designed than the OPi3. It's got a lot less problems, and a bit better heat characteristics. The H6 SoC's do need a fan to run maxed out at 1.8Ghz. But you could clock it a bit lower if you'd like to passively cool it. The software isn't ready yet for it. But I expect this to become a well supported board. Here my review and comparison video of the Pine H64 model B with OPi3 I'm in love with the RK3399 boards from FriendlyElec(NEO4/M4/T4). But now the NEO4 is at $50. It was cheaper when released. It only has got 1GB ram, a bit worse cooling than the NanoPi M4(my favorite). But they've got great VPU support in Armbian and in FriendlyElec images. But of course those are more expensive. As they've already said. The Amlogic S905 boards are a good choice since they've got good VPU support. But on higher display resolutions than 1080p my Odroid C2 lags a lot. There's not that much other choises. The Rock64 has problems with the media script. Allwinner H5 SoC's should be well supported for this. But I don't have any H5 board. So I have not seen this working well. ( @mindee I'd love to review the NanoPi K1 Plus)

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

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