Search the Community

What about doing just this - back to "latest stable" according to Ayufan? --- a/config/sources/rockchip64.conf +++ b/config/sources/rockchip64.conf @@ -42,7 +42,7 @@ fi case $BRANCH in default) KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' - KERNELBRANCH='tag:4.4.138-1094-rockchip-ayufan' + KERNELBRANCH='tag:4.4.132-1072-rockchip-ayufan' KERNELDIR='linux-rockchip64' KERNEL_USE_GCC='> 7.0' ;;

wrote the image on two different cards, waited approx. more than 5 Minutes for each and let the Rock64 run for the last try (more than 30 Minutes) how do i add this line, files are write protected, also cannot extract the iso

Try this one: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.154.7z

I am running the exact same image and its working fine. My Rock64 is also 4Gb version ... The only suspicious things are those two patches which might be absent in OMV since we add them recently: https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-default/enable-1392mhz-opp.patch https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-default/enable-1512mhz-opp.patch I can provide you test image if you like to try?

Yes I assumed its based on the Debian armbian image, but this makes it also very odd since its booting up on the same hardware setup. I used the current images from https://dl.armbian.com/rock64/ Armbian_5.59_Rock64_Debian_stretch_default_4.4.152_desktop Armbian_5.59_Rock64_Ubuntu_bionic_default_4.4.152 OMV Image stretch-openmediavault-rock64-0.7.8-1061-arm64.img Used the same HDMI, LAN and Power supply cable, yes

Which is made on top of Armbian. Almost all images are tested and networking is always checked. My report confirms that it is working: https://github.com/armbian/testings/blob/master/rock64-default.report Are you always use the same cables? Which is a version of your images? Which kernel is used in OMV, which on Armbian ...

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.

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.

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 ?

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.

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.

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?

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!

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

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.

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?

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

The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already. While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs. For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work ) I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed: /dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there). Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at https://github.com/Fourdee/DietPi/issues/1550 but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/resize_rootfs.sh which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements: I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too: Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour': DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself: https://www.linuxatemyram.com), the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively). Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram). So far I don't see that much advantages (none to be honest) but most probably I missed something? Anyway: let's continue focussing on storage utilization and 'use': DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller? Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs). And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards! Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600). So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!) It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!) So where's some room for improvement when comparing our defaults with DietPi's? Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?

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