Search the Community

Yeah, I just like the Arch way of things. I started with Ubuntu like most people, and I do run Debian on one of the machines, but on my laptop I use Arch™ As for Debian being "better" I mean in the sense of "even being doable",. I brought the U-Boot upstreaming topic here because this distro does care to bring U-Boot and the like to more boards than other distros, especially ones that are not ARM-specific. As I mentioned, I didn't even know some defconfig for Renegade had been upstreamed! It was only Rock64 before, haha

Maybe change "verbosity=1" to "verbosity=7" ... Because I've currently my Rock64 working since a week with a build done with 5.8.1 kernel, and of course still using U-Boot 2017.09.

Thanks for the answer! Yes it would be awesome if UMS was enabled! cat: /sys/class/devfreq/dmc/trans_stat: No such file or directory Specifically, there is nothing under the devfreq directory. I'm running Linux 5.8 on ArchLinuxARM. The guys on the archlinuxARM forum are having (at least one of them) the same issue of getting stuck in "Starting kernel..." when using Rock64 and Linux 5.8, so it's not isolated to Renegade Maybe it has something to do with that distro's specific Linux 5.8 version?

The current plan regarding legacy u-boot for rockchip64 is to get rid of it for v20.11: https://armbian.atlassian.net/browse/AR-350 https://armbian.atlassian.net/browse/AR-351 I will add a separate issue for Renegade to not forget it in the process ;p I believe we could try to enable it. Current Rockchip's DDR loaders are also limited to 333MHz but we have DMC enabled in mainline kernels for rk3328 and higher frequencies should be used. What do you see when you run the following command? cat /sys/class/devfreq/dmc/trans_stat EDIT: Rock64 boots fine with 5.8.x and u-boot v2017.09: http://ix.io/2uyG so the issue might be isolated to Renegade...

It seems the Linux kernel 5.8+ on aarch64 is incompatible with the U-Boot from 2017, at least on the RK3328 boards. This apparently affects the Rock64 as well as my own Renegade. Essentially U-Boot gets stuck on "Starting kernel..." In this post https://archlinuxarm.org/forum/viewtopic.php?f=23&t=14657&start=10 they fix it by recompiling u-boot, newer version from upstream In addition to the existing rock64 defconfig, it seems that the defconfig for the Renegade was finally upstreamed on May! https://github.com/u-boot/u-boot/commit/bab972948e152e468fa5ab34764769fc4cddcaab No more 2017 U-Boot from rockchip for me, perharps... I modified https://archlinuxarm.org/packages/aarch64/uboot-rock64/files/PKGBUILD for the renegade and actually got a system that can boot Linux 5.8. (flashed the loader1 and an .itb file) I have 2 (possibly 1) issue: 1) Like the current branch in the armbian build, uboot is missing the ums (USB mass storage) command which is really useful to modify the emmc from a pc. 2) The 2020 uboot i compiled shows DDR4 333 in the first stage, instead of the older DDR4 786Mhz. Does that mean the RAM gets initialized at a lower speed? Maybe, but at least I can boot newer kernels now. Also Maybe the Rock64 and Renegade armbian packages should actually use the upsteam uboot instead of rockchip's 2017 version. I don't know if you already do this in the build tools, but it would be cool!

tobetter's Gnome-wayland is the best build I've ever used out of my 2 SBC's. Rock64 and the N2+. Just got the N2+ last week and it's as good as folks are saying so far. So today I built Armbian Deb bullseye-dev for it and I thought you might like to know how it went. Flashed to sdcard booted first try. Same as the Ubu focal-dev last week. Both run great but the nic on the UBU broke as you know using armbian-config to upgrade it to nightly. The bullseye nic won't download during first upgrade faster than 1-10k p/s. Popped a wireless nic in , finished upgrade and rebooted. Solid blue/red lights no boot. Maybe they are related. Figured you could use the info. When I get free time I like to experiment with cutting edge builds of a few arm distro's. FYI I'm waiting for a patch set for mainline kernel on Manjaro hoping panfrost gets support working soon through mesa. At this time the tobetter libMali drivers seem the way to go until then. I will attempt an Armbian KDE build/install when panfrost/mesa/mainline is more advanced. Cheers, Archetech Update 8-13-20 Thanks to the dev team I can report that my N2+ is now officially OC'ed to 2100 vs 1800 Mhz and idles at 29 C. Lanefu built the latest Boot stuff and I hand edited the boot.ini to match the new dual use- n2 and plus one at github. Sadly we confirmed the nic can't receive well at all. Looking forward to more progess on this SBC.

Thank you MacBreaker, that clears up everything. Yes, I have _looked_at_ the data sheet, but I am even more clueless about electronics than I am about programming, and I would not dare to come near a soldering iron. I will just keep things unchanged and see if I can use the Rock64 for something else. Best regards Freddy

We have nightly images built available for the boards below. Please help us test and report your experience via This Google Form. Images are available via our normal Armbian download page. Just scroll to the bottom to the "nightly build" section. Bananapi Bananapim2plus Bananapim2zero Bananapipro Clearfogbase Clearfogpro Cubietruck Espressobin Helios4 Lepotato Lime-a64 Nanopct4 Nanopiair Nanopim4 Nanopim4v2 Nanopi-r1 Nanopi-r2s Odroidc2 Odroidc4 Odroidn2 Odroidxu4 Orangepi3 Orangepi4 Orangepione Orangepipc Orangepipc2 Orangepipcplus Orangepizero Orangepizeroplus2-h3 Orangepizeroplus2-h5 Pine64 Pinebook-a64 Pineh64 Pineh64-b Rock64 Rockpi-4a Rockpi-4b Rockpi-e Teres-a64 Tinkerboard Tritium-h3 Tritium-h5

Added nightly images for testing: Bananapi Bananapim2plus Bananapim2zero Bananapipro Clearfogbase Clearfogpro Cubietruck Espressobin Helios4 Lepotato Lime-a64 Nanopct4 Nanopiair Nanopim4 Nanopim4v2 Nanopi-r1 Nanopi-r2s Odroidc2 Odroidc4 Odroidn2 Odroidxu4 Orangepi3 Orangepi4 Orangepione Orangepipc Orangepipc2 Orangepipcplus Orangepizero Orangepizeroplus2-h3 Orangepizeroplus2-h5 Pine64 Pinebook-a64 Pineh64 Pineh64-b Rock64 Rockpi-4a Rockpi-4b Rockpi-e Teres-a64 Tinkerboard Tritium-h3 Tritium-h5

Hey, this will not work.. Have you seen the data sheet of the Rock64? There is no I2S on the Pi-2 Bus (pinheader) where you connected the HiFiBerry DAC from your RPi. You can use jumper wire to connect it with P5 but you need a overlay to activate I2S.

Hello Armbian community My HiFiBerry DAC HAT works well on my Raspberry Pi 3B with RasPiOS. However, I would like to put it on my Rock64 to use the higher Ethernet and USB speed it offers. As far as I can tell, HiFiBerry DAC is in the mainline Linux kernel - it is mentioned in the source code, but I do not understand programming, so I cannot see if it is used. Is the HiFiBerry DAC supported in Armbian's kernel? If so, how can I activate and use it? I put the HAT on the Rock64 and installed Armbian_20.05.2_Rock64_buster_current_5.4.43.img.xz , and it booted without problems, but I could not get sound out of the HiFiBerry DAC, and Alsamixer showed no controls for the sound hardware. I also tried making a Virtualbox to compile the Armbian kernel, and I could get the build environment to work, but I did not find any clues to include support for the HiFiBerry DAC - yes, I am truly clueless when it comes to programming, but I can follow a step by step recipe. Please give me a recipe for getting the HiFiBerry DAC to work on Rock64 with Armbian. Best regards Freddy

Is the result of the following command anything different than mine? root@rock64:~# xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Both of my rock64 CPUs have their efuse empty and thus both also have the same mac address which is generated by u-boot and based on CPUID. CPUID should be present in bytes 0x07 - 0x16. I always wondered if it is a common issue... I also have ROCK Pi E and NanoPi R2S - both based on RK3328 - but they have their efuses set. Did you deactivate and activate the connection after editing cloned mac address? My "/etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection" looks like this and it overrides the default mac address

Hi! I've 2 rock64 boards -- 4gb and 2gb bought with 1 year difference The problem -- both boards have same MAC address. Changing it with macchanger has no effect, same for cloned mac in nmtui. Also I tried this in armbianEnv.txt: root@rock64:~# cat /boot/armbianEnv.txt verbosity=1 overlay_prefix=rockchip rootdev=UUID=48ad169b-7620-4c84-89fa-6c9a0fcde766 rootfstype=ext4 ethaddr=a7:71:b0:90:17:1f usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u But mac stays the same. I've plugged usb ethernet just to avoid conflict on same network, but how can I change the MAC of eth0 ?

Hello, I've fairly new to ArmBian and as I'm trying to setup a cluster of Rock64's, I'm wondering if there's any support for using cloud-init (user-data) to be able to setup a board on boot? Thanks!

What? There's no difference between 408 MHz and 600 MHz since the DVFS OPP for both are pretty low. That's RK3328 powered Renegade idling at 408 MHz: root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 12:47:02: 1296MHz 0.19 1% 1% 0% 0% 0% 0% 45.5°C 0/5 12:47:07: 408MHz 0.17 2% 1% 0% 0% 0% 0% 43.6°C 0/5 12:47:12: 408MHz 0.16 1% 0% 0% 0% 0% 0% 45.0°C 0/5 12:47:17: 408MHz 0.15 1% 0% 0% 0% 0% 0% 44.1°C 0/5 12:47:23: 408MHz 0.13 1% 0% 0% 0% 0% 0% 42.7°C 0/5 12:47:28: 408MHz 0.12 1% 0% 0% 0% 0% 0% 44.5°C 0/5 12:47:33: 1296MHz 0.11 1% 1% 0% 0% 0% 0% 46.4°C 0/5^C That's the exact same hardware with exact same load when setting minimum cpufreq to 600 MHz (no idea why @Igor did this change back in November though, the 600 MHz are not the result of the cpufreq governor doing anything but of the project's owner commiting some changes for whatever reason): root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 13:42:02: 1296MHz 0.00 2% 0% 1% 0% 0% 0% 43.6°C 0/5 13:42:07: 600MHz 0.00 0% 0% 0% 0% 0% 0% 44.5°C 0/5 13:42:12: 1296MHz 0.00 2% 1% 0% 0% 0% 0% 44.5°C 0/5 13:42:17: 600MHz 0.00 0% 0% 0% 0% 0% 0% 43.2°C 0/5 13:42:23: 600MHz 0.00 1% 0% 0% 0% 0% 0% 43.6°C 0/5 13:42:28: 600MHz 0.00 1% 0% 0% 0% 0% 0% 43.6°C 0/5 13:42:33: 600MHz 0.00 0% 0% 0% 0% 0% 0% 45.0°C 0/5 13:42:38: 600MHz 0.00 0% 0% 0% 0% 0% 0% 44.1°C 0/5^C And now compare with @devman's results above using R2S without the yellow plastic oven which are still close to 15°C above Renegade/Rock64. So it's obviously not an RK3328 problem users are talking here about! Wrt ondemand governor. This governor has some tunables that need to be set accordingly depending on kernel version. But since nobody in Armbian gives a sh*t about such low level stuff, it's as it is. This most probably would need some attention: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L81-L83 The last time I asked for testers I got zero useful responses:

Hi jock and ning, many thanks for the assistance. I'm not sure about this, I'm using the stock device tree/kernel 5.4 from the Armbian Focal here. Here's my rk3328-rock64.dts from /boot/dtb/rockchip. Do you have any pointers on how I might enable these nodes or examples from other boards? I'm not very experienced here. As I understand it, the rockchip vendor kernel is only 4.4 or is this incorrect? "uname -r" gives me "5.4.45-rockchip64" which I suppose is mainline with some patches from Armbian devs, but maybe I'm mistaken. I could also try the rockchip-dev branch which is 5.6.x if necessary. With regards to performance, I'm only looking to run kodi or maybe some emulation frontends in the future, no desktop - can I expect decent performance with these? I could also try running it via GBM if I get some pointers on how to do that.

Hi, Around the forums, I've seen that some people have been successful in running the lima driver on Amlogic or Allwinner hardware: https://forum.armbian.com/topic/14180-bananapro-lima-driver-problems/ https://forum.armbian.com/topic/11424-playing-with-limamesa-mali-drivers/ However, I couldn't seem to find any posts with Rockchip hardware, specifically the ROCK64. I tried to enable it myself by doing the following, but was unsuccessful so far. enable kernel module lima via "sudo modprobe lima" update /etc/X11/xorg.conf.d/01-armbian-defaults.conf as below per the lima wiki instructions (also tried w/o the "Device" section) Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "ServerFlags" Option "AutoAddGPU" "off" Option "Debug" "dmabuf_capable" EndSection Section "Device" Identifier "Lima" Driver "modesetting" Option "AccelMethod" "glamor" EndSection Section "OutputClass" Identifier "Lima" MatchDriver "rockchip" Driver "modesetting" Option "PrimaryGPU" "true" EndSection Install kodi from the standard repo install updated graphics drivers from Oibaf's PPA start kodi, Armbian desktop (XFCE), or weston (can't confirm if weston was running lima actually) However, no matter what I do, I always get output via llvmpipe as opposed to lima, as also seen in my Xorg.0.log. A couple things I also noticed: other boards also have an armsoc video driver like xserver-xorg-video-armsoc-sun4i, but there isn't one for Rockchip. However, I'm also not sure if this is for the proprietary blobs as opposed to lima. there is a rockchipdrm module loaded in my kernel. I tried to blacklist it and load lima in /etc/modules-load.d, but it seems that it didn't work (rockchipdrm still loaded, lima not) when I booted. I guess it's baked into the kernel? So, can anyone point me in the right direction of where to go from here? My goal is to run kodi via lima so that I can use mainline kernels + mesa with minimum/no patches (vpu might still be tricky).

This is a Renegade featuring the same 'powerful and hot running' RK3328 with large passive heatsink without enclosure: ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to Armbian buster with Linux 5.4.8-rockchip64 System load: 0.24 0.05 0.02 Up time: 41 days Memory usage: 12 % of 1986MB Zram usage: 7 % of 993Mb IP: 192.168.83.251 CPU temp: 46°C Usage of /: 40% of 7.3G storage/: 16% of 7.3T Last login: Sun May 31 12:39:32 2020 from 192.168.83.186 tk@renegade:~$ sudo -s [sudo] password for tk: root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 07:31:13: 1296MHz 0.20 0% 0% 0% 0% 0% 0% 45.9°C 0/6 07:31:18: 408MHz 0.19 0% 0% 0% 0% 0% 0% 42.7°C 0/6 07:31:23: 408MHz 0.17 2% 1% 1% 0% 0% 0% 39.5°C 0/6 07:31:29: 408MHz 0.16 1% 0% 0% 0% 0% 0% 44.1°C 0/6 07:31:34: 408MHz 0.14 1% 0% 0% 0% 0% 0% 42.3°C 0/6 07:31:39: 408MHz 0.13 1% 0% 0% 0% 0% 0% 41.8°C 0/6 07:31:44: 408MHz 0.12 1% 0% 0% 0% 0% 0% 43.2°C 0/6 07:31:49: 1296MHz 0.33 2% 1% 0% 0% 0% 0% 47.3°C 0/6 07:31:55: 408MHz 0.30 1% 0% 0% 0% 0% 0% 41.8°C 0/6^C Rock64 is based on the very same RK3328 SoC, my board has just a laughable tiny heatsink on the SoC and all of the 8 sbc-bench results collected here https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md were done without active cooling. Even with the most demanding cpuminer benchmark the SoC temperature was never reported as above 70°C and running cpuminer at 1.4GHz was possible without any throttling. This is NanoPi R2S using the very same RK3328 doing exactly nothing at all at around or above 70°C: https://tech.scargill.net/nanopi-r2s-openwrt-minirouter/ If idle temperatures of NanoPi R2S without that little yellow plastic oven are above 50°C then there's clearly something wrong (maybe something trivial as a wrong supply voltage resulting in the thermal sensor reporting BS just as we saw on Orange Pi Zero). Utilizing FriendlyELEC's little yellow plastic oven of course will result in insane temperatures.

Actually I'm using Armbian running on Rock64 board. Today I successfully did the kernel upgrade and I hope this will resolve the problem. @Igor, thank you for the info and the detailed instructions how to upgrade the Armbian kernel!

Hi all, Sorry to revive an old forum post but this is directly related to the issue described here. I have a librecomputer rk3328-roc-cc board with 1GB of Ram which was only should about half the RAM. I spent way too much time in u-boot and arm trusted firmware land but I was able to go back to the old Firefly git repo for u-boot and do some source analysis to come up with a patch which will correct the RAM issue in u-boot. I'm a new Armbian user, as I was struggling getting the new 5.4 main line Kernel working on my board when I upgraded from Debian Stretch. Armbian has an amazing build script and process and so far I've really enjoyed using it. The LED lights actually doing things on this board completely sold me. However this half ram issue was the only thing keeping me from upgrading u-boot and going more main line Armbian. I wouldn't call myself a C programmer at all but from my limited understanding it looks like this adds an additional variable for doing math to size the SDRAM for u-boot to initialize. Does anyone here have a contact with ayufan from the git repo (https://github.com/ayufan-rock64/linux-u-boot) so we can get this merged upstream? Also, what else needs to be done to get this board in the supported column? I'm happy to help out and contribute in anyway possible. I run two of these boards at my day job so I can even spend a limited amount of paid time if it allows us to keep them updated and running. ==START userpatches/u-boot/u-boot-rockchip64-dev/sdram_common.patch== --- index 76dbdc8..5233e7f 100644 --- a/arch/arm/mach-rockchip/sdram_common.c +++ b/arch/arm/mach-rockchip/sdram_common.c @@ -14,7 +14,7 @@ DECLARE_GLOBAL_DATA_PTR; size_t rockchip_sdram_size(phys_addr_t reg) { - u32 rank, col, bk, cs0_row, cs1_row, bw, row_3_4; + u32 rank, col, bk, cs0_row, cs1_row, bw, row_3_4, dbw, bg; size_t chipsize_mb = 0; size_t size_mb = 0; u32 ch; @@ -37,16 +37,19 @@ size_t rockchip_sdram_size(phys_addr_t reg) SYS_REG_BW_MASK)); row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) & SYS_REG_ROW_3_4_MASK; + dbw = sys_reg >> SYS_REG_DBW_SHIFT(ch) & SYS_REG_DBW_MASK; + /* only used by DDR4 */ + bg = (dbw == 1) ? 1 : 2; - chipsize_mb = (1 << (cs0_row + col + bk + bw - 20)); + chipsize_mb = (1 << (cs0_row + col + bg + bk + bw - 20)); if (rank > 1) chipsize_mb += chipsize_mb >> (cs0_row - cs1_row); if (row_3_4) chipsize_mb = chipsize_mb * 3 / 4; size_mb += chipsize_mb; - debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n", - rank, col, bk, cs0_row, bw, row_3_4); + debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d dbw %d\n", + rank, col, bk, cs0_row, bw, row_3_4, dbw); } return (size_t)size_mb << 20; ==END userpatches/u-boot/u-boot-rockchip64-dev/sdram_common.patch=== Thanks Gymnodemi

Another piece of feedback: I tried Armbian_20.05.0-trunk.148_Rock64_buster_current_5.4.43.img.xz on Rock64 HW v2.0 (4 GB RAM) After apt update && apt upgrade && reboot I made '7z b' run in a loop. The board hanged after about 15 minutes. I also tried stable version with kernel 5.4.20 with the same result. I suspect that RAM workings under load is unstable. Hope this is helpful.

Thank you for the link ! I checked again all ROCKCHIP configuration differences between linux-rk3399-legacy.config and "ayufan-rock64" rockchip_linux_defconfig: CONFIG_VIDEO_ROCKCHIP_VPU=y CONFIG_VIDEO_ROCKCHIP_ISP1=y CONFIG_SND_SOC_ROCKCHIP_HDMI_ANALOG=y CONFIG_SND_SOC_ROCKCHIP_HDMI_DP=y CONFIG_SND_SOC_ROCKCHIP_MULTICODECS=y CONFIG_SND_SOC_ROCKCHIP_CDNDP=y CONFIG_ROCKCHIP_SUSPEND_MODE=y CONFIG_ROCKCHIP_OTP=m CONFIG_ROCKCHIP_SIP=y CONFIG_ROCKCHIP_SARADC=m I am not sure that all is relevant but I hope it can be helpful... I didn' t checked with rock64-dev and rock64-current but perhaps they also should be verified.

These are the last lines of compilation.log: ...... == kernel == arch/arm64/boot/dts/rockchip/overlay/rockchip-spi-spidev.dts:22.11-27.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0" arch/arm64/boot/dts/rockchip/overlay/rockchip-spi-spidev.dts:36.11-41.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0" arch/arm64/boot/dts/rockchip/overlay/rockchip-spi-spidev.dts:50.11-55.6: Warning (spi_bus_reg): /fragment@3/__overlay__/spidev: SPI bus unit address format error, expected "0" arch/arm64/boot/dts/rockchip/overlay/rockchip-spi-spidev.dts:64.11-69.6: Warning (spi_bus_reg): /fragment@4/__overlay__/spidev: SPI bus unit address format error, expected "0" arch/arm64/boot/dts/rockchip/rk3328.dtsi:344.5-15: Warning (reg_format): /syscon@ff100000/pd_gpu@1:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) arch/arm64/boot/dts/rockchip/rk3328-evb.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-evb.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-evb.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328.dtsi:344.5-15: Warning (reg_format): /syscon@ff100000/pd_gpu@1:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev00.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev00.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev00.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328.dtsi:344.5-15: Warning (reg_format): /syscon@ff100000/pd_gpu@1:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev20.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev20.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-rev20.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328.dtsi:344.5-15: Warning (reg_format): /syscon@ff100000/pd_gpu@1:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) arch/arm64/boot/dts/rockchip/rk3328-rock64.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-rock64.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-rock64.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328.dtsi:344.5-15: Warning (reg_format): /syscon@ff100000/pd_gpu@1:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' fs/aufs/i_op.c: In function ‘au_pin_hdir_set_owner’: fs/aufs/i_op.c:636:45: error: ‘struct rw_semaphore’ has no member named ‘owner’ atomic_long_set(&p->hdir->hi_inode->i_rwsem.owner, (long)task); ^ make[2]: *** [fs/aufs/i_op.o] Error 1 make[1]: *** [fs/aufs] Error 2 make: *** [fs] Error 2 make: *** Waiting for unfinished jobs....

Interesting. This was activated upstream with some other stuff quite a while ago:https://github.com/ayufan-rock64/linux-kernel/pull/42/commits/4b09df95f536a6fecd244dbabd0c59b5aa4048b9

Soooo, Roger That. RIP Rock64 for me.