Search the Community

I'm trying to run NixOS on my NanoPC-T4, and it's having trouble detecting the NVMe drive connected to the M.2 port. I've tried running Armbian, specifically Armbian_21.02.1_Nanopct4_focal_current_5.10.12.img downloaded from here, and it appears to detect it just fine. On NixOS I'm running a stock 5.10.13 kernel, which is newer than the 5.10.12 that Armbian is using. I'm assuming that I'm missing some kind of specific patch that makes this work on Armbian. I examined the kernel I was running on Armbian: qwe@nanopct4:~$ ls -l /boot/ | grep rockchip total 63872 -rw-r--r-- 1 root root 221399 Feb 3 19:55 config-5.10.12-rockchip64 lrwxrwxrwx 1 root root 22 Feb 4 12:11 dtb -> dtb-5.10.12-rockchip64 drwxr-xr-x 6 root root 4096 Feb 4 12:11 dtb-5.10.12-rockchip64 lrwxrwxrwx 1 root root 26 Feb 4 12:10 Image -> vmlinuz-5.10.12-rockchip64 -rw-r--r-- 1 root root 15339843 Feb 4 12:14 initrd.img-5.10.12-rockchip64 -rw-r--r-- 1 root root 5835612 Feb 3 19:55 System.map-5.10.12-rockchip64 lrwxrwxrwx 1 root root 26 Feb 4 12:14 uInitrd -> uInitrd-5.10.12-rockchip64 -rw-r--r-- 1 root root 15339907 Feb 4 12:14 uInitrd-5.10.12-rockchip64 -rw-r--r-- 1 root root 28582400 Feb 3 19:55 vmlinuz-5.10.12-rockchip64 And it appears to be be coming from a linux-image-current-rockchip64/now package: qwe@nanopct4:/boot$ sudo apt list | grep current-rockchip64 linux-dtb-current-rockchip64/now 21.02.1 arm64 [installed,local] linux-headers-current-rockchip64/focal 20.11.4 arm64 linux-image-current-rockchip64/now 21.02.1 arm64 [installed,local] I'm trying to identify what source was used to build this image, but there is no linux-source package. I looked at the repo: https://github.com/armbian/build And I found this: https://github.com/armbian/build/blob/a1e96e68d864ddc2fef169f3f503a9493311313b/config/sources/families/rockchip64.conf But it seems to only reference kernel version 4.4.202 from https://github.com/ayufan-rock64/linux-kernel which looks wrong. Can someone please help me figure out what kernel source was used to build the image? Ideally I'd find the exact patch that fixes the NVMe drive and apply just that, but I'd settle for building the whole thing if it works.

And thank you for the info concerning the new models to come RK3566 and RK3568 it seems to be really promising but it will surely also be much more expensive, novelty oblige .. So far I have only seen 2 SOCs with this rk3566 / 68 (geniatech and rock64) are there other manufacturers?

Rock64's image with 4.x kernel and desktop is as the same as it.log: http://ix.io/2PXh

Rock64's image with 5.x kernel didn't have filesystem error, log: http://ix.io/2PX6

OK,station M1's image with 4.x kernel and desktop had a filesystem error after the first boot,but the second time it fixed the error correctly.log: http://ix.io/2PWU. I'll try rock64's image soon.

ummm,though I can't understand why rock64's and station M1's images still need be tested while renegade's image is already works(?),I will do these test later.Also,I tried install 5.x kernel on the image with 4.x kernel,still couldn't display.But,I run it through chroot and updated system diagnosis (http://ix.io/2PWu),hope that would help.

Hardware: Rock64 Image: Buster desktop stable4.4.y (Armbian_21.02.1_Rock64_buster_legacy_4.4.213_desktop.img) I was running mainline and wanted to try this, so I could get acceleration, However, I couldn't get it to boot properly. I see it scanning the installation partition at boot. I get the "welcome to Armbian" boot message and after a few more messages, it goes into kernel panic. I tried with different SD cards, including the one that was working with mainline.

Yes, as I told you a few posts above, Renegade is the commercial name that Libre Computer uses for roc-rk3328-cc I also have the board, and I was very active developing for it in the past when bringing it up as CSC. The problem you mention, about filesystem getting corrupted, also happens in my board. But, since nobody else complained about it, I assumed it was just my defective unit and forgot about it. But now, you mention the same problem, and some other user also recently reported it. So, my first question: ¿Do you have emmc, or only SD card? The quickest workaround is to use a "Current" (5.10.y) image to flash "Legacy" (4.4.y) to the emmc, as described in this post. Also, since you seem to be using a old Rock64 image without problems, please try the new Rock64 image I linked above, and post here the results. If that one does not work, please try the images for Station M1, as @balbes150 adviced above. We will appreciate if you perform these tests and post here the results. It can be helpful not only for you, but also for other users. [EDIT]: And please, post the output of "sudo armbianmonitor -u" for the tests, so we can figure out what is failing.

The Rock64 uses DDR3, the roc-rk3328-cc uses DDR4 memory. Your model is closer to Renegade. https://www.armbian.com/renegade/ https://libre.computer/products/boards/roc-rk3328-cc/

ummm, in fact,my board isn't rock64,it's firefly's roc-rk3328-cc,which even doesn't have an armbian image,I just find a rootfs which MIGHT BE suitable to my board. If it is convenient for you,could you tell me which version of kernel is suitable?I will try to build it.

That error was present only in older kernels, it is solved already. I looked at your logs, and for some reason you are using a very old kernel (4.4.194). Try this image instead: https://redirect.armbian.com/region/EU/rock64/Buster_legacy_desktop Notice that Rock64 is not offcially supported by Armbian anymore, due to issues with hardware quality and lack of compatibility between different HW revisions. So I cannot guarantee the image will work for you.

The problem with the nand-sata-install is that, if your SD card or reader is failing, they will replicate the errors. In this particular case, I would recommend booting the board and then flashing the image on the fly from the web, like this: wget https://redirect.armbian.com/rock64/Buster_legacy_desktop -O - | xzcat | dd of=/dev/mmcblk0 bs=1M Replacing /dev/mmcblk0 with the device node corresponding to your emmc.

Ok, I've been trying for 3 days with the native SanDisk Ultra 32Gb HC1 (maybe a bit tired ?) and another new Integral 128 Gb SD XC1 A1. The problems are the same so you're probably right. Is the SDXC enough good quality ? I bought a Emmc 32Gb with the Rock64 but i didn't have the serial cable to flash it. I'm now looking for a way to flash the emmc from just a SD card. It seems nand-sata-install or arbian-config scripts should do the job ?

SQL database errors, weird APT errors... It looks to me like a faulty storage media. Try with some new good quality SD card, like Sandisk Ultra. [EDIT]: IIRC, Rock64 has many hardware problems, that is the reason why we don't support it anymore. That can be the cause for the storage failures, probably a faulty SD card reader.

Hi, Thank you for your help :-) Reinstall from scratch is getting better : i guess i had encoding problems choosing locales according to my location France. I said "Yes" and now i just say "No" and i don't have error with "sudo apt update". About Kodi, i launched it once from login screen, choosing Kodi-GBM with my main account user/password. I got menu screen but impossible to interact : keyboard/mouse not working anymore. After reboot, i'm now stucked at the Kodi splash screen. No menu. A sudo reboot from Putty console took a moment to effectively reboot the Rock64, and no more Kodi menus appearing... 2021-02-09 21:47:44.903 T:547990247008 ERROR: DBus error: org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files [...] 2021-02-09 21:47:48.920 T:547865369984 ERROR: SQL: [Epg12.db] SQLite error SQLITE_ERROR (no such table: version) Query: SELECT idVersion FROM version 2021-02-09 21:47:48.957 T:547865369984 ERROR: Process error processing job So i had a look at ~/.kodi/userdata/Database/ and renamed Epg12.db to Epg12.db.old Now, lauchning Kodi, i got a Dbus error in log https://postit.ilinux.fr/?02830bec8bcc36d9#2QAW5vaRzKjxNjPgxXGGfuWsr8TrjEnpE3AFobo4mQjb

Hello, I have a Rock64 and i would like to install Kodi on Armbian Buster Legacy 4.4.213 Desktop. I flashed it with Etcher, it seems OK. Then i did : sudo apt remove command-not-found sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3328 --install-recommends The app command-not-found was preventing me from updating with apt. I got an error. After the reboot, when I select Kodi-GBM in the menu and log-in with my main user account, i got Kodi Leia fullscreen and nothing else happens. I'm stucked here. Am i making a mistake ? Have you any idea of what is happening ? Where should i see some relevant logs about Kodi's launching ?

OK. After doing much testing, I can say that there is something wrong with Chromium. The situation is totally random and I reproduced the issue in many conditions. It is not related to anything but the browser itself. This is really sad. Everything works very well (I even play youtube through mpv/ytdl) but this hardware accelerated chromium is totally unstable. There was not even one time when it did not crash on me, which is a shame because for those websites that don't have a streaming implementation in kodi/youtube-dl, the browser is the only way to access the media and with Rock64 and the current chromium it is unusable. Q1. Is there anything that could be done to increase the stability in Chromium? (Like some options in the browser) Q2. Will there be any other hardware-accelerated browser?

Since this is the thread linked on the Rock64 page with "In case you face stability issues, check this", I'm posting my issue experience and different workaround here. After getting pretty consistent freezing even while idle on my 1GB Rock64 board I flashed the SPI to enable USB boot and switched to booting from external SSD drive rather than SD card and it has completely cleared up my freezing issues while also giving a huge performance/storage boost. The board has been able achieve a stable uptime of over 60 days, now only intentionally going down for power losses or updates. Reverting back to booting from SD card immediately brings back the random freezing issues and occurs with multiple known good high quality cards from Samsung & Sandisk. I've maintained this no-SD card / USB boot stability through several upgrades since July 2020, current stable set up is Focal 5.9.14-rockchip64. I don't know if there is a relationship between the higher memory speed and SD card access causing the issue as I never tried under-clocking the memory or if this is a separate issue altogether, but for those experiencing stability issues this might fix it for you as well while adding some performance rather than taking it away. Ref: Ayufan SPI flash to enable USB boot - https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md

I am starting Rock64 again after a long layoff. I'm a bit rusty, please forgive any forgetfulness. I tried downloading the Rock64 desktop image, but it was 404. I downloaded Armbian_19.11.6_Rock64_bionic_legacy_4.4.207_desktop.7z Unzipped it, and used etcher to write it to the micro-SD card. Booted up, but didn't get to a graphical desktop. Created a new user OK. I did # apt update, # apt upgrade, # reboot now. Still no graphical desktop. I did # apt install lxde lxdm. (this used to work OK). As expected, the installer asked if i wanted to use lxdm as the display manager. Yes. $ sudo armbian-config Updated the timezone OK. Did Enable Desktop OK, but this didn't get me to lxde. Did Enable autologin. Reboot got me to LXDE. So far so good. But the USB keyboard and mouse don't work. Tried numerous mice and USB sockets. ALT+f1 now doesn't get back to command line so I am stuck. Have I forgotten something?

We can only help you if you are using the official Armbian kernel, from the stable legacy branch. If you choose to use some other kernel, then you are on your own. Please try on a fresh Armbian image, with the official kernel. Make sure you use a buster legacy desktop image, namely this one: https://redirect.armbian.com/rock64/Buster_legacy_desktop.torrent. I am telling you to start over with a new image, because from the logs above I suspect there was a problem with the installation of some desktop packages.

Thank you very much for your swift reply. I immediately got the needed information but somehow armbian forum did not let me post more than once yesterday. Anyway, this is the output: https://drive.google.com/file/d/1MTjonq6bYMsD3ef5iHa7ebHA64Vri6om/view?usp=sharing I have also appended Xorg.0.log to the end of the file. I also tested my own custom compiled kernel for Rock64, and while the experience was a little better, at the end chromium always crashed again with Aw, snap. This is a on 4GB Rock64 SBC. For the fdt I am using rk3328-rock64.dtb.

thank you @balbes150 and sorry new user on this forum I can only post one message per day .. Thank you for confirming the .dtb version to use. There is a version of NextCloudPi for Rock64 which also uses the RK3328, as NextCloudPi is based on an Armbian I was wondering if there was a way to fit that into the image you built for RK3328 .. https://ownyourbits.com/downloads/NextCloudPi_Rock64_11-27-20/ Otherwise do you think that since it works with a Rock64 isn't it also possible to run it on an MX10 which has the same technical characteristics ? Thank again..

Here how to use the media packages from JMCC on Armbian Buster Legacy for the RK3399. This gives Chromium hardware acceleration, and installs Kodi. This also works for the Tinker Board and Rock64.

It is my first RockPi 4 board and first Armbian install - board working OK with official Radxa image (Debian 9) and eMMC drive. Since my plan is to use just CLI I'm trying to install Armbian Buster images. Unforunately both "current" and "legacy" versions are not booting up. I have used SDFormatter (just in case) and Balena (as usual) on 16B Transcend Premim and 32GB SanDisk Ultra (A1) cards - same result: board is powered on but nothing happened at all. Only green diode is lighting but no signs from SD card (red diode is not showing up). eMMC card not connected in both cases. I have checked other topics (i.e. ROCK64) but can not find a good solution how to proceed - your help is much appreciated.

Thanks for the previous posts! I'm having the same issue. I cloned an SD card to set up a second Rock64 board and have duplicate MAC addresses. But I'm now confused as the proper solution. First, removing cloned-mac-address from the network connections file in /etc/NetworkManager/system-connections/'Wired connection 1.nmconnection' does not work for me, either. When I reboot, that line is missing, still, but my MAC address is unchanged. Second, I then see some folks fix this in /etc/network/interfaces with: auto eth0 iface eth0 inet dhcp hwaddress ether b6:09:a4:06:01:2c That works for me, also. But... what's the proper way to automate this. That is, I 'm setting up a master SD card that I'll then want to replicate to put into new boards and I need them all to come up with different MAC addresses just like they would if I booted from a fresh Armbian image on each (Or would they? I've not seen this issue, before, but I've not had multiple boards running in parallel, either). What's the proper way to do that? I don't see where the initial MAC address is being set up, or how/where the MAC address is determined in that case. Thanks!