Search the Community

Hi, I've built the Ubuntu 18.04 image with legacy kernel (4.4) and tried to install wireguard. The problem was the kernel module which seems to be build by dkms. I've installed kernel headers from the linux-headers-rk3328_5.44_arm64.deb (built by armbian's build procedure) and tried to install wireguard-dkms package. It fails: Unpacking wireguard-dkms (0.0.20180513-wg1~bionic) over (0.0.20180513-wg1~bionic) ... Setting up wireguard-dkms (0.0.20180513-wg1~bionic) ... Loading new wireguard-0.0.20180513 DKMS files... Building for 4.4.131-rk3328 Building initial module for 4.4.131-rk3328 Error! Bad return status for module build on kernel: 4.4.131-rk3328 (aarch64) Consult /var/lib/dkms/wireguard/0.0.20180513/build/make.log for more information. The content of make.log DKMS make.log for wireguard-0.0.20180513 for kernel 4.4.131-rk3328 (aarch64) Thu May 17 21:24:11 UTC 2018 make: Entering directory '/usr/src/linux-headers-4.4.131-rk3328' Makefile:643: arch//Makefile: No such file or directory make: *** No rule to make target 'arch//Makefile'. Stop. make: Leaving directory '/usr/src/linux-headers-4.4.131-rk3328' The line 643 is include arch/$(SRCARCH)/Makefile so SRCARCH is not set for some reason. Any suggestions how to fix it? Also I've tired to build wireguard module manually with dkms and/or from source. In both cases it fails because of absent scripts/recordmcount. I've tried to build that stuff with 'make scripts' in the /usr/src/linux-headers-4.4.131-rk3328 and this fails too: HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:10: fatal error: classmap.h: No such file or directory #include "classmap.h" This classmap.h exists in the kernel source tree, but was not included into kernel-headers deb. Do I need to fix something in kernel makefiles?

Finally I was able to boot from SSD's partition. Attached is the patch for boot-rk3328.cmd. Steps: 1. Flash the ayufan's u-boot-flash-spi-rock64.img.xz to SD card, boot the device and wait for SPI bootloader flashed. 2. Flash the Armbian image (build with the patch) to SD card, boot the device with it 3. Login to a device, run nand-sata-install (copy rootfs to the selected SSD partition) , power off the device when finished. 4. Remove the SD card and boot the device. diff.txt

Yes, it's almost Rock64 ... but what are those small diffs, who wants to be in charge? I can build images (when we merge stable and development branches) and leave it this way: https://www.armbian.com/z28-pro/ as an alternative/for a while.

Now that the Rock64 has achieved the "supported" status, there is a free seat in the WIP section. Any chance that this board can make it into WIP soon?

An Asus Tinkerboard (Mali-T764) or a Rock64 (Mali-450MP4)? With a quite good support: http://opensource.rock-chips.com/wiki_Status_Matrix Try to build r6 driver by Free Electrons: https://github.com/mripard/sunxi-mali Kernel module: git clone https://github.com/mripard/sunxi-mali.git cd sunxi-mali export CROSS_COMPILE=$TOOLCHAIN_PREFIX export KDIR=$KERNEL_BUILD_DIR export INSTALL_MOD_PATH=$TARGET_DIR ./build.sh -r r6p2 -b ./build.sh -r r6p2 -i ... and the userspace driver: git clone https://github.com/free-electrons/mali-blobs.git cd mali-blobs cp -a r6p2/fbdev/lib/lib_fb_dev/lib* $TARGET_DIR/usr/lib Pay attention: "In order to build the kernel module, you'll need a functional DRM driver. If you have that already, you'll need the options CONFIG_CMA and CONFIG_DMA_CMA enabled in your kernel configuration."

Hello. Please could someone help me to solve this issue? I have a wifi dongle recognized as: Bus 002 Device 002: ID 148f:5572 Ralink Technology, Corp. RT5572 Wireless Adapter I am trying to use it on my Rock64 and ARMBIAN 5.42 testing Debian GNU/Linux 9 (stretch) 4.4.124-rk3328 uname -a: Linux rock64 4.4.124-rk3328 #24 SMP Wed Mar 28 17:15:52 CEST 2018 aarch64 GNU/Linux It seems it is recognized correctly: Using Network Manager had no luck, the device was always listed as disconnected. So I tried to configure it manually in /etc/network/interfaces, adding this entry: auto wlx441ca87f7a19 iface wlx441ca87f7a19 inet dhcp wpa-ssid mySSID wpa-psk [key removed] Still no luck, this is the log of networking service: I also tried to add: options rt2800usb nohwcrypt=y in /etc/modprobe.d/rt2800usb.conf, as I read somewhere and removed and reloaded the modules, no change Trying the scan manually I get no results: wlx441ca87f7a19 IEEE 802.11abgn ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off sudo iwlist wlx441ca87f7a19 scan wlx441ca87f7a19 No scan results I also connected the module to my laptop (running Ubuntu 17.10) to be sure it works, and from there I can connect to my wifi just fine (using Network Manager). I also can connect to wifi using another usb adapter (Realtek 8188EU USB) on Rock64 with Network Manager. Any idea? Thanks in advance.

Hi, Is it possible to boot from SSD? How it should be partitioned? Can I use any arbitrary partition for rootfs? Should I follow the procedure from this thread ? It assumes I should write the armbian image to a whole drive instead of partition, right? Well, I actually tried some way... First, I've tried to just run some utility from ambian-config that transfers rootfs to a partition. Device did not boot after this (with SD card ejected). Then I've flashed the ayufan's u-boot-flash-spi-rock64.img.xz. This also fails (boot log is attached) but the log looks promising. BTW, I'm experimenting with Ubuntu 18.04 image built by myself from armbian's development branch. Should I use 16.04 instead? Does armbian have its own image/procedure to place uboot into SPI? Just in case here is the drive partitioning (fdisk log from Linux PC): Disk /dev/sde: 232.9 GiB, 250059350016 bytes, 488397168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x22138112 Device Boot Start End Sectors Size Id Type /dev/sde1 2048 119769087 119767040 57.1G 83 Linux /dev/sde2 156354560 488396799 332042240 158.3G 83 Linux /dev/sde3 * 119769088 156354559 36585472 17.5G 83 Linux Partition table entries are not in disk order. And I'm trying to use third partition for rootfs. This partition was actually created after shrinking partition 1 in the freed space. Drive is attached to USB3. minicom.cap

I tried the stable Arabian image for rock 64 and found out that full HD video is played with strong brakes, when playing HEVC image is missing How to force video to be reproduced normally, maybe I don't understand something ?

When searching for rock64 in kernel folder you will find two files: rk3328-rock64.dts and rk3328-rock64-android.dts git clone https://github.com/FireflyTeam/kernel.git git clone https://github.com/FireflyTeam/build.git git clone https://github.com/FireflyTeam/rkbin.git git clone https://github.com/FireflyTeam/u-boot.git Edit: Button on Renegade-cc is not for power, it's a recovery button, used to enter loader mode http://en.t-firefly.com/doc/product/info/id/381.html#Loader20mode0A

Debian Stretch and Nextcloud 13.0.2 Image available for testing at https://ownyourbits.com/downloads Initial testing shows no problems other that some small adjustments that need to be made for all armbian images: static IP and mDNS. More testing is welcome and feedback appreciated! Cheers, Nacho

hi guy's, pay attention when looking for a emmc module for Renegade-cc, the socket is not the same as the one of Rock64 and OdroidXU4. Here two links perhaps you haven't seen yet: https://forum.armbian.com/topic/6850-document-about-compiling-a-kernel-and-rootfs-for-the-firefly-boards/ http://forum.loverpi.com/discussion/62/no-iptables-support-and-vpn-connections-dont-work-and-no-linux-image-installed the_rig April 29 The ubuntu image provided by Libre/Firefly is crap, it misses a lot of kernel modules. I use Armbian now, they more-or-less support the ROK-RK3328-CC. You can try the Armbian build I made, it's prepared for ipsec. https://www.dropbox.com/s/a2pqliuc2oyc7p3/Armbian_5.41_Roc-rk3328-cc_Ubuntu_xenial_default_4.4.120.img?dl=0

Did you use "development" branch, NEXT and you come out with kernel 4.14.40? I just made an image and it sometimes hangs on boot. I tried XU4 and HC1 ... I am still investigating what's wrong. Well, we seek "board data maintainers" and Rock64 is free of duties, also Odroids It's little work but you need to be up2date with the board. Keep the data accurate here: https://www.armbian.com/rock64/, perhaps add some valuable info or links like https://www.armbian.com/pine64/ (but not that much) and keep that up to date. I am your backup in case you can't follow up or mixup something. You can recommend and rearrange recommended images, but they have to exist on the dl.armbian.com first. Stable images are done manually by me, while you can enable/disable beta images at any time and they are remade in next rebuild cycle. Usually in less than 24h. CLI_BETA_TARGET="jessie,xenial,stretch,bionic:next" This would build both Debian and both Ubuntu images with NEXT (4.14.y) kernel. In case you are up for this, I'll make your login credentials to the webpage.

They work just fine according to my testing. Of course, I mainly tested NextCloudPlus... that's why I ask: if you have some criteria for image acceptance I can generate and/or test the image. I can also help with the rock64 image if you guys want, time permitting.

If you use armbian-config, one of the options is 'install kernel headers' -- however this did not match the kernel I had installed in my case (rock64 stretch image) so I ended up adding the beta repo to sources.list and then updating to the latest 4.4.x kernel that also had 4.4.x headers availble. (the newer dev kernel did not work for me)

What configuration file are we talking about? I keep having the same issue with the command ./compile.sh docker \ BOARD=rock64\ BRANCH=default\ KERNEL_ONLY=no\ KERNEL_CONFIGURE=no\ RELEASE=stretch\ BUILD_DESKTOP=no\ EXPERT=yes \ LIB_TAG="development"\ USE_CCACHE=yes\ Probably not detecting the LIB_TAG parameter. If it's easier to wait a little bit I can wait. Thanks!

Hi, It seems that we have a stable version now, congratulations for the hard work! -> https://www.armbian.com/rock64/ Still, I couldn't build it. I pulled the latest master and it still shows in the menu as WIP. When I build it with ./compile.sh docker \ BOARD=rock64\ BRANCH=default\ KERNEL_ONLY=no\ KERNEL_CONFIGURE=no\ RELEASE=stretch\ BUILD_DESKTOP=no\ USE_CCACHE=yes It gets stuck at U-Boot 2017.09-armbian (Apr 12 2018 - 18:09:32 +0000) Model: Pine64 Rock64 DRAM: DDR version 1.06 20170424 In LPDDR3 786MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=2048MB ddrconfig:6 OUT Boot1 Release Time: 2017-05-18, version: 2.43 ChipType = 0x11, 130 emmc reinit emmc reinit SdmmcInit=2 20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=7420MB FwPartOffset=2000 , 0 StorageInit ok = 48550 Raw SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit ret = 0, SecureMode = 0 LoadTrustBL No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa4d10 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 12:22:09, Mar 28 2018 NOTICE: BL31:Rockchip release version: v1.3 INFO: ARM GICv2 driver initialized INFO: Using rkfiq sec cpu_context! INFO: boot cpu mask: 1 INFO: plat_rockchip_pmu_init: pd status 0xe INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2017.09-armbian (Apr 12 2018 - 18:09:32 +0000) Model: Pine64 Rock64 DRAM: If I add EXPERT=yes \ LIB_TAG="development"\ some patches fail [ warn ] * [l][c] 04-patch-4.4.112-113.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.113-114.patch [ failed ] [ warn ] * [l][c] 04-patch-4.4.114-115.patch [ failed ] And the kernel configuration is incomplete Debug PINCTRL calls (DEBUG_PINCTRL) [N/y/?] n AMD GPIO pin control (PINCTRL_AMD) [N/y/?] n One-register-per-pin type device tree based pinctrl driver (PINCTRL_SINGLE) [N/m/y/?] n Anything I am missing? should I wait a little bit longer? Thanks

This one is funny. The Kconfig talks about 'eMMC module socket, MicroSD Card slot, Pi-2 Bus, Pi-P5+ Bus, USB 3.0 and many others peripheral devices interface for makers'. Weird language and there's no 'Pi-P5+ Bus' on this board but ROCK64 is providing another 22 pin header inspired by the old RPi P5 header. The Kconfig text for this Renegade board is simply copy&paste of Rock64 product page typos included Also I asked 5 weeks ago for the necessary blobs but to no avail. Obviously having the device vendor 'on board' here doesn't help that much with Libre Computer hardware The only real difference is DDR4 vs. DDR3 memory but as we already learned DDR4 is not automagically faster, also often higher memory bandwidth is accompanied by higher latency so I wouldn't call DDR4 automatically an advantage (only for media streaming use cases -- using an SBC as TV box). For obvious reasons I do not trust in the memory bandwidth numbers published here any more (also there's only memcpy/memset mentioned but no word about latency). And then there's Micro USB for DC-IN... how should this work with a connected USB3 disk that wants to be powered by the host (many popular external 2.5" USB3 disks do this)?

I just received mine today, having a hard time getting the image downloader (etcher based) to work, keeps failing out. Not that I wasn't going to try to build something anyway... @tkaiser https://github.com/FireflyTeam/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380 https://github.com/FireflyTeam/u-boot/commit/3f87b0c622e246f138d4d32c599fa087b880cade Mainline I haven't looked at/for yet. @JMCC I'm not 100% on the differences, but my understanding is the Rock64 is DDR3 and does not support UHS modes on the microSD. It has also been out a while and has decent support. The Rock64 is friendlier to the wallet and comes with a (small) barrel jack and SPI flash for housing uboot, something I can always support. ;-) Memory and SD throughput would be the major benefits on the Renegade, although I'd have to question why someone that concerned wouldn't just us a USB3 storage medium for the rootfs at that point, on either board, to be honest. I believe the Rock64 can boot a USB media from the SPI flash. (correct me if wrong, anyone, I haven't tried it)

@Igor if I have time tonight this might be the culprit: https://github.com/ayufan-rock64/linux-kernel/commit/75a7a42ab19f026427c8aa0dacc034f9956f1745 [edit] hmmm, ok, so that was already remedied. I guess I'll wait for @Hoerli to report back what the tty is calling itself... [edit2] downloaded today, login via tty1 was no problem.

I got the stable release of armbian for the ROCK64, flashed on a sd-card aaaaaaaand ... wrong password. root + 1234 doesn't work. Has the password been changed? I tried the following combinations: root:1234 ROOT:1234 root:!"§$ (german keyboard, don't know whats on en) armbian:armbian rock64:rock64 All passwords are incorrect. I try it with xenial and strech. (Files of the direct download)

@pfeerick Thank you for your time! On the other hand, I do apologize for wasting it. I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me. I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot. On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e) Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up. This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC. I think this is default behavior on Etcher on Windows/Linux. When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out... When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself. As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished. Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response) Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below. Source. P.S. I noticed the Rock64 Armbian image is still in its testing phase... If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help!

If you subsequently mounted and unmounted the partition, a sync shouldn't have been needed, as you introduced enough time for the buffers to be written to disk, and the unmount shouldn't release the drive until everything has been written to disk. I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible. If you're using a serial console cable with the rock64, it would be a good idea to disconnect it (from the computer), powerup the rock64, and reconnect it, as sometimes the power feeding in from the serial console cable via either the TX or RX pin is enough to leave the rock64 in a non-booting state. Other than that, if Ether is verifying the image, it sounds like the image writing to eMMC is fine, so I don't know what else is going on. If you want to get really bored, you can watch these two screen record caps of me writing the current rock64 Ambian xenial image to the eMMC and then booting it... firstly using Etcher and then secondly using dd. Note with the dd capture I ran into the intermittent issue where the rock64 will not boot properly if there is a serial console cable connected at power on- it gets some residual power via the serial console cable and doesn't reset the CPU properly. Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though.

@pfeerick No, I did not issue a 'sync' after the 'dd' command was executed, but I waited a while before un-mounting the USB to eMMC adapter as I browsed the files that were flashed to it (certainly more than 3 minutes) I also waited after flashing the image with Etcher... I was not aware of this... Nevertheless, once I inserted the eMMC into my Rock64, it would not boot up, the white and red LEDs were constantly on as opposed to when booting Ubuntu Xenial/Artful when the red led was rapidly blinking indicating it found a bootable storage device and once it finished booting only the white LED would remain on... When I flashed images to microSD cards using on a Windows 7 machine, it also ran a "Verifying" step post flashing, this does not happen on Linux in my experience... I agree, but the Armbian image in question is compressed using '7zip' and as such you won't be able to flash it using Etcher unless you uncompress it beforehand. This is why I stated it would have been impossible for me to flash the compressed image to eMMC using Etcher.

When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? pfeerick@ASUS-H55D:~$ sudo dd if=~/Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img of=/dev/sdf status=progress bs=1M 832569344 bytes (833 MB, 794 MiB) copied, 3.00251 s, 277 MB/s 1052+0 records in 1052+0 records out 1103101952 bytes (1.1 GB, 1.0 GiB) copied, 3.97628 s, 277 MB/s pfeerick@ASUS-H55D:~$ time sync real 0m11.902s user 0m0.000s sys 0m0.028s As can be seen above, I needed to wait 12 seconds after dd had finished before I could safely remove the microSD card. (Edit: Just to remove any confusion, I loaded Armbian on a microSD this time to show the timing and that a sync is needed with dd. I previously loaded and booted a 16GB FORESEE eMMC using the pine64 eMMC to USB adapter.) Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition. pfeerick@ASUS-H55D:~$ sudo fdisk -l /dev/sdf Disk /dev/sdf: 15 GiB, 16118710272 bytes, 31481856 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x91a1b523 Device Boot Start End Sectors Size Id Type /dev/sdf1 32768 2154495 2121728 1G 83 Linux pfeerick@ASUS-H55D:~$ fdisk -l Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img Disk Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img: 1 GiB, 1103101952 bytes, 2154496 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x91a1b523 Device Boot Start End Sectors Size Id Type Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img1 32768 2154495 2121728 1G 83 Linux Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options? Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility.

Firsly, thanks for your interest in my issue! @Igor I am afraid that's not possible, as I did not save the logs... In any case, no error was reported. @pfeerick I tried to flash the latest image of Armbian for Rock64, the very same one you pointed out. Here are the steps I undertook: 1) Downloaded the latest Rock64 Armbian build. 2) unzipped the image 3) a. Attempted to flash the image using 'dd if=/path/to/armbian_rock64.img of=/dev/sdb bs=1M' The image was flashed on the eMMC card, but only the 1.1GB root partition, no '/boot' partition was created. It looked as if the image was simply copied as opposed to flashed... b. Formatted the eMMC card, this time I used Etcher (the Pine64 version from Github), and had the same result. To test if I was actually doing something wrong, I used Etcher to flash ayufan's Ubuntu Xenial to eMMC, it worked and it created the /boot partition along with the root partition as expected, tried again with ayufan's Ubuntu Artful image, worked as well... 4) Etcher did not verify my image as I am running Fedora27 Workstation... I unzipped the downloaded archive, albeit I used Fedora's native zip tool, not '7zip'...but the image was uncompressed with no error reported. Also, the Etcher GUI will only list images (probabily by looking for the '.img' extension on the end of files) so unless you uncompress the downloaded file you won't be able to see it in Etcher, let alone flash it... I will try to flash with Etcher once more from a Windows7 machine on Monday, although I am sceptical to say the least... If all else fails I will use the "nand-sata-install" script to flash the image to eMMC and create an image out of that to share with others...