Search the Community

I am trying to build an Image for the Rockpro but i am allways getting an Error when it comes to compile U-boot (did not make any Changes so far): Displaying message: Preparing host info Displaying message: Build host OS release bionic info Displaying message: Syncing clock host info ## BUILD SCRIPT ENVIRONMENT Repository: https://github.com/armbian/build Version: 46340a24 Host OS: bionic Host arch: amd64 Host system: Linux ek-desktop 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Virtualization type: none ## Build script directories Build directory is located on: TARGET SOURCE FSTYPE AVAIL /home /dev/sda1 ext4 319,9G Build directory permissions: # file: /home/ek/build # owner: ek # group: ek user::rwx group::rwx other::r-x Temp directory permissions: # file: /home/ek/build/.tmp # owner: root # group: root user::rwx group::rwx other::r-x ## BUILD CONFIGURATION Build target: Board: rockpro64 Branch: default Desktop: yes Kernel configuration: Repository: https://github.com/ayufan-rock64/linux-kernel Branch: tag:4.4.138-1094-rockchip-ayufan Config file: linux-rockchip64-default U-boot configuration: Repository: https://github.com/ayufan-rock64/linux-u-boot Branch: branch:rockchip-master Config file: rockpro64-rk3399_defconfig Partitioning configuration: Root partition type: ext4 Boot partition type: (none) User provided boot partition size: 0 Offset: 16 CPU configuration: 600000 - 1900000 with ondemand Displaying message: Downloading sources info Displaying message: Checking git sources u-boot-rockchip64 rockchip-master info Displaying message: Checking out Displaying message: Checking git sources linux-rockchip64 4.4.138-1094-rockchip-ayufan info Displaying message: Up to date Displaying message: Checking git sources arm-trusted-firmware-rockchip64 rockchip info Displaying message: Up to date Displaying message: Checking git sources sunxi-tools master info Displaying message: Up to date Displaying message: Checking git sources rkbin-tools master info Displaying message: Up to date Displaying message: Checking git sources marvell-tools A3700_utils-armada-17.10 info Displaying message: Up to date Displaying message: Checking git sources odroidc2-blobs master info Displaying message: Up to date Displaying message: Checking git sources testing-reports master info Displaying message: Up to date Displaying message: Cleaning output/debs for rockpro64 default info Displaying message: Cleaning arm-trusted-firmware-rockchip64/rockchip info Displaying message: Compiling ATF info Displaying message: Compiler version aarch64-linux-gnu-gcc 6.4.1 info Displaying message: Started patching process for atf rockchip64-rockpro64-default info Displaying message: Looking for user patches in userpatches/atf/atf-rockchip64 info Displaying message: * [\e[32ml\e[0m][\e[35mb\e[0m] add-trust-ini.patch info Displaying message: Cleaning u-boot-rockchip64/rockchip-master info Displaying message: Compiling u-boot 2017.09 info Displaying message: Compiler version aarch64-linux-gnu-gcc 7.2.1 info Displaying message: Checking out sources Displaying message: Cleaning u-boot-rockchip64/rockchip-master info Displaying message: Started patching process for u-boot rockchip64-rockpro64-default info Displaying message: Looking for user patches in userpatches/u-boot/u-boot-rockchip64-default info Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add_fdtfile_dt_overlays.patch info Displaying message: ERROR in function compile_uboot compilation.sh:185 err Displaying message: U-boot file not found idbloader.bin err Displaying message: Process terminated info Trying to build an Image for the PineH64 does not work either: Displaying message: Preparing host info Displaying message: Build host OS release bionic info Displaying message: Syncing clock host info Displaying message: ERROR in function source main.sh:188 err Displaying message: No kernel branch selected err Displaying message: Process terminated info

Maybe... I have found out on this thread that the RTC is not located inside the CPU but in a RK805 This RTC has neither a battery nor a crystal, so it cannot be used while the board is off, as I read on this page: So I would need an external RTC if I wanted to use rtcwake with off or suspend-to-disk options. Still, in suspend-to-ram, the LEDs turned on again, so apparently, the RTC works in suspend-to-ram mode. In the log it says Sep 2 12:32:25 nextcloudplus kernel: [ 1.431242] rk808-rtc rk808-rtc: rtc core: registered rk808-rtc as rtc0 Sep 2 12:32:25 nextcloudplus kernel: [ 1.432090] rk3x-i2c ff160000.i2c: Initialized RK3xxx I2C bus at ffffff8009bf8000 so the on-board RTC is at least registered somewhere. I don't know whether 'nextcloudplus kernel' is the linux kernel in disguise, but apparently, it handles the RTC. Maybe I will have to see what happens if I have a monitor connected to my rock64.

Show command output on PC "fdisk -l" to SD card with the image xenial-minimal-rock64-0.5.15-136-arm64.img Have you tried to move the boot loader from SD card xenial-minimal-rock64-0.5.15-136-arm64 to SD card with Armbian 5.59 ?

As a comparison now the same task (building ARM's Compute Library on a SBC) on a device where swapping does not occur. The purpose of this test was to check for efficiency of different swapping implementations on a device running low on memory (NanoPi Fire3 with 8 Cortex-A53 cores @ 1.4GHz but just 1 GB DRAM). Results back then when running on all 8 CPU cores (full details): zram lzo 46m57.427s zram lz4 47m18.022s SSD via USB2 144m40.780s SanDisk Ultra A1 16 GB 247m56.744s HDD via USB2 570m14.406s I used my RockPro64 with 4 GB DRAM and pinned execution of the compilation to the 4 Cortex-A53 cores running also at 1.4 GHz like the Fire3: time taskset -c 0-3 scons Werror=1 -j8 debug=0 neon=1 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a build=native This is a quick htop check (pinned to an A72 core) confirming that only the 4 A53 cores are busy: On NanoPi Fire3 when being limited to 4 CPU cores and with just 1 GB DRAM we got the following execution times (slightly faster with lzo in contrast to 'common knowledge' telling us lz4 would always be the better choice): Sun May 20 16:05:17 UTC 2018 100 4 lzo [lz4] deflate lz4hc real 86m55.073s Mon May 21 11:41:36 UTC 2018 100 4 [lzo] lz4 deflate lz4hc real 85m24.440s Now on RockPro64 without any swapping happened we get 73m27.934s. So given the test has been executed appropriately we're talking about a performance impact of below 20% when swapping to a compressed block device with a quad-core A53 @ 1.4 GHz (5125 seconds with lzo zram on NanoPi Fire3 vs. 4408 seconds without any swapping at all on RockPro64 --> 16% performance decrease). I looked at the free output and the maximum I observed was 2.6GB RAM used: root@rockpro64:/home/rock64# free total used free shared buff/cache available Mem: 3969104 2666692 730212 8468 572200 1264080 Swap: 0 0 0 'Used' DRAM over the whole benchmark execution was almost always well above 1 GB and often in the 2 GB region.

As I said, suspend to ram seems to be working, the on-board LEDs switch on after the appropriate time, I'm just unable to connect to it. I know that Rock64 has an RTC module, so the reason cannot be the lack of a RTC.

Hello I recently set up NextCloudPlus/NextCloudPi on a Rock64. I used the image that can be downloaded from the ownyourbits website, cat /etc/*-release resulted in the following output: BOARD=rock64 BOARD_NAME="ROCK64" BOARDFAMILY=rk3328 VERSION=5.44 LINUXFAMILY=rk3328 BRANCH=default ARCH=arm64 IMAGE_TYPE=user-built BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image 03af3b07-6131-4b1c-8cc2-7f716caf75e1 # PLEASE DO NOT EDIT THIS FILE BOARD=rock64 BOARD_NAME="ROCK64" BOARDFAMILY=rk3328 VERSION=5.44 LINUXFAMILY=rk3328 BRANCH=default ARCH=arm64 IMAGE_TYPE=user-built BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" Now, I wanted to use rtcwake to automatically shut down or suspend my server during night. I tested the states off, suspend-to-disk and suspend-to-ram. The first two did not work at all (-m disk was not recognized and when completly switching off, it did not wake). Probably they are not supported by the device. Suspend-to-Ram (-m mem) did work, however, after my Rock64 woke, I was unable to communicate with it. Both the NextCloudPi web interface and ssh are unreachable, then until i manually restart the device using the power connection. This is a link to a section out of my system log that I think is important (I think it is when rtcwake was launched, the command was sudo rtcwake -m mem -s 300, if I remember the time correctly). I already posted this question in the NextCloud forum and they told me that I may have better chances here. Does anybody know how to solve this issue? Thanks in advance for any help.

I've been doing some tests with NanoPi M4 these days. While I'm not a professional board reviewer, here I can share some early performance numbers to you. Beware that none of these tests fit into real world use cases, they are just provided as-is. Besides, Armbian development on RK3399 boards are still at a very early stage, so any of these numbers may change in the future, due to software changes. Unless mentioned, all tests are done using Armbian nightly image, FriendlyARM 4.4 kernel, CPU clocked at 2.0/1.5GHz Powering NanoPi M4 is my first board powered by USB-C, while RK3399 is not power-hungry under normal load, I do doubt if 5V/3A power supply is sufficient when the CPU load goes higher, or when a lot of USB devices are connected. So I went a series of power measurement, with this tool That is to measure the power consumption on the USB side, excluding the consumption of PSU. The board is powered by the USB-C charger that came with my Huawei MateBook E, which supports 5V/2A, 9V/2A, and 12V/2A, so theoretically it is insufficient to power the NanoPi M4 board. Unfortunately I can't find a USB-C charger capable of 5V/3A output, and I have to do such test with it. What if I connected a lot of USB 3.0 device and exceeded the 5V/2A limit? Well, I did try that (connect 4 USB HDD and run cpuburn, or even connect 2 SBCs to the USB), and the answer is simple: the board crashed. But normally the board's consumption will not exceed 10W, so the charger works just fine. Test setup 1) Idle consumption This is the typical consumption when you use it as an headless server. 2) Idle consumption with HDMI display output (console tty interface, no Desktop/X11/GPU stuff) Testing with Dell P2415Q 4k 60Hz display. HDMI connected, with 2560*1440 60Hz video output. Also connect the USB 3.0 hub to 3) Display connected, 802.11ac WiFi with iperf sending With HDMI display connected (same as (2)), and WiFi connected to 802.11ac 5GHz AP in another room, run the following command: iperf3 -c 10.24.0.1 -t 60 The WiFi throughput is around 110Mbps 4) Display connected, running cpuburn With HDMI display connected (same as (2)), run cpuburn on all 6 cores 5) Idle consumption of 4.19-rc1 mainline kernel Same as (1), but running mainline kernel. Test results The idle consumption is 1.79W, and it might need some tuning to reduce the consumption. When WiFi and display are connected, it goes higher to 2.87W. With an active WiFi networking, the board consumes 4.67W, and with all CPU cores active, it consumes 9.86W. Mainline kernel has a higher idle consumption, the reason might be DDR dvfs and/or devfreq are not implemented yet. Based on these results, it seems that 5V/2A power is okay if no peripheral devices are connected. However if you connect any USB devices, it may easily exceed the 2A limit when CPU load goes higher. CPU/RAM and IO Performance While RK3399 is not a super fast chip, its performance fits into its position. To reveal the full potential of the board, I'm posting some visualized sbc-bench results taken from mainline 4.19-rc1 kernel here. This is because there might be some DRAM performance issues on RK3399 with 4.4 kernel.. For comparison, I'm also posting the results of Firefly-RK3399 (2.2/1.8GHz overclock, tested by myself), Raspberry Pi 3 B+, ROCK64 and RockPro64 (taken from existing sbc-bench results) You can see the full sbc-bench log here. Memory 7-zip cpuminer For IO performance, I use iozone to measure the performance of SD card, eMMC and USB SSD. NanoPC T4's NVMe SSD results are added as a reference. SSD performance are measured by command "iozone -e -I -a -s 1G -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2", SD card and eMMC are using 100M instead of 1G size. Networking NanoPi M4 comes with a 1Gbps ethernet port and a 802.11ac 2x2 MIMO WiFi module, and I tested both with iperf3. GbE iperf3 full duplex test: hjc@nanopim4:~$ iperf3 -c 10.20.0.1 & iperf3 -Rc 10.20.0.1 -p 5202 [1] 27486 Connecting to host 10.20.0.1, port 5201 Connecting to host 10.20.0.1, port 5202 Reverse mode, remote host 10.20.0.1 is sending [ 4] local 10.20.0.2 port 43782 connected to 10.20.0.1 port 5201 [ 4] local 10.20.0.2 port 45102 connected to 10.20.0.1 port 5202 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 64.6 MBytes 542 Mbits/sec [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 95.1 MBytes 798 Mbits/sec 0 314 KBytes [ 4] 1.00-2.00 sec 110 MBytes 919 Mbits/sec [ 4] 1.00-2.00 sec 94.5 MBytes 793 Mbits/sec 0 320 KBytes [ 4] 2.00-3.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 95.8 MBytes 803 Mbits/sec 0 317 KBytes [ 4] 3.00-4.00 sec 110 MBytes 920 Mbits/sec [ 4] 3.00-4.00 sec 94.5 MBytes 792 Mbits/sec 0 317 KBytes [ 4] 4.00-5.00 sec 110 MBytes 920 Mbits/sec [ 4] 4.00-5.00 sec 94.6 MBytes 794 Mbits/sec 0 314 KBytes [ 4] 5.00-6.00 sec 110 MBytes 919 Mbits/sec [ 4] 5.00-6.00 sec 95.7 MBytes 803 Mbits/sec 0 314 KBytes [ 4] 6.00-7.00 sec 110 MBytes 919 Mbits/sec [ 4] 6.00-7.00 sec 95.5 MBytes 801 Mbits/sec 0 317 KBytes [ 4] 7.00-8.00 sec 110 MBytes 920 Mbits/sec [ 4] 7.00-8.00 sec 94.8 MBytes 795 Mbits/sec 0 314 KBytes [ 4] 8.00-9.00 sec 110 MBytes 920 Mbits/sec [ 4] 8.00-9.00 sec 94.5 MBytes 792 Mbits/sec 0 314 KBytes [ 4] 9.00-10.00 sec 97.2 MBytes 816 Mbits/sec 0 320 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 952 MBytes 799 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 949 MBytes 796 Mbits/sec receiver [ 4] 9.00-10.00 sec 110 MBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr iperf Done. [ 4] 0.00-10.00 sec 1.03 GBytes 884 Mbits/sec 9 sender [ 4] 0.00-10.00 sec 1.03 GBytes 882 Mbits/sec receiver iperf Done. [1] + 27486 done iperf3 -c 10.20.0.1 Wireless hjc@nanopim4:~$ iperf3 -c 10.24.0.1 Connecting to host 10.24.0.1, port 5201 [ 4] local 10.23.4.116 port 39730 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 13.0 MBytes 109 Mbits/sec 13 1.21 MBytes [ 4] 1.00-2.01 sec 12.9 MBytes 107 Mbits/sec 5 618 KBytes [ 4] 2.01-3.00 sec 12.6 MBytes 106 Mbits/sec 0 618 KBytes [ 4] 3.00-4.00 sec 9.35 MBytes 78.7 Mbits/sec 4 329 KBytes [ 4] 4.00-5.00 sec 11.1 MBytes 92.9 Mbits/sec 0 348 KBytes [ 4] 5.00-6.00 sec 10.2 MBytes 85.5 Mbits/sec 0 363 KBytes [ 4] 6.00-7.00 sec 9.37 MBytes 78.6 Mbits/sec 0 387 KBytes [ 4] 7.00-8.00 sec 10.9 MBytes 91.5 Mbits/sec 0 409 KBytes [ 4] 8.00-9.00 sec 13.6 MBytes 114 Mbits/sec 0 409 KBytes [ 4] 9.00-10.00 sec 13.8 MBytes 116 Mbits/sec 0 410 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 117 MBytes 98.0 Mbits/sec 22 sender [ 4] 0.00-10.00 sec 116 MBytes 97.0 Mbits/sec receiver iperf Done. hjc@nanopim4:~$ iperf3 -c 10.24.0.1 -R Connecting to host 10.24.0.1, port 5201 Reverse mode, remote host 10.24.0.1 is sending [ 4] local 10.23.4.116 port 39734 connected to 10.24.0.1 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 10.6 MBytes 88.8 Mbits/sec [ 4] 1.00-2.00 sec 10.9 MBytes 91.5 Mbits/sec [ 4] 2.00-3.00 sec 4.41 MBytes 37.0 Mbits/sec [ 4] 3.00-4.00 sec 2.07 MBytes 17.3 Mbits/sec [ 4] 4.00-5.00 sec 1018 KBytes 8.34 Mbits/sec [ 4] 5.00-6.00 sec 1.29 MBytes 10.8 Mbits/sec [ 4] 6.00-7.00 sec 6.48 MBytes 54.4 Mbits/sec [ 4] 7.00-8.00 sec 10.8 MBytes 91.0 Mbits/sec [ 4] 8.00-9.00 sec 10.7 MBytes 89.9 Mbits/sec [ 4] 9.00-10.00 sec 10.7 MBytes 89.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 70.1 MBytes 58.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 69.1 MBytes 58.0 Mbits/sec receiver iperf Done. It's too complicated to analyze the performance of a WiFi connection, but so far I've never seen more than 200Mbps throughput on AP6356S.

Hello guys, hope I'm in the right subforum. If not, please postpone. I have a question about the device tree and pinctrl... I have added a chip to my I2C-0, the configuration looks like this: &i2c0 { clock-frequency = <400000>; status = "okay"; os8104: os8104@41 { compatible = "smsc,os8104"; reg = <0x41>; master = <0>; /* slave mode*/ bypass = <0>; /* /ABY (all bypass mode) im register bXCR */ pinctrl-names = "default"; pinctrl-0 = <&os8104_reset &os8104_int &os8104_aint &os8104_error &os8104_3dB>; }; }; Then, under pinctrl I have added this block: &pinctrl { ir { ir_int: ir-int { rockchip,pins = <2 2 RK_FUNC_GPIO &pcfg_pull_none>; }; }; ... os8104 { os8104_reset: os8104-reset { rockchip,pins = <RK_GPIO2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_up>; }; os8104_int: os8104-int { rockchip,pins = <RK_GPIO3 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>; }; os8104_aint: os8104-aint { rockchip,pins = <RK_GPIO3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>; }; os8104_error: os8104-error { rockchip,pins = <RK_GPIO3 RK_PA6 RK_FUNC_GPIO &pcfg_pull_down>; }; os8104_3dB: os8104-3dB { rockchip,pins = <RK_GPIO3 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>; }; }; }; But, how can I access these pins from the LKM? I'm using of_find_node_by_name to find the device node. Board is Rock64 and kernel is 4.4.143 Many thanks.

the boot with bionic-minimal-rock64-0.7.9-1067-arm64.img.xz ( it stop at the end )

I spent some time with this board yesterday. Here are my initial impressions: PROs: - Using 32GB eMMC from Pine64 the system is very usable (quick). I have not tested with a NVMe SSD yet. - As @tkaiser has mentioned, the tall heatsink is easily up the task of keeping the RK3399 SOC cool. Questions/Remarks/CONs: - The power on behavior seems intermittent. Specific example: Flash image to eMMC using Etcher, install eMMC, connect power... nothing... press Power, Reset,... nothing. Remove power, re-apply power... board boots. Have others experienced this? - Upgrading to the latest Kernels using the method described above by @tkaiser causes the board to have no HDMI output on reboot (I did not have UART connected). I tried two kernel builds from yesterday. Had to refresh eMMC, very time consuming. - So, is there a stable kernel 4.14, 4.17, or 4.18 you guys would recommend? - I can not get a USB wifi card to come up. This is a v1 TL-WN722N which is supported by ath9k. Shows up in "lsusb", I load the ath9k module, reboot, ath9k is not reloaded. I add ath9k to /etc/modules, reboot and it loads on boot. Still nothing in iwconfig. I tried adding "wifi.scan-rand-mac-address=no" to NetworkManager.conf, no help. dmesg does not show firmware being requested, and the information is a little odd. It shows as "USB NIC" and serial number "12345". Same behavior on USB 3.0 and 2.0 ports. (This USB NIC has been plug and play on all sorts of things including Android for years.) I feel like I am missing something obvious. Any ideas? - How should the "RECOVERY" button be used? There is not information at "http://wiki.pine64.org/index.php/ROCKPro64_Main_Page#Datasheets_for_Components_and_Peripherals" The item is labeled as "28" in a picture, but not in the table below the picture. Would this make it possible to flash the eMMC like on the ROCK64? I do not like pulling it off the board over and over. Thanks!

I'm trying to switch the upper USB port to peripheral mode so I can use the ethernet gadget on it. Has anyone done anything like that before? I've got an issue here https://github.com/ayufan-rock64/linux-build/issues/117 with some of the things I've tried already.

boot xenial-minimal-rock64-0.5.15-136-arm64.img => printenv arch=arm baudrate=1500000 board=rock64_rk3328 board_name=rock64_rk3328 boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf boot_mode=unknown boot_net_usb_start=usb start boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_targets=mmc0 mmc1 usb0 pxe dhcp bootargs=earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M ethaddr=da:d1:f5:a1:86:84 eth1addr=da:d1:f5:a1:86:a4 serial=2f1213b77b38289 bootcmd=run distro_bootcmd bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=setenv devnum 0; run mmc_boot bootcmd_mmc1=setenv devnum 1; run mmc_boot bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi bootcmd_usb0=setenv devnum 0; run usb_boot bootdelay=2 bootfile=/extlinux/extlinux.conf bootfstype=fat cpu=armv8 cpuid#=55524b5030393030350000000015051e devnum=0 devplist=6 devtype=mmc distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done efi_dtb_prefixes=/ /dtb/ /dtb/current/ eth1addr=da:d1:f5:a1:86:a4 ethact=ethernet@ff540000 ethaddr=da:d1:f5:a1:86:84 fdt_addr_r=0x01f00000 fdtcontroladdr=7df1db70 fdtfile=rockchip/rk3328-rock64.dtb fileaddr=1f00000 filesize=0 kernel_addr_r=0x02000000 load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=reserved1,size=64K,uuid=${uuid_gpt_reserved1};name=reserved2,size=4M,uuid=${uuid_gpt_reserved2};name=loader2,size=4MB,uuid=${uuid_gpt_loader2};name=atf,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=B921B045-1DF0-41C3-AF44-4C6F280D3FAE; pxefile_addr_r=0x00600000 ramdisk_addr_r=0x04000000 scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi; scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done scriptaddr=0x00500000 serial#=2f1213b77b38289 soc=rockchip stderr=serial@ff130000 stdin=serial@ff130000 stdout=serial@ff130000 usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi vendor=rockchip Environment size: 4497/8188 bytes => bdinfo arch_number = 0x00000000 boot_params = 0x00000000 DRAM bank = 0x00000000 -> start = 0x00200000 -> size = 0x7FE00000 baudrate = 1500000 bps TLB addr = 0x7FFF0000 relocaddr = 0x7FF27000 reloc off = 0x7FD27000 irq_sp = 0x7DF1DB60 sp start = 0x7DF1DB60 Early malloc usage: 470 / 800 fdt_blob = 000000007df1db70

Hi, everyone. I'm looking for board which can be used for playing video in kiosk mode, therefore it must have video hardware acceleration available. I've looked through supported devices and created short-list: A20-based: Olimex Lime 2 and its modifications BananaPi/BananaPi Pro Cubietruck H3-based: OrangePi PC/Plus/+2E and other similar modifications (have one, is overheating common problem for them?) Rockchip-based: MiQi Tinkerboard S A64-based (with original/legacy kernel): Pine64/Rock64/Sopine A64 OrangePi Win/Plus + Hummingboards Am I right that these boards are able to play video with hardware acceleration and what board will be more suitable for this purpose?

boot sd : xenial-minimal-rock64-0.5.15-136-arm64.img ! DDR version 1.10 20171106 In DDR3 333MHz Bus Width=32 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=2048MB ddrconfig:2 OUT Boot1 Release Time: 2017-06-12, version: 2.44 ChipType = 0x11, 171 SdmmcInit=2 0 BootCapSize=2000 UserCapSize=7456MB FwPartOffset=2000 , 2000 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 212180 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=0x92d74 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 09:28:45, May 31 2017 NOTICE: BL31:Rockchip release version: v1.3 INFO: ARM GICv2 driver initialized INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 1 INFO: plat_rockchip_pmu_init: pd status 0xe INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2017.09-g5aef9f7 (Oct 12 2017 - 09:11:39 +0000), Build: jenkins-linux-build-rock-64-136 Model: Pine64 Rock64 DRAM: 2 GiB MMC: rksdmmc@ff500000: 1, rksdmmc@ff520000: 0 *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block invalid extent block switch to partitions #0, OK mmc1 is current device Scanning mmc 1:6... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf reading /extlinux/extlinux.conf 259 bytes read in 3 ms (84 KiB/s) 1: kernel-4.4 Retrieving file: /initrd.img reading /initrd.img 3504483 bytes read in 157 ms (21.3 MiB/s) Retrieving file: /Image reading /Image 18606088 bytes read in 814 ms (21.8 MiB/s) append: earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M ethaddr=da:d1:f5:a1:86:84 eth1addr=da:d1:f5:a1:86:a4 serial=2f1213b77b38289 Retrieving file: /dtb reading /dtb 42707 bytes read in 5 ms (8.1 MiB/s) ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 7dbc2000, end 7df19963 ... OK Loading Device Tree to 000000007dbb4000, end 000000007dbc16d2 ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0

on emm is stock android,if i don't have sd it boot . I find a file dtb in the boot sd on xenial-minimal-rock64-0.5.15-136-arm64.img.xz, i rename it in dtb.img and put in the sd of "Armbian_5.59_Rk3328-tv_Ubuntu_bionic_default_4.4.152_desktop_20180831.img.xz" without success I open the box and come back

i try all dtb rk3328 one by one for the moment : i boot on sd on : xenial-minimal-rock64-0.5.15-136-arm64.img.xz in read the changelog i see after : "0.6.0: Use SPL/TPL instead of Rockchip's loaders (supports flashing and booting from SPI)," delete partition 6 and 7 , reboot with usb stick(bionic-minimal-rock64-0.7.9-1067-arm64.img.xz), activate eth1 ( all explain in the post off segv ) If you want I can try to open the box to find rs232 connection to see bootlog.

Picture courtesy of TL Lim. Check #Rock64 channel from yesterday here: http://irc.pine64.uk/

The rock64 and rockpro64 can have 4gb ram. Arm mainboards which have 4gb ram I would expect to be able to display youtube videos.

That is not a problem. How about this way: RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle RK3399 (RockPRO) and RK3328 (Rock64) -> rockchip64 (ayufan source) RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future

Is it possible to share a board family between Rock64 and RockPro64? If they could use exactly the same kernel source and u-boot source from ayufan... Use armbian-config and switch to nightly build, and you'll get the latest kernel.

This gives an aes-256-cbc score of 274785 at 8k. And this is 368675. Those OpenSSL numbers are great since they do not depend on anything else other than existence of ARMv8 Crypto Extensions so we can draw conclusions from benchmark result to Cortex-A53 clockspeed. Comparison chart: https://forum.armbian.com/topic/4583-rock64/?do=findComment&amp;comment=37829 An Allwinner H5 clocked at 816 MHz scored 380482 back then so the 368675 we get is a clear indication of slightly below 800MHz. Same with the 274785 number --> slightly below 600 MHz. So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality). Interestingly in the above result collection there are EspressoBin numbers that indicate that some time ago we were running at close to 1000 MHz (462012). Numbers were generated exactly one year ago with no kernel cpufreq support back then: https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&amp;comment=37981

I've been considering some options for experiments with electronic wind instruments and synthesizers, such as ZynAddSubFx, Fluidsynth. I've seen project Zynthian and they are running it on a Raspberry Pi 3, so that should be a safe choice, right? Although I'm not sure if they are using some mainstream Debian or something heavily adjusted. Also, for a wind instrument I hoped to find something smaller so I can even build it into the instrument itself; although I don't have my hopes high on that - I'm not sure if I'll find an SBC with enough power. I happen to be one of lucky (or not) backers of NextThingCo C.H.I.P. (now mostly out-of-business company) and I have two CHIPs. So, I just tried one with ZynAddSubFx. Well, it jitters like hell, even with 20ms latency, while some RPi3 user claimed to have achieved around 5ms latency with the same setup (compiled from source, using ALSA and not jack). So, clearly CHIP with its R8 (essentially AllWinner A13) is not enough for playing ZynAddSubFx in real time. It seems, for most of Linux audio synths single core performance matters most because I'm not sure if they are optimized to leverage ARM benefits (at least not yet, but maybe they will in the future). Also, 32/64 bits might be not important at all. BUT - in some benchmarks I've seen that Cortex-A53 running at the same clockspeed as A7 shows almost ~30% better performance even for 32 bit programs? So, it might be worth choosing H5 over H3 in any case? Memory usage - not so important; I don't want to load entire soundbank of samples into RAM. So, 512MB might suffice, although 1GB seems more future-proof. Not sure yet. And, of course, I don't care about video decoding (unless it's possible for some software synth to use video chip as an additional CPU, but it seems highly unlikely) and network performance Looking through these forums, I found one person claimed to be using ZynAddSubFx on a Orange Pi (presumably H3?) and being satisfied with the results. Does this mean that 4 x Cortex-A7 CPU-cores of H3 work better than 1 x Cortex-A8 CPU-core of R8? Yes, there are 4 cores, but is the OS distributing the load evenly across all of them thus making sound synthesis more efficient? Does leveraging of multiple cores depend more on the OS (Armbian specifically) or on ZynAddSubFx ? Again not sure. I only know that for now I should stay away from H6 because it's not yet completely supported and I'm not sure if it would give any benefits for my case, unless it could provide more horsepower for the synths even at this early stages of Linux support? I don't need super high audio quality, but seeing that those smaller boards don't have audio out, it seems I'll need an I2S output and an addon board anyway (and Orange Pi sells even sets of SBC + I2S board, so that might be a nice option). Unfortunately, analog IO pins are a rarity and I'll have to add an Arduino anyway to deal with all the sensors (touch buttons and breath sensor), but then having reliable SPI or I2C is mandatory for me! This might exclude many options. Which boards have reliable SPI or I2C support in Armbian? So, CPU wise, my choices (besides obvious RPi3B+) seem to be H2+/H3 (seems to be the same thing) or H5 (if there is any reason to go for 64 bit in my specific case) or RK3328. And finally the price. The cheapest Rpi 3 B+ I can get is 45 USD (with shipping). In comparison, ROCK64 with 1GB RAM is 36 USD (with shipping). But they are too large to consider building into an EWI, so I would have to run wires (which I might have to do anyway, if my idea to build everything into the EWI itself fails for some reason). Only Orange Pi offers small form factor in their Zero models (H2+, H3, H5 based). What do you think? Is it worth trying to find a small factor SBC for ZynAddSubFx among those Orange Pis or should I go for ROCK64?

Yep. What happens if you call 'sudo depmod'? If it succeeds then another time 'sudo modprobe cifs' would be interesting. On Rock64 the cifs module should be built as module and therefore modprobe should work. Unfortunately our settings are not consistent accross kernels: macbookpro-tk:kernel tk$ egrep "CONFIG_CIFS |CONFIG_CIFS=" * | grep -v 'CONFIG_CIFS=m' linux-mvebu-dev.config:CONFIG_CIFS=y linux-mvebu-next.config:CONFIG_CIFS=y linux-mvebu64-dev.config:# CONFIG_CIFS is not set linux-mvebu64-next.config:# CONFIG_CIFS is not set linux-odroidc1-next.config:# CONFIG_CIFS is not set linux-qcomlt-default.config:# CONFIG_CIFS is not set linux-rockchip-dev.config:CONFIG_CIFS=y linux-rockchip-next.config:CONFIG_CIFS=y linux-s5p6818-default.config:# CONFIG_CIFS is not set linux-sun4i-default.config:CONFIG_CIFS=y linux-sun5i-default.config:CONFIG_CIFS=y linux-sun7i-default.config:CONFIG_CIFS=y linux-sun8i-default.config:CONFIG_CIFS=y linux-udoo-default.config:# CONFIG_CIFS is not set

I'm not sure whether this is the correct place. Sorry if it isn't and please move it to where it belongs - thanks! The problem is: in our community (forum.iobroker.net) came up problems with mounting to a nas by cifs. ioBroker is a smart home management, and a new module ("adapter") has been designed to provide automated backups to a nas. in most cases this works fine, but on some platforms with armbian it fails with the message: cifs filesystem not supported by the system I'm not that linux crack, but i tried to find out what could cause this, I found at this site https://www.linuxquestions.org/question ... 175593855/ some help. In all versions the message mentioned above occured /proc/filesystems didn't contain cifs in the versions the backup worked, cifs was included. At the moment we have confirmed it at orangePi plus2e (ARMBIAN 5.38 stable Ubuntu 16.04.5 LTS 4.14.4-sunxi) and I could reproduce it on a Rock64 (nightly Ubuntu 16.04.5 LTS 4.4.131-rk3328) ( I know it's nighly!!) The platforms will have different age of images, and the users will not have updated/upgraded It seems that the problem occurs only at Ubuntu based images (cifs-utils already installed and at newest version), not at Debian based. on A Tinkerboard Ubuntu image (Ubuntu 16.04.5 LTS 4.4.120-rockchip) all is ok, so it is not at all ubuntu images. calling: sudo modprobe cifs on my rock64 installation, the response was modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.131-rk3328/modules.dep.bin' modprobe: FATAL: Module cifs not found in directory /lib/modules/4.4.131-rk3328 Is this a common issue and known? And the more imortant question: What can be done? thanks for every help in advance Rainer

Usually you do not want an USB hub between host and disk, especially if disk accesses happen in parallel. Since all RPi just have one single USB2 port there's always one (internal) hub involved if you're not using an RPi Zero. The RPi Trading 'geniuses' when mixing ingredients for their latest update of the platform chose a combined Ethernet/hub thingy (LAN7515) that does not only suck when it's about networking but also contains not just one but two internal hubs in a cascaded fashion. So with your external hub you might already have 3 cascaded hubs between host port and disks. Terrible. Also RPi 3 and 3+ are one of the few 64-bit capable SBC that do not implement ARMv8 Crypto Extensions and therefore suck horribly when it's about AES performance: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md While I personally consider mdraid-1 just a weird waste of disks obviously you want to access your both disks concurrently and fast. As already mentioned: combining any cheap USB3 equipped SBC like Rock64 with the JMS561 thing will work fine with HDDs or you could use an EspressoBin with one disk connected to the SATA and the other to the USB3 port. Or using an PCIe attached SATA controller on those PCIe capable boards. Just a matter of money you want to spend on the setup. Since all HDD suck horribly at random IO I personally would also consider USB3 combined with good UAS capable SATA bridges since... fast enough. But USB3 when you have to use the USB3-A connector can be a real sh*t show since connection issues are quite common with this crappy connector. There was a RK3399 board announced a while ago called Rock960 Pro with an JMS561 on the PCB providing 2 SATA ports suitable for HDDs but no idea what has happened (@hipboi asked me whether I want a developer sample some time ago but we did not succeed for whatever reasons)