It seems that the HDMI output does not have any option beyond 1080P. Tried multiple monitors. The font size at uboot stage seems right but the resolution maxed out at 1080P after kernel starts.

Tried Armbian 24.2.1 with 6.6.16. Could be related with this: https://forum.manjaro.org/t/rk3399-hdmi-output-for-resolutions-different-than-1080p/90644. but patches should be applied at Kernel 6.4: https://www.phoronix.com/news/Linux-6.4-imx25-Rockchip-4K

Attached is the screenshot when connected with DELL 25inch monitor. Should have 2K option.

diagnoses: https://paste.armbian.com/gaketoluye

Thank you

rockpro64 board can't boot up if usb hdd is attached, if I pull out the usb it boot up correctly (Armbianmonitor log attached).

With previous firmware (6.6.36) works correctly.

Please help.

Hi,

I read everything I could possibly find on the DP-Alt mode for the RockPro64 and came to the conclusion that no Distro is offering that right now.

However, the Pinebook Pro seems to have support via a Kernel Patch. Can the Pinebook Pro Kernel be installed on the RockPro64?

Is there a repository for Armbian Kernels?

Thanks very much.

Hello,

After several days of debug I put the finger on a very strange issue using integrated Ethernet.

I use my Rockpro64 mostly as a Samba and DNS server.

In my network context I implement 2 vlans as vlan interfaces (eth0.10 and eth0.20).

Each of these interfaces needs to use a specific mac address that differs from physical eth0 mac address (it is an important point).

If I use only the physical mac my router is not be able to route correctly between vlans (probably an ivl/svl issue).

Under this context I first noticed that when I bring down eth0.20 although using vlan 10 (so eth0.10) connectivity is lost.

I then write a script to gather all needed information (ie. ip link/addr/route/rule/neigh, ping, arping, netstat, ...) ==> no peculiar problem

I then add a background tcpdump and, guess what, the connectivity loss didn't occur anymore !

After thinking a bit, I made the assumption that the main difference is the use of promiscuous mode during tcpdump.

==> and "bingo" : setting 'promisc' flag on eth0 acts as a workaround.

Also if I do not set a specific mac for vlan and use physical mac leads to no connectivity issue, despite the wrong routing.

The key point seems that bringing down a vlan interface unregisters all macaddress from listening process instead only the needed, so the connectivity problem.

I don't know if it's a hardware limitation, a driver bug or Armbian issue, but I am open to any fix or at least, any debug hint that helps to narrow down the root cause.

Regards.

Hi

I installed a nvme SSD to my rockpro64 (with a generic PCIe adapter card). Somehow it only uses a x1 link instead of x4. I also observed the same behaviour with a x2 SATA card (only x1 link established).

Output of lspci:

LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)

To rule out hardware issues, I also tried the same setup with Manjaro-ARM which correctly negotiates a x4 link.

LnkSta: Speed 2.5GT/s (downgraded), Width x4

dmesg for Armbian

[    2.221206] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[    2.221296] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[    2.221334] rockchip-pcie f8000000.pcie:       IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[    2.222953] rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator
[    2.223187] rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator
[    2.286376] rockchip-pcie f8000000.pcie: wait 1000 ms (from device tree) before bus scan
[    3.298661] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
[    3.309542] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    3.310052] pcieport 0000:00:00.0: PME: Signaling with IRQ 58
[    3.310984] pcieport 0000:00:00.0: AER: enabled with IRQ 58

virtually identical for Manjaro-ARM

[    1.114557] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[    1.114626] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[    1.114655] rockchip-pcie f8000000.pcie:       IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[    1.115937] rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator
[    1.116100] rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator
[    1.176874] rockchip-pcie f8000000.pcie: wait 1000 ms (from device tree) before bus scan
[    2.234398] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
[    2.274272] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    2.274780] pcieport 0000:00:00.0: PME: Signaling with IRQ 58
[    2.275722] pcieport 0000:00:00.0: AER: enabled with IRQ 58

I also compared the device trees for Armbian and Manjaro. There are no differences as well.

Has anyone a hint for me what I could try to get the x4 link established?

I have a problem with this version: Armbian_20.05.2_Rockpro64_buster_legacy_4.4.213.img

I don't see my disk that is plugged on the PCIe To SATA Marvell 88SE9230 in the system.

I've create the file /etc/udev/rules.d/99-marvell.rules with the following line on it:

ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1b4b", ATTR{device}=="0x9230", RUN+="/bin/bash -c 'echo %k > /sys/bus/pci/drivers/ahci/bind'"

If I do the same thing with this version: Armbian_20.05.4_Rockpro64_focal_current_5.4.46.img, I see my disk after creating the file.

But, there's two problem with this version: first the fan always running and, more important, second I can't install OpenMediaVault on it.

My question is, do I have to do something on the kernel? If so, could someone tell me what I have to activate to see my disk ?

I don't have a lot of knowledge about kernels but I'm ready to jump it if someone could tell me where to check.

Thank you all in advance.

I have a RockPro64 that I have been using for many years as a server. It is currently running Armbian bookworm 12.5. Most of the storage is on an M.2 SSD attached to the PCI socket and is subdivided into disk volumes using linux LVM2.

Today I accepted the Armbian kernel upgrade from 6.1.50 to 6.6.16

During the reboot it failed to mount any of my LVM volumes because the device nodes where not present.

I found this article about how to recover the situation: https://unix.stackexchange.com/questions/11125/lvm-devices-under-dev-mapper-missing

While in rescue mode I ran the suggested command

vgchange -a y <name of volume group>

This re-created the lvm devices under /dev/mapper so I was able to mount the volumes, but the newly created devices where not persisted so I got the same problem again when I attempted to reboot.

I have been able to get my system booting by adding "nofail" to each /etc/fstab line and then after boot running the vgchange command to create the devices so that the system can boot, but clearly this is not a wise long term solution. It looks like something has been missed out of the early boot commands or the intrid, but I don't know enough to fully debug the problem.

Any ideas?

I have been using a RockPro64 as a miniserver for many years. It runs stable most of the time. I have assigned it a host name "ab2" via armbian-config. It usually responds well to this alias. Only from time to time it happens that it no longer responds to the hostname. Only a reboot helps. Do you have any idea what this could be?

PS Thanks for your great work!

Sem

I have a custom PCIe x4 lane card that I'm trying to integrate with a RockPro64 SBC. This custom card has been tested with many users on different platforms including a linux x86 system. When I try this card in a RK3399 system, I get a strange result when I view the assigned address space with the lspci command. It appears the address assigned is the exact value of the BAR address size for each BAR. If I change the BAR size the assigned address changes to that value. Below is a dmesg dump along with a lspci output for my device. Device is  [ad00:001e]. Any guidance?

dmesg:

[    2.395091] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[    2.395148] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[    2.395175] rockchip-pcie f8000000.pcie:       IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[    2.396226] rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator
[    2.396376] rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator
[    2.571466] rockchip-pcie f8000000.pcie: wait 1000 ms (from device tree) before bus scan
[    3.582289] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
[    3.582303] pci_bus 0000:00: root bus resource [bus 00-1f]
[    3.582316] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff]
[    3.582330] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff])
[    3.582387] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400
[    3.582547] pci 0000:00:00.0: supports D1
[    3.582557] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[    3.588072] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    3.588301] pci 0000:01:00.0: [ad00:001e] type 00 class 0x000000
[    3.588382] pci 0000:01:00.0: reg 0x10: [mem 0xfffffe00-0xffffffff]
[    3.588455] pci 0000:01:00.0: reg 0x18: [mem 0xffe00000-0xffffffff]
[    3.588606] pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)
[    3.588632] pci 0000:01:00.0: Max Payload Size set to 128 (was 128, max 128)
[    3.589238] pci_bus 0000:01: busn_res: [bus 01-1f] end is updated to 01
[    3.589272] pci 0000:00:00.0: BAR 14: assigned [mem 0xfa000000-0xfa2fffff]
[    3.589287] pci 0000:00:00.0: PCI bridge to [bus 01]
[    3.589302] pci 0000:00:00.0:   bridge window [mem 0xfa000000-0xfa2fffff]
[    3.589497] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    3.589853] pcieport 0000:00:00.0: PME: Signaling with IRQ 37
[    3.590302] pcieport 0000:00:00.0: AER: enabled with IRQ 37

lspci -v:

00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 37
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: fa000000-fa2fffff [size=3M] [32-bit]
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport

01:00.0 Non-VGA unclassified device: Alta Data Technologies LLC Device 001e
Subsystem: Alta Data Technologies LLC Device 001e
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at fffffe00 (32-bit, non-prefetchable) [disabled] [size=512]
Region 2: Memory at ffe00000 (32-bit, non-prefetchable) [disabled] [size=2M]
Capabilities: <access denied>

I tried to connect an external USB 3.2 gen 2x2 4TB SSD drive to the only USB-C port available on the Rockpro64, but it's not recognized.

I don't know if I need to install some packages for it to work?

Any help would be very appreciated!

I am on Ubuntu Jammy based Armbian: 6.1.63-current-rockchip64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

It works well with the same cable on a Macbook Pro.

Kind regards,

Baptiste

dmesg
[    4.879030] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[    4.880111] [drm] Initialized panfrost 1.2.0 20180908 for ff9a0000.gpu on minor 1
[    5.779194] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[    5.779596] usb usb1-port1: attempt power cycle
[    6.755189] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[    7.655190] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[    7.655590] usb usb1-port1: unable to enumerate USB device

sudo lsusb -t
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

looking to upgrade from SBC Rock64 to RockPro64<

however, on the homepage it is mentioned, 

that

https://wiki.pine64.org/wiki/ROCKPro64_Software_Releases

Quote

If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not.

Since my Rock64 is running aready Linux kernel 4.4 and i am looking to upgrade, both from Rock64 and from SDcard to eMMC,

my question, if this limitation still applies to RockPro64 with newer editions of Armbian, also since there is no mention of it on the official Armbian Page for RockPro64

https://www.armbian.com/rockpro64/

Thank you very much 

I have recently accepted the 23.11.1 armbain kernel release on my RockPro 64

The update has not rebuilt or updated the uIntrd for the 6.1.63 kernel. Note that the /boot/uInitrd symlink still points to the old uInitrd version but the other two symlinks have updated.

root@jupiter:~# ls -l /boot/dtb /boot/Image /boot/uInitrd
lrwxrwxrwx 1 root root 29 Dec  2 20:38 /boot/dtb -> dtb-6.1.63-current-rockchip64
lrwxrwxrwx 1 root root 33 Dec  2 20:38 /boot/Image -> vmlinuz-6.1.63-current-rockchip64
lrwxrwxrwx 1 root root 33 Nov 30 18:04 /boot/uInitrd -> uInitrd-6.1.50-current-rockchip64
root@jupiter:~# ls -l /boot/uInitrd*
lrwxrwxrwx 1 root root       33 Nov 30 18:04 /boot/uInitrd -> uInitrd-6.1.50-current-rockchip64
-rw-r--r-- 1 root root 17777215 Jul 22 21:07 /boot/uInitrd-5.15.93-rockchip64
-rw-r--r-- 1 root root 17560966 Nov 30 12:06 /boot/uInitrd-6.1.50-current-rockchip64

The first time after the update I did not notice before rebooting, and the box failed to boot properly. I got to a rescue console and was able to restore the three 6.1.50 kernel files from a backup, and restore the symlinks.

I tried running:

apt reinstall armbian-config armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-rockpro64-current base-files

But this did not fix the problem. Google is not helping me find the command to create the 6.1.63 uInitrd file by hand.

I have also tried installing the 6.1.64 kernel from beta.armbian.com but that had the same issue.

Currently my device is running 6.1.50-current-rockchip64 but the 6.1.64-current-rockchip64 kernel is installed and I suspect that there are inconsistencies in how things are setup. For example wireguard is not working correctly.

How can I restore my device back to a stable working state?

I was getting 2 blinks of white LED, then a pause, then repeating.  I thought it wasn't booting or something.

After checking a whole bunch of things, including connecting a serial terminal, I finally realized I had a bad Ethernet cable (and this was why it was not showing up on my router).  The board (and OS installed to eMMC) had been fine the whole time.

Now, my understanding is that the LED behavior is particular to software (bootloader, I guess?).  But FWIW, on a slightly older Armbian (21.02.3) at least, this appears to be default behavior.

I just wanted to make a note for search purposes, in case anyone else runs across the same issue.

I currently have a monitor plugged in running dmesg -W hoping for something when these hard locks are occurring but I am not seeing anything to indicate what the issue may be.

armbianmonitor-u output is:

https://pastebin.com/DeU8VsB4

Any suggestions on any additional debugging I can enable to try tracking this down?

I have compiled with Armbian build (btw i reported that RockPro64 and Rock64 download pages give 502 Bad gateway)
1. Armbian_23.08.0-trunk_Rockpro64_jammy_current_6.1.46_minimal.img

2. Armbian_23.08.0-trunk_Rockpro64_jammy_current_6.1.46_cinnamon_desktop.img

With SPI disabled, the img boots fine, but when reboot/restart takes place, board gives black screen, no U-boot activity, no white light.
It will boot again after restart if reset pressed or power off/on

Shouldnt board reboot normally?

PS
nd after u-boot log/text this screen shows prior booting

In the past it was proposed by @Igor to use the u-boot-sunxi/remove-boot-messages-from-hdmi.patch
this now as I can see under the allwinner-optional and seems do nothing on RockPro64 u-boot compile to hide the text

@jock provided in the Tinker forum a userpatch disable-vidconsole.patch which works great on it (tinker)

diff --git a/include/configs/tinker_rk3288.h b/include/configs/tinker_rk3288.h
index bde7d72e6d..3ae9bb05f7 100644
--- a/include/configs/tinker_rk3288.h
+++ b/include/configs/tinker_rk3288.h
@@ -7,9 +7,9 @@
 #define __CONFIG_H
 
 #define ROCKCHIP_DEVICE_SETTINGS \
-        "stdin=serial,usbkbd\0" \
-        "stdout=serial,vidconsole\0" \
-        "stderr=serial,vidconsole\0"
+        "stdin=serial\0" \
+        "stdout=serial\0" \
+        "stderr=serial\0"
 
 #include <configs/rk3288_common.h>

On an Linux 5.15.93-rockchip64 aarch64 GNU/Linux - Ubuntu 20.04.6 LTS image the u-boot does not boot the sd, but on a spi u-boot installed, it boots ok

I would like to have working hidden u-boot installed on the sd (bridge spi to disabled with pin 23-25) rather boot first the spi. (feels longer boot)
I try to compile with, tried diff patches but no luck

./compile.sh build BOARD=rockpro64 BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes BUILD_ONLY=u-boot KERNEL_CONFIGURE=no RELEASE=jammy

Any feedback or existing solution is much appreciated.
To recap:
- Tips or pointers on which patch to be used to hide uboot boot process on RockPro64
- Below is probably to uboot related so Ill test other compiles

PS
I have compiled a non patched/[non applied sunxi hide msgs patch] "linux-u-boot-rockpro64-current_23.08.0-trunk_arm64__2023.01-S62e2-Pee75-He8c0-V2d4f-B9963-R448a.deb" and applied from armbian-config to sd card.
It boots ok with disabled SPI from Power Off
But if OS reboots it stays to black screen (no white light).

If reset pressed or power off and start from buttons, it boots again fine with UBOOT visible (submarine logo and text)
NOTE: @ayufan Ayufan latest uboot on spi works excellent and hidden boot

Hello,

Armbian 22.02 images doesn't boot on rockpro64. I have tried:

Armbian 22.02 Bullseye

Armbian 22.02 Jammy XFCE

It doesn't boot (not blinking white led).

Previous builds works correctly:

Armbian_21.08.1_Rockpro64_bullseye_current_5.10.60

The issue I describe below begins with a simple 1GB/s speed test with iperf3 (using tcp, then udp). With tcp everything is almost ok. With udp it's an other story.
I first try through Internet and notice that there is connection drops. The network topology is : test computer => internet => router => switch (Mikrotik crs-326) => Rockpro64

The iperf3 server is on Rockpro64, and the client is on test computer.

I then try to narrow down :

- I connect directly to the switch and try again : in and out switch ports show near max speed (~1 Gbps), however the iperf3 server logs show 2 or 3 transfers at reduced speed, then show no transfer/throughput after
Topology : test computer => switch => Rockpro64 (ethernet)

- I then connect an usb-c network adapter on Rockpro64 : all is working correctly at around 350MBits throughput (seems to be maximum speed with usb)
Topology : test computer => Rockpro64 (usb adapter)

It looks like the Rockpro64 has problems with processing udp packets at high-rate with its embedded ethernet controller.

I try to enable ethernet flow control on switch, and check it's enabled on Rockpro64 : no change (pause frames are not even sent).
I increase tx/rx ring buffers to the maximum (1024) : nothing changes as well.
I try to increase kernel net.core.rmem_* buffers to 25M : no changes

Is there known issues about this ?
Is there an alternate/improved driver for the nic ?
Have you some advices about extra debug steps ?

Regards.

E:\utils\iperf3\iperf-3.1.3-win64>iperf3 -V -c 192.168.0.64 -u -b 0 --get-server-output
iperf 3.1.3
CYGWIN_NT-10.0 ARNAUD-PC 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Sat, 19 Aug 2023 09:16:46 GMT
Connecting to host 192.168.0.64, port 5201
      Cookie: ARNAUD-PC.1692436606.019644.1e8c9a9b
[  4] local 192.168.0.13 port 64985 connected to 192.168.0.64 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   115 MBytes   962 Mbits/sec  14690
[  4]   1.00-2.00   sec   114 MBytes   958 Mbits/sec  14630
[  4]   2.00-3.00   sec   114 MBytes   953 Mbits/sec  14530
[  4]   3.00-4.00   sec   109 MBytes   918 Mbits/sec  14010
[  4]   4.00-5.00   sec   114 MBytes   956 Mbits/sec  14590
[  4]   5.00-6.00   sec   114 MBytes   958 Mbits/sec  14620
[  4]   6.00-7.00   sec   114 MBytes   958 Mbits/sec  14620
[  4]   7.00-8.00   sec   114 MBytes   958 Mbits/sec  14630
[  4]   8.00-9.00   sec   114 MBytes   958 Mbits/sec  14620
[  4]   9.00-10.00  sec   114 MBytes   958 Mbits/sec  14620
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.11 GBytes   954 Mbits/sec  0.074 ms  521/20469 (2.5%)
[  4] Sent 20469 datagrams
CPU Utilization: local/sender 0.8% (0.0%u/0.8%s), remote/receiver 2.9% (0.2%u/2.7%s)

Server output:
Time: Sat, 19 Aug 2023 09:16:46 GMT
Accepted connection from 192.168.0.13, port 44317
      Cookie: ARNAUD-PC.1692436606.019644.1e8c9a9b
[  5] local 192.168.0.64 port 5201 connected to 192.168.0.13 port 64985
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   106 MBytes   891 Mbits/sec  0.082 ms  347/13937 (2.5%)
[  5]   1.00-2.00   sec  49.7 MBytes   416 Mbits/sec  0.074 ms  174/6532 (2.7%)
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
[  5]  10.00-10.26  sec  0.00 Bytes  0.00 bits/sec  0.074 ms  0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5] (sender statistics not available)
[  5]   0.00-10.26  sec   156 MBytes   127 Mbits/sec  0.074 ms  521/20469 (2.5%)  receiver


iperf Done

.

Thanks as always. 

The pastebin is here:
https://paste.armbian.com/zikixujaho


Here is the syslog:

Apr 28 10:17:45 rockpro64 systemd-resolved[795]: Clock change detected. Flushing caches.
Apr 28 10:17:45 rockpro64 chronyd[1120]: System clock was stepped by 3624.542409 seconds
Apr 28 10:17:45 rockpro64 chronyd[1120]: System clock TAI offset set to 37 seconds
Apr 28 10:17:46 rockpro64 vnstatd[1094]: Info: Latest database update is no longer in the future (db: 2023-04-28 10:05:00 <= now: 2023-04-28 10:17:46), continuing.
Apr 28 10:17:48 rockpro64 systemd[1]: Starting system activity accounting tool...
Apr 28 10:17:48 rockpro64 systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Apr 28 10:17:48 rockpro64 systemd[1]: sysstat-collect.service: Deactivated successfully.

hardware log:

Time    CPU_cl0/CPU_cl1  load %cpu %sys %usr %nice %io %irq  Tcpu  C.St.
09:17:07  1416/1800 MHz  1.83  38%  21%  11%  0%  4%  0%  43.3 °C  0/5
09:17:08  1416/1800 MHz  1.83  39%  6%  28%  0%  4%  0%  42.8 °C  0/5
09:17:08  600/1800 MHz  1.83  39%  4%  31%  1%  1%  0%  43.3 °C  0/5
09:17:08  600/1800 MHz  1.83  40%  5%  31%  1%  2%  0%  42.8 °C  0/5
09:17:09  1416/1800 MHz  1.83  42%  9%  25%  0%  6%  0%  43.9 °C  0/5



Apr 28 10:17:48 rockpro64 systemd[1]: Finished system activity accounting tool.
Apr 28 10:18:01 rockpro64 systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Apr 28 10:18:51 rockpro64 chronyd[1120]: Selected source 108.61.73.244 (0.ubuntu.pool.ntp.org)

I would be very grateful if you will help me.

Thank you.

I'm trying to get Armbian jammy latest to boot on my new RockPro64.

I've tried both the CLI and XFCE images, flashed with Balena to a good SanDisk uSD card.

Both boot into U-Boot but then fail to find a partition on mmc 1.

Checking the SD card there's only 1 Linux partition and no FAT one.

I tested with a Debian image on the same SD card (DOS + Linux Partition) and it booted into the installer no problem.

Any ideas?

Thanks!

(Also asked on Pine 64 Forums, I will update/close this if they resolve it or vice/versa.)

Does this kernel know about the DSI port?   Do I have to build a custom kernel?  If not then what boot env line will get it going?

I've a rockpro64 with the SSD adapter and a WD black 250GB nvme.

The system doesn't recognizes this drive.

I've tested the latest stable ayufan image (kernel 4.4) and it recognises it perfectly.

Should I downgrade the kernel to the 4.4 branch?

Any help would be appreciated.

Thanks,

Yesterday morning, after apt upgrade my Rockpro64 not boot (the white and red led stayed lit).

After some tries I managed to get a boot again but I now have a "init not found" error, as you can see on the screenshot.

What have been done so far :

- Install an Ubuntu as "debug" platform

- Follow the recovery steps from Armbian website

- Put on eMMC storage a 5.15.63 by copying the files from Armbian

- Check if UUID was consistent between partition, boot config, ... ==> this is the case

- Made a fsck : no errors found

==> I would like to try this : https://askubuntu.com/questions/910218/sbin-init-no-such-file-or-directory-not-able-to-boot-ubuntu-desktop, but need to have a boot prompt (how to get it ?)

If somebody has any other hint... I would take it

I have spent hours on the setup of my Rockpro64, I would avoid to reinstall it.

Regards.

Hi all,

I am a newbie here.
Is there a way to install ZFS on RockPro64 RK3399 with the latest Armbian release (doesn't matter if it is bionic, buster or focal)?

I have experienced a lot of system instability with the rockpro64 on debian and armbian as explained here:

https://forum.pine64.org/showthread.php?tid=17083

and here:

https://github.com/monero-project/monero/issues/8473

I think the solution lies in what the guys are discussing here:

https://forum.pine64.org/showthread.php?tid=7387

Can someone please give me a clear set of instructions on how to create an image to boot with with lowered ddr clock frequency?

Presumably from the files listed here?:

https://github.com/rockchip-linux/rkbin/tree/master/bin/rk33

i.e.: files such as

rk3399pro_ddr_666MHz_v1.27.bin

rk3399pro_miniloader_v1.26.bin

Thanks!

Iv searched around and found a few unmaintained projects but Its not something iv ever done before so wanted to ask what others use.

Although I do have some experience in the terminal I'm still relatively new to it so im hoping there is something with good step by step documentation.

If anyone can assist Id be appreciative. Many thanks.

Hi everyone. I’ve been facing some issues with my RockPro64 lately, running on a dedicated version of Ambian for this sbc.
Earlier, I was using a USB Bluetooth module with it for playing audio on my speakers (via Logitech Bluetooth adapter), and it worked perfectly fine. I wanted to save some USB ports so I decided to replace the module with a ROCKPro64 1*1 Dual Band WIFI 802.11 AC/BLUETOOTH 5.0 MODULE. But ever since I’ve done that, the audio quality is choppy and inconsistent. Receiver and transmitter are located closely, so I don’t think it’s a signal issue. It seems like a hardware or a software issue, but I’m not sure what could it be. I’d appreciate any help with troubleshooting or diagnostics. Thanks in anticipation!

Has anyone tried compiling zfs? According to google it should work out of the box?

However, when I try to install, zfs dkms is saying that the module will not be compiled due to missing kernel headers. Fine, but where are the headers?

I'm using a fresh install from https://www.armbian.com/rockpro64/

armbian-config - Software - headers_install does nothing, installing linux-headers-current-rockchip64 installs 22.05.4, not 22.08.1 that I have, and "compiling headers", whatever that might be, fails 

how do I get a matching kernel and headers, any version?

root@rockpro64:~# dpkg -l | fgrep rockchip
ii  linux-dtb-current-rockchip64    22.08.1                                 arm64        Armbian Linux DTB, version 5.15.63-rockchip64 current
ii  linux-image-current-rockchip64  22.08.1                                 arm64        Linux kernel, armbian version 5.15.63-rockchip64 current



root@rockpro64:~# apt upgrade -y linux-headers-current-rockchip64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  linux-headers-current-rockchip64
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.1 MB of archives.
After this operation, 80.2 MB of additional disk space will be used.
Get:1 http://armbian.hosthatch.com/apt jammy/main arm64 linux-headers-current-rockchip64 arm64 22.05.4 [12.1 MB]
Fetched 12.1 MB in 2s (6,470 kB/s)
Selecting previously unselected package linux-headers-current-rockchip64.
(Reading database ... 42002 files and directories currently installed.)
Preparing to unpack .../linux-headers-current-rockchip64_22.05.4_arm64.deb ...
Unpacking linux-headers-current-rockchip64 (22.05.4) ...
Setting up linux-headers-current-rockchip64 (22.05.4) ...
Compiling headers - please wait ...
scripts/sign-file.c: In function ‘display_openssl_errors’:
scripts/sign-file.c:89:9: warning: ‘ERR_get_error_line’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
   89 |         while ((e = ERR_get_error_line(&file, &line))) {
      |         ^~~~~

The failure on the emmc card is between /scripts/local-premount and /scripts/local-block

it fails with

gave up waiting for root file system device
...
alert! UUID=ed78b... does not exist. dropping to shell!

and I am at a busybox shell in (intramfs)

I was wondering if booting from the emmc card was expected to work, or if anyone could remember what needs to be tweaked for the kernel to find the root filesystem on the emmc card.

Cheers

Only "chirps and chips" come through during extended playback. Only hdmisound device is affected, not analog.
Duplicate of improperly "resolved" thread

Armbian 22.02 Bullseye Kernel 5.15.25-rockchip64

Armbian 22.02 Bullseye Kernel 5.16.16-rockchip64

working in 5.10.60-rockchip64

steps to reproduce:

aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Right.wav

dmesg | grep es83
   [   10.077582] es8316 1-0011: Failed to get IRQ 0: -22

card 0: Analog [Analog], device 0: ff890000.i2s-ES8316 HiFi ES8316 HiFi-0 [ff890000.i2s-ES8316 HiFi ES8316 HiFi-0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

I'm able to load libcomposite, the configfs driver, but that does not pull in a USB device mode driver. I'm unable to attach armbian monitor status right now but will update my post with it.

Hi,

I have had some issues trying to boot from eMMC with the last version of Armbian (kernel v5.4) while it's working perfectly on Armbian with a v4.4 kernel.

Images not working:

https://dl.armbian.com/rockpro64/archive/Armbian_20.05.2_Rockpro64_bionic_current_5.4.43.img.xz

https://dl.armbian.com/rockpro64/archive/Armbian_20.05.4_Rockpro64_focal_current_5.4.46.img.xz

Working image:

https://dl.armbian.com/_old/rockpro64/archive/Armbian_5.98_Rockpro64_Debian_buster_default_4.4.192.7z

I though I messed up with the SPI or the eMMC card but after trying all I could, it finally worked using an old version of Armbian.

The new images are working on a SD-Card but it's much slower to boot.

On a eMMC card it get completely stuck (see attached file),  I managed to get the "Done" displayed waiting much longer (just after the "Running /scripts/local-premount" step but nothing more).

The CPU is becoming super hot while it stuck.

I have the same issue on two different RockPro64 cards and with two different eMMC cards.

I have tried the "Disable SPI while booting" step but it didn't help:

https://wiki.pine64.org/index.php/ROCKPro64#Disable_SPI_.28while_booting.29

It would be great if I could have a kernel 5.4 running on eMMC on those cards, please let me know if I can help.

Kind regards,

Baptiste

I was trying to enable i2c on my RockPro64,  and when looking at the documentation in the overlay directory, it states this:

rockchip (Rockchip)

### Provided overlays:

- i2c7, i2c8, pcie-gen2, spi-spidev, uart4, w1-gpio

### Overlay details:

### i2c7

Activates TWI/I2C bus 7

I2C7 pins (SCL, SDA): GPIO2-B0, GPIO2-A7 GPIO1-C5, GPIO1-C4

### i2c8

Activates TWI/I2C bus 8

I2C8 pins (SCL, SDA): GPIO1-C5, GPIO1-C4

Note that the  "GPIO1-C5, GPIO1-C4" from i2c8 is accidentally included on the i2c7 pins line.

I would submit a PR for this change,  but ... I'm not sure where this document actually lives, and it's not easy to figure out.

I see that @Igor  is listed as the maintainer of the package, but that's not helping me find the source to submit changes.

Also, for clarity, it would be nice to include that    i2c8  is the pi-connector,  and  i2c7  is the Digital Video Port

Happy to submit changes if somebody can point me to the right place.

Thanks

Hi,

I am looking at investing in a RockPro64 NAS setup using the Pine64 Desktop casing and other necessary accessories. I'm hoping to run OpenMediaVault on it and have 2 3.5" HDDs attached. The entire setup would be configured to be a backup of my operational NAS (Helios4) in a different location (i.e. different room of the house).

My reading of the forum and the armbian download section has me a bit confused. The download section indicates that the board is supported, but the forum indicates it's a WIP.

Just trying to understand the status/stability of the board for what I'm planning on using it for and whether it would be a good investment or a waste of money.

Also wondering whether this post regarding updating the CPU governor is related -  and will be a benefit - to the RockPro64 as both the NanoPi M4 and RockPro64 share the same SoC RK3399.

Thanks

U need ixgbe to run my Intel X550T 10G Ethernet NIC.

That module seems to be a part of linux-modules-$(uname -r) package. My kernel version is 5.10.60-rockchip64. However, I do not have linux-modules-5.10.60-rockchip64 available via apt.

# apt install linux-modules-$(uname -r)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package linux-modules-5.10.60-rockchip64
E: Couldn't find any package by glob 'linux-modules-5.10.60-rockchip64'

I have apt downloaded linux-modules of some greater kernel release to make sure it provides ixgbe.ko.

It does:
 

# apt install --download-only linux-modules-5.11.0-40-generic

# dpkg --contents /var/cache/apt/archives/linux-modules-5.11.0-40-generic_5.11.0-40.44~20.04.2_arm64.deb | grep ixgbe
drwxr-xr-x root/root         0 2021-10-26 15:50 ./lib/modules/5.11.0-40-generic/kernel/drivers/net/ethernet/intel/ixgbe/
-rw-r--r-- root/root    665577 2021-10-26 15:50 ./lib/modules/5.11.0-40-generic/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
drwxr-xr-x root/root         0 2021-10-26 15:50 ./lib/modules/5.11.0-40-generic/kernel/drivers/net/ethernet/intel/ixgbevf/
-rw-r--r-- root/root    148153 2021-10-26 15:50 ./lib/modules/5.11.0-40-generic/kernel/drivers/net/ethernet/intel/ixgbevf/ixgbevf.ko

How do I get ixgbe for my actual kernel?

Thanks,

- Aleksandr

Hello,

I installed Armbian Hirsute xfce bleeding edge kernel 5.13.y on my RockPro64 4GB and updated it right after that. After restarting after the update, ethernet doesn't work anymore. (Wifi connecting icon is shown and no connection to ethernet) dsmesg says that the link is up. 
armbianmonitor: https://paste.ubuntu.com/p/9Yz8SJVrzS/
apt/history.log: https://paste.ubuntu.com/p/GQbfZp3Xch/
For apt history only the last two operations seem relevant. I assume the previous ones are made by whoever/whatever created the image.

Hi,

I'm not sure if it is a bug as by board seems to work correctly, however I thought I should post it.

In the latest version (5.10.60-rockchip64) I'm getting a few errors in dmesg:

debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!

I hadn't seen these errors in the previous version (5.10.43)

Logs are here:

http://ix.io/3yY5

Regards,

After last apt upgrade (v21.05.4), lightdm on a RockPro64 does not start anymore.

rockpro64:~:# systemctl status lightdm.service   
● lightdm.service - Light Display Manager
     Loaded: loaded (/lib/systemd/system/lightdm.service; indirect; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sun 2021-06-20 16:13:01 CEST; 21min ago
       Docs: manlightdm(1)
    Process: 1877 ExecStartPre=/bin/sh -c [ "$(basename $(cat /etc/X11/default-display-manager 2>/dev/null))" = "lightdm" ] (code=exited, status=0/SUCCESS)
    Process: 1880 ExecStart=/usr/sbin/lightdm (code=exited, status=1/FAILURE)
   Main PID: 1880 (code=exited, status=1/FAILURE)

Jun 20 16:13:01 rockpro64 systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 5.
Jun 20 16:13:01 rockpro64 systemd[1]: Stopped Light Display Manager.
Jun 20 16:13:01 rockpro64 systemd[1]: lightdm.service: Start request repeated too quickly.
Jun 20 16:13:01 rockpro64 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Jun 20 16:13:01 rockpro64 systemd[1]: Failed to start Light Display Manager.

and trying to start manually as root

rockpro64:~:# systemctl start lightdm.service 
Job for lightdm.service failed because the control process exited with error code.
See "systemctl status lightdm.service" and "journalctl -xe" for details.
rockpro64:~:# journalctl -xe 
Jun 20 16:36:33 rockpro64 systemd[1]: Failed to start Light Display Manager.
-- Subject: A start job for unit lightdm.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- A start job for unit lightdm.service has finished with a failure.
-- 
-- The job identifier is 1583 and the job result is failed.
Jun 20 16:36:33 rockpro64 systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 5.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Automatic restarting of the unit lightdm.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Jun 20 16:36:33 rockpro64 systemd[1]: Stopped Light Display Manager.
-- Subject: A stop job for unit lightdm.service has finished
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- A stop job for unit lightdm.service has finished.
-- 
-- The job identifier is 1648 and the job result is done.
Jun 20 16:36:33 rockpro64 systemd[1]: lightdm.service: Start request repeated too quickly.
Jun 20 16:36:33 rockpro64 systemd[1]: lightdm.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- The unit lightdm.service has entered the 'failed' state with result 'exit-code'.
Jun 20 16:36:33 rockpro64 systemd[1]: Failed to start Light Display Manager.
-- Subject: A start job for unit lightdm.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- A start job for unit lightdm.service has finished with a failure.
-- 
-- The job identifier is 1648 and the job result is failed.

running lightdm as root with debug enabled

rockpro64:~:# lightdm --debug                    
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.30.0, UID=0 PID=3791
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-disable-guest.conf
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-disable-log-backup.conf
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-greeter-wrapper.conf
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-guest-wrapper.conf
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/60-lightdm-gtk-greeter.conf
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /var/lib/flatpak/exports/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /root/.local/share/flatpak/exports/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf.d/10-slick-greeter.conf
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf.d/11-armbian.conf
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.19s] DEBUG: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ?gio-vfs?
[+0.20s] DEBUG: Monitoring logind for seats
[+0.20s] DEBUG: New seat added from logind: seat0
[+0.20s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.20s] DEBUG: Seat seat0: Starting
[+0.20s] DEBUG: Seat seat0: Creating greeter session
[+0.20s] DEBUG: Seat seat0: Failed to find session configuration slick-greeter
[+0.20s] DEBUG: Seat seat0: Failed to create greeter session
[+0.20s] DEBUG: Failed to start seat: seat0

Any ideas how to drill further down the problem?

Hey folks...

We are trying to use a DHT22 sensor on rockpro64 using armbian (buster)...

Is there something we need to know about GPIO pin ?

We are trying to compile and use this code as a starter...

https://github.com/ayufan-pine64/dht22-pine64.git

But we got a segfault when using it...

thanks

Hi everyone,

I tried the 20.11.3 version of Armbian, I have manually updated the SPI with U-boot using armbian-config (after an apt update && apt upgrade), but it doesn't start from a PCIe NVME SSD :-/

Is there something that I have missed? Any idea is more than welcome !

Here is my serial - USB console output:

Kind regards,

Baptiste

Hello,

I own a RockPro64 and I'm using Armbian Legacy Buster 4.4.213-rockchip64. Everything mostly works, although I've had a pretty annoying issue. Reboot just doesn't work.

Every time I do a 'sudo reboot' (or any equivalent for that matter, as for example 'sudo shutdown -r now') it doesn't work. Although it apparently reboots, the TV monitor to which my box it's connected via HDMI lose connection and all, nothing actually happens. Both the red and the white leds of the RP64 turn on and keep on all time (instead of just one of them blinking, as expected) and then it will work only if I poweroff and on again, either by unplugging the power cable or pushing the reset button. That's pretty annoying, since for obvious reasons I can't remotely reboot the machine...

I noticed that it only happens with the legacy kernels (I've tried Armbian and Ayufan, both have the exact same behavior). Current kernels work properly, but I really need, at least for now, keep using legacy (I'm trying to use the tool provided by the developer JMCC in order to use Kodi and it doesn't work on mainline so fat).

I've googled for a while for this specifc issue and used the search from this forum but found nothing.

Any help would be very appreciated.

Board is RockPro64, legacy kernel - 4.4.213-rockchip64.  The issue is this:

[ 1451.681339] ohci-platform fe3a0000.usb: frame counter not updating; disabled
[ 1451.681972] ohci-platform fe3a0000.usb: HC died; cleaning up
[ 1451.682516] usb 8-1: usbfs: usb_submit_urb returned -19
[ 1451.682569] usb 8-1: USB disconnect, device number 2

It happens only on the USB2.0 ports with different keyboards, mice, custom USB HID device, webcam. The other 2x USB 3.0 ports are working fine with the same devices.

Tried fixes so far - turning usbcore.autosuspend option off, adding usbhid.quirks for every device.

extraargs=usbcore.autosuspend=-1 usbhid.quirks=0x10c4:0x85d4:0x00000400

The problem seems to be fixed in mainline kernel, as 24/7 test with continuous transfers to a custom USB HID device passes for 3 days that I tested.

I cannot use mainline kernel since I need the VPU and GPU accelerated X with EGL. 

Any advice on fixing this in the legacy kernel is appreciated.

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE LEGACY MULTIMEDIA INTEGRATION. PLEASE REFER TO THIS TOPIC:

So finally we have the first version of:

The UN-official, UN-supported, etc...

RK3399 MEDIA TESTING SCRIPT

This is the first release of the RK3399 media testing script. The script provides a functionality similar to its RK3288 equivalent:

• Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 3.2 / OpenCL 1.2 support.
• Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi.
• Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple).
• A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0.
• Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with:
  •  Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.),
  • and a simple Pulseaudio GTK equalizer using LADSPA.

Here is a more thorough documentation:

ARMBIAN UNOFFICIAL RK3399 MEDIA TESTING SCRIPT
----------------------------------------------
v1.0 Bionic - 2019/01/11


This script will install several multimedia-related software pieces in a
RK3399 Ubuntu Bionic Armbian desktop default image (kernel 4.4.y).
Currently it only supports the installation of the features, while
uninstall must be performed manually.

The script must be run in a command line from the same directory it was
unpacked (./media-rk3399.sh), and will ask for superuser privileges if
not launched with "sudo". Each subfolder contains, in addition to the
packages needed for installation, a text file with information about the
sources for those packages.

The script will present the user with a menu where they can select the
features to be installed. Here is a brief description of each option:

- System: This option will install the base libraries, X server packages
          and system files configuration. It must be run at least once
          before installing any of the other features, or after any
          system upgrade that modified X or Chromium configuration.
          Enabling system config will also present the user with the
          choice of two different versions of the Rockchip X server:
            · Glamor: The tweaked X server that you can download from 
              Rockchip repos, with a few additional tweaks. It will use
              Glamor for GPU acceleration, providing good 3D performance
              and complete vsync, but giving a very laggy experience in 
              general desktop usage.
            · Armsoc: An updated version of the xf86 Armsoc driver. It
              only supports fullscreen vsync, but on the other hand the
              overall desktop experience is much snappier.
           
- Devel: When this option is enabled, the script will install the 
         development libraries for every other option that is selected.
         So, for example, if in your first run of the script you keep 
         this option disabled and enable the rest, it will install all 
         the features but without any devel lib. If eventually you need,
         e.g., to compile some app requiring Gstreamer development libs,
         then you can run again the script, and select only "Devel" and
         "Gstreamer", so in that run it will only install Gstreamer with
         the development libraries, without touching the rest.
         
- MPV: This is a RKMPP accelerated version of MPV. In order to use the 
       hardware acceleration, it needs to make use of KMS for display,
       which means that it will ignore the X server if it is running,
       and play video in a full-screen overlay, using keyboard or LIRC
       to control the player. Type "man mpv" for a list of keyboard
       controls (tip: shift+Q will save position and exit).
       Alternatively, you can also use software decoding, and output to
       a X window with mouse support. It will still have some display
       acceleration through X11/EGL, though not as efficient as GBM/KMS.
         · To use the X, non-RKMPP version, just type "mpv <file>" in
           the console, or use the launcher labeled simply "MPV".
         . To use the GBM+RKMPP version, type "mpv-gbm <file>", or use
           the "MPV (GBM)" launcher.
         · You can use the player even in a console-only session.

- Gstreamer: These are the Rockchip Gstreamer plugins for media playback
             and capture.
             Notice that the Gstreamer plugin is the only method that
             allows full RKMMP+KMS acceleration associated to a X 
             window.
               · To play a video in a X session, use the launcher "Rock-
                 chip Gst Player".
               . From the command line, in a X session, type:
                 "gst-play-1.0 --videosink=rkximagesink <file>"
               . From a console-only session, type:
                 "gst-play-1.0 --videosink=kmssink <file>"

- CLSamples: A couple of simple programs to test OpenCL capabilities:
	     · Compiled examples from the Arm Compute Library
	     . An old GPU crypto miner (cgminer) with support for
	       extra algorythms like Skein.
	     They are installed under ~/clsamples, where you can find
	     a readme.txt file with instructions.

- GL4ES: An Opengl-ES wrapper library that will allow you to use OpenGL
         1.5-2.0 compatible programs with hardware acceleration. 
         More info: https://github.com/ptitSeb/gl4es.
         · In order to make it easier to use the library, we have
           included a script called "glrun", that will set the proper
           environment variables. Launch your OpenGL program like this:
           "glrun <command>"
         
- Streaming: This will install Chromium with the Widevine DRM and
             Pepper-Flash libraries enabled, allowing you to watch 
             videos from sites such as Netflix, Amazon Prime or Hulu.
             It will also install the h264ify addon, which will force
             all Youtube videos to use the H.264 codec.
             Since those libraries are only available for 32-bit ARM,
             the script will install a whole armhf docker container,
             with a minimal ubuntu and Chromium installation on it. It
             will also install a wrapper for running commands inside the
             docker container called "armhf-run":
               · Type "armhf-run chromium-browser" to launch the 32-bit
                 Chromium in regular mode.
               . Type "armhf-run chromium-streaming" to launch it in
                 streaming mode (may cause problems with non-streaming
                 webpages).
             The script will also install desktop entries for both 
             options.

- Equalizer: A GTK-based equalizer for PulseAudio, using LADSPA. You
             need to enable it through the menu entry, and select the
             desired preset or tweak your own settings. The "Boosted"
             preset is recommended for everyday use.
             This package is old and unmaintained, but I still find it
             useful.

- Kodi: Kodi 18.0 Leia rc4. This version is supposed to be stable
        enough for normal use. But the main purpose of including Kodi in
        the script is to test the new RKMPP+KMS implementation. We don't
        intend to offer a full-fledged distribution of Kodi. For that, I
        recommend using LibreELEC.
        It cannot be launched from an active X session, you need to
        switch to a virtual terminal and stop the X server first.
        · The "Kodi" desktop launcher will do the whole process for you.
        · From the command line, in a X session, type:
          "kodi-gbm-wrapper" for the same effect.
        · If you are already in a console-only session, you can just 
          type "kodi".

All the RKMPP accelerated players can handle up to 4K@60 10-bit HEVC 
with perfect smoothness. 4K VP9 8-bit is fine, but don't try 
VP9 10-bit or you'll get a green screen and your /var/log partition
filled up in less than ten seconds ;)


Please report bugs and suggestions in the thread dedicated to this
script at the Armbian Forum. Enjoy!

JMCC.

>>> DOWNLOAD LINK <<<

Prerequisites:

• You need a fresh Armbian Bionic desktop image with legacy kernel installed.

Instructions:

1. Download the file above
2. Untar it: tar xvf media-rk3399_*.txz
3. cd media-script
4. ./media-rk3399.sh

Notes:

• This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC.
• Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance.
• That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.

Enjoy!

Typically its when I load Media web sites like the BBC ,.... but it even occurs when I load this forum!!

I am trying to develop some C GPIO library to help the rockPro64 community, but its hopeless. I have to work on console and web brows on a laptop.

I have ordered a KVM to help but this is really frustrating.

Because the HW locks up I can not detect any issues in the logs and I don't know how to set up a HW trace in the graphics drivers.

I have eliminated any Power issues. I have a pico cluster case and decent heatsink ... I have ordered some Heatsink fans but CPU is in the 40 Deg C.

Any Ideas how I find out why the HW just freezes ?

It must have something to do with the mali drivers ?

Any ideas welcome

hi all, I am wondering if there's any reason that CEC is not built into legacy kernel for RK3399. 

In https://github.com/armbian/build/blob/master/config/kernel/linux-rk3399-legacy.config, module dw-hdmi-cec is not enabled.

# CONFIG_DRM_DW_HDMI_CEC is not set

If no special reason, I can make a PR for this.

Thank you!

I have two rockpro64 boards.

One board runs Debian buster with a slightly extended ayufan 5.4.0-rc1 kernel where as the other runs a Armbian (Debian) buster with the current project supplied 5.4.0-rc1 kernel.

On the Debian on I have installed the nice ats solution (https://github.com/tuxd3v/ats#install)

On the Armbian one the fan is running all the time. I tried to install ats there as well but I failed.

Also I found that basically the  /sys/devices/platform/pwm-fan/hwmon is not there, only upto pwm-fan I have.

Is there some module I need to load or compile into the kernel to get ats working on the Armbian based one as well?

Any hints are highly appreciated.

Kind Regards

Martin

I have a RockPro64 that was initial setup using the Armbian 20.02.1 buster desktop image (using the 5.4.20 kernel). Over the past few months, I have accepted each minor release of Armbian up to the 20.05.7 release with a 5.4.49 kernel

Yesterday, I installed the 20.08 upgrade with 5.7.15 kernel, and the board failed to boot. I have only just got it working again. (I had to restore the kernel and supporting files from a recent backup, and restore symlinks in /boot).

I don't know the root cause. I have ordered a second MicroSD card so that I can try booting from a fresh 20.08 image, and I will report back on what happens. In the meantime, I have attached a copy of the serial port output during the failed boot. (The last line is where it got stuck. I left it for an hour before powercycling)

Verbose Boot bad new 5.7.15 kernel.txt

I just booted Armbian_20.08_Rockpro64_focal_current_5.7.15.img via sdcard , but HDMI output seems to stop after "Starting Kernel". Just after that I see some yellow/black vertical lines on my monitor and then the screen goes black, no more HDMI input on the monitor.

Logging into Armbian on the RockPRO then works fine via ssh, can do the setup, update etc. So it looks like a problem with HDMI output?

Anyone ideas how to solve this? Would like to have console terminal access via HDMI as last resort

Thanks in advance!

p.s. Just tried the Armbian_20.08_Rockpro64_focal_current_5.7.15_desktop which seems to have the same issue

Goal

We are building an appliance on the RockPro64 board, with eMMC and an PCIe SSD attached, using a custom-built Armbian Ubuntu 18.04 image with extensive post-configuration (packages, appliacations, overlayroot...) within the boot process. The image is then processed by Mender to create a true dual-root filesystem over-the-air update system with fallback (we invested a lot of resources to extend Mender for Armbian and RockPro64). This build process works perfectly and is exactly what we need.

Issue

The reliability, however, is bad. In an older topic of mine, I documented our issues of regular device reboots due to kernel panics and infrequent freezes. We never really figured out what causes these crashes. It depends on the individual hardware, but on average reboots happen every few days, freezes that need a manuall power cycle every one or two weeks. This is also the case when using the official images.

Workaround

When using the exact same custom-built Armbian image, but replace the kernel with an Ayufan kernel, the images are stable. The devices run for weeks without reboots or freezes, independent on the individual hardware.

Quote

dpkg --install linux-firmware-image-4.4.202-1237-rockchip-ayufan-gfd4492386213_4.4.202-1237-rockchip-ayufan_arm64.deb
dpkg --install linux-image-4.4.202-1237-rockchip-ayufan-gfd4492386213_4.4.202-1237-rockchip-ayufan_arm64.deb

ln -sf /boot/vmlinuz-4.4.202-1237-rockchip-ayufan-4.4.202-1237-rockchip-ayufan /boot/Image

Options

This is obviously a very hacky way of creating a Linux image. So we have two options:

1. (preferred) continue to use Armbian, but with a stable kernel
2. switch to Ayufan and eat all the costs: implement new build system, redesign post-configuration, extend Mender solution

The way forward

I am not a Linux kernel expert. I am also not sure how the two projects Armbian and Ayufan are related exactly, but it seems that Armbian uses some of Ayufans resources in the build process. For me the question then becomes where the differences originate.

• Is this something that can be and people are willing to figure out?
• How can I support that by running tests, providing logs or assist in other non source-code tasks?

Any help is appreciated.

Hi there! I am trying to set up communication between an Attiny85 and my RockPro64 over UART (running Armbian, kernel `Linux rockpro64 5.8.1-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 08:17:08 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux`). The issue is that I can't connect to the serial port:

rock64@rockpro64:~$ sudo picocom -b 115200 /dev/ttyS4
picocom v3.1

port is        : /dev/ttyS4
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

FATAL: failed to add port: Filedes is not a tty

Here are some details about my setup:
An Attiny85 is powered from a 3V coin cell. Here is the wiring:

• Battery positive - Attiny85 pin 8
• Battery negative - Attiny85 pin 4 - RockPro64 ground on GPIO pin 6
• Attiny85 pin 6 (PB1) - RockPro64 UART4_RX on GPIO pin 21 (connected through a 1K current-limiting resistor)
• UART4_TX is not connected because currently I only need unidirectional communication

I used Arduino IDE with a USBtinyISP programmer to program my Attiny85 with the following test code:

#include <SoftwareSerial.h>

#define RX 0
#define TX 1

SoftwareSerial serial(RX, TX);

void setup() {
  // put your setup code here, to run once:
  serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
  serial.println("ping");
}

I have tried using different kernels (including dev) and switching between different combinations of overlays (UART4 and SPI1 share the same pins on RockPro64). The RockPro64 itself is booting from an eMMC module, the SPI flash contains U-Boot for USB and PXE boot support.

Is there any way I can fix this issue? Are there any other easy-to-use alternatives to UART for establishing bidirectional communication? Any help is appreciated!

Thanks,
Anton

I'm using this guide here from over on the OMV forum which suggests that Buster Server is the only thing that will work; this is based on the 4.4 kernel, and the suggested alternate of Buster Minimal is not present.

I've tried downloaded from multiple locations and cannot get the SHA to match.

The 256 per Checksum utility is 760BD8FA51316D07E875D5B8687E837C8C00070E68F44B8B413C76EC217C606B

while the file from the Armbian download site is 3ddc7bc3e47bc39a9a9bed6109d35ca712bd34a6206121d37814ca8faf4b8798

If i try to flash the image to SD and boot device fails to boot (performed all required tests and tried different cards).

So at this point I don't know if i'm looking at a bad download or a compatibility issue with Buster? Any help would be greatly appreciated!

Please, does the latest Armbian support setting the resolution on boot? I want to use this resolution in my SDL2 based app, so things like randr does not help me.

Thank you very much.

The exact same problem is observed with Armbian_20.08_Rockpro64_focal_current_5.7.15_desktop.img.

If I write the Armbian_20.05.2_Rockpro64_buster_current_5.4.43_desktop.img image to the SD Card, then the system starts and installs normally.
Then I use apt update and apt upgrade, as a result, the system is updated to version 5.7.15.
I am trying to transfer the system to a connected SSD, after which the system stops booting.

PS Sorry for my English.

I am running a rockpro64 and updated my kernel to 5.7 (linux-image-current-rockchip64 package), but I am not able to run ZFS any longer because ZFS/0.8.4 does not support 5.7 kernel and ZFS/2.0.0rc1 dkms gives me a build failure with linux-image-current-rockchip64 v20.08 (symbol "__stack_chk_guard" is undefined). I was able to build ZFS/2.0.0rc1 with linux-image-current-rockchip64=20.05.7. I am not able to downgrade my kernel because the apt-cache only shows the latest version of linux-image-current-rockchip64 available. Any suggestions on where I can get the old linux-image-current-rockchip64 package (v20.05.7)?

Thanks in advance guys, love the work done here.

~Brocklobsta

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:IWefc//FoZcRXp...fpsF0eM. Please contact your system administrator. Add correct host key in C:\Users\User/.ssh/known_hosts to get rid of this message. Offending ECDSA key in C:\Users\User/.ssh/known_hosts:3 ECDSA host key for has changed and you have requested strict checking. Host key verification failed.

EDIT: I figured out I should be looking on my Windows laptop when I was expecting it to be on the Ubuntu server I was creating haha! Getting user@IP address: Permission denied (publickey) now though

nano /boot/boot.cmd

Go to line that starts with:

setenv bootargs and  add at the bottom of the row:

ahci_sunxi.enable_pmp=1

recompile with:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Restart Almbian and the SATA Port Multiplier was activated.

I now own a RockPro64 with Armbian and a 6-port PCIE sata card.

Should buy a card with 8-10 ports to add hdd that I will need to make backups.

At the moment, however, I would like to enable PMP support also on this card so that I can immediately install the backup disks because they are urgent because a disk has problems.

The procedure described above for Banana PI does not work, I believe it is due to a different CPU architecture.

Before Kernel 4.x on the "banana pi" you had to recompile the kernel, could you tell me what is the exact procedure to enable PMP support also on Rockchip RK3399 with 4.4.213 kernel?

Thank you

At first i need to thank you for all the work you done.

I'm runnig my ROCKPro64 no for a while now

Today i wanted to try wifi and bt  but it looks we dont have any drivers for the module

AMPAK AP6256 Combo Module and made specifically for the ROCKPro64

Debian 10 headless 20.08.0-trunk

Can someone help me to reach the goal to use my wifi ?

The only issue I have is that once the OS starts up the fan comes on and never stops - it seems to be running 100% all the time. It the speed meant to vary? And is it meant to turn off sometimes when not required?

I'm wondering if I am I missing a config file entry for this.

Thanks for any assistance and well done on the distro.

I have a very strange issue:

kernel 5.4.14-rockchip64

debian_version 10.3

Armbian 20.02.0-rc1 stable

cable is OK - checked

eth0 in /etc/network/interfaces.d/eth0 set  to dhcp

----

unfortunately the rockpro64 gave up with an hardware ram issue

The unit was replaced and luckily I have an image: March 3, 2020

which was OK and fully functional.

Today I threw it on the SD-Card and I do not have a NIC at all.

A.m. Data drawn from the OS

hwinfo issues RTL8211F

irq:0 27 "eth0"

lshw

network:0  eth0 id9 with MAC

network:1 DISABLED dummy0

ip a

dummy0 down (Never had this scrap before)

eth0: NO CARRIER

ip link show

dummy0 down

eth0: BROADCAST UP...  state UP

Any ideas what happens here????

What am I missing???

Thank you - willi

btw: my rockpros take about 90 seconds to boot up and I do have to power on/off the screen 2 times before the interface

realizes that it has got a screen????

Rockchip64 20.05.4 kernel images are missing from the PPA. There is only 20.05.3 in https://apt.armbian.com/pool/main/l/linux-5.4.45-rockchip64/ and no https://apt.armbian.com/pool/main/l/linux-5.4.46-rockchip64/

I am looking for the header package in particular to build zfs.

Can you make those packages available, please?

Best regards,

kryps

compiling Kernel 5.4.40 (setting in lib.config with KERNELBRANCH=tag:'5.4.40') under Vagrand  with RT-Patch "patch-5.4.40-rt24.patch"  putting in " ~/build/userpatches/kernel/rockchip64-current/ "for RockPro64 fails.

........

[ o.k. ] * [l][c] general-rt5651-add-mclk.patch 
[ o.k. ] * [l][c] mp8859-kbuild-makefile.patch 
[ o.k. ] * [c] patch-5.4.40-rt24.patch 
[ o.k. ] * [l][c] rk3328-add-dmc-driver.patch 
[ o.k. ] * [l][c] rk3328-audio-and-renegade-supplies.patch 
[ o.k. ] * [l][c] rk3328-clean-up-codec-gpio-SD.patch 
[ o.k. ] * [l][c] rk3328-fix-wrong-mmc-shift.patch 
[ o.k. ] * [l][c] rk3399-add-sclk-i2sout-src-clock.patch 
[ o.k. ] * [l][c] rk3399-adjust-txpbl-for-mtu-1500.patch 
[ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch 
[ o.k. ] * [l][c] rockpi4-0005-arm64-dts-enable-es8316-audio.patch 
[ o.k. ] * [l][c] timekeeping32-tweaks-for-5.0.y.patch 
[ o.k. ] * [l][c] unlock-temperature.patch 
[ .... ] Compressing sources for the linux-source package 

.....

The following compiling process stopped with:

......

  CC      security/inode.o
  CC      security/lsm_audit.o
  CC      security/device_cgroup.o
  CC      kernel/configs.o
  AR      security/built-in.a
  AR      kernel/built-in.a
  CC [M]  kernel/kheaders.o
[ error ] ERROR in function compile_kernel [ compilation.sh:378 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated 

Any idea what goes wrong ?
 

Martin

Hi, 

hot o enable splash screen on boot fo this image:

Armbian_20.02.1_Rockpro64_bionic_legacy_4.4.213_desktop.img

for Rockpro64?

Thanks

Has anybody seen this message at boot:

[    5.352826] CPU4: failed to come online
[    5.352835] CPU4: failed in unknown state : 0x0
[   10.481328] CPU5: failed to come online
[   10.481336] CPU5: failed in unknown state : 0x0

Then, the A72 cores don't show up (unsurprisingly since these are the two cores that somehow did not come online). On top of that, the kernel throws a backtrace (related to sound if I understand correctly):

------------[ cut here ]------------
[   13.014782] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1990 request_threaded_irq+0x144/0x180
[   13.014784] Modules linked in:
[   13.014793] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.4.26-rockchip64 #20.02.5
[   13.014795] Hardware name: Pine64 RockPro64 (DT)
[   13.014799] pstate: a0000005 (NzCv daif -PAN -UAO)
[   13.014804] pc : request_threaded_irq+0x144/0x180
[   13.014808] lr : request_threaded_irq+0x6c/0x180
[   13.014810] sp : ffff80001004b9b0
[   13.014813] x29: ffff80001004b9b0 x28: 0000000000000000
[   13.014817] x27: ffff0000ef78c0c0 x26: ffff8000111c8d98
[   13.014822] x25: 0000000000000000 x24: 0000000000000007
[   13.014826] x23: ffff0000f0914870 x22: ffff800010b2dce0
[   13.014830] x21: ffff0000f142a000 x20: 0000000000000000
[   13.014834] x19: ffff80001141bee0 x18: 0000000000000001
[   13.014838] x17: ffff800011188d00 x16: ffff800011188d08
[   13.014843] x15: ffffffffffffffff x14: ffff80001137b508
[   13.014847] x13: ffff00016f1e14b7 x12: ffff0000ef1e14c3
[   13.014851] x11: ffff0000f67ac268 x10: 0000000000000040
[   13.014855] x9 : ffff80001139f028 x8 : ffff80001139f020
[   13.014859] x7 : ffff0000f10002a8 x6 : 0000000000000000
[   13.014863] x5 : ffff0000f1000248 x4 : 0000000000000000
[   13.014867] x3 : 0000000000000000 x2 : 0000000000000000
[   13.014871] x1 : 0000000000000007 x0 : 0000000000031600
[   13.014875] Call trace:
[   13.014880]  request_threaded_irq+0x144/0x180
[   13.014887]  snd_mtpav_probe+0x15c/0x3d8
[   13.014893]  platform_drv_probe+0x50/0xa0
[   13.014899]  really_probe+0xd8/0x300
[   13.014902]  driver_probe_device+0x54/0xe8
[   13.014906]  __device_attach_driver+0x80/0xb8
[   13.014910]  bus_for_each_drv+0x78/0xc8
[   13.014915]  __device_attach+0xd4/0x130
[   13.014918]  device_initial_probe+0x10/0x18
[   13.014922]  bus_probe_device+0x90/0x98
[   13.014927]  device_add+0x3c4/0x5f0
[   13.014930]  platform_device_add+0x10c/0x230
[   13.014934]  platform_device_register_full+0xc8/0x140
[   13.014940]  alsa_card_mtpav_init+0x74/0xd0
[   13.014945]  do_one_initcall+0x74/0x1b0
[   13.014950]  kernel_init_freeable+0x194/0x22c
[   13.014957]  kernel_init+0x10/0xfc
[   13.014961]  ret_from_fork+0x10/0x18
[   13.014969] ---[ end trace 34ce35f0c45c0a90 ]---

Mathias

On the Rockpro64, with the latest Amrbian dev kernel (5.4.0-rc1-rockchip64 updated on 19th of January), the sata hard drive connected to PCIe through the pine store adapter does not go to sleep anymore. It is properly set with hdparm and a udev rule, it used to work fine with the dev kernel before the 19th of January update. Now, if I issue a sleep commd (hdpram -y /dev/sda) it goes to sleep properly but not by itself after the 5 minutes inactivity I have set up.

Mathias

The idea is simple, if your RK3399 board crashed recently, you just :

• Write what happened during the crash;
• Provide the link you got from sudo armbianmonitor -u , after the crash happened;
• Provide the content of /var/log/kern.log (if this file is present on your system) (attach it or copy the content on pastebin and link it here).

No discussion here.
Feel free to create a new dedicated thread afterwards to talk about the problem you encountered.

Minor issues are welcome too, if they trigger a BUG message in your logs. Just state that it's a minor issue.

When looking at the kern.log, there are quite a few errors and warnings, but comparing to a successful boot these are all also present. So I don't think they cause the freeze directly.

Currently, I recorded the freeze on the latest Armbian Bionic as release just recently. FWIW, I think the same issue also occurs on the previous Debian Stretch image (had various freezes, but have not recorded any details yet).

On a unsuccessful boot, the error occurs after about 8 seconds. A reboot (or two) usually fixes the issue, until the next time...

Jul  8 15:18:23 carol kernel: [    8.528275] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Jul  8 15:18:23 carol kernel: [    8.530625] pgd = ffffffc0ead3f000
Jul  8 15:18:23 carol kernel: [    8.532515] [00000000] *pgd=0000000000000000, *pud=0000000000000000
Jul  8 15:18:23 carol kernel: [    8.534710] Internal error: Oops: 96000005 [#1] SMP
Jul  8 15:18:24 carol kernel: [    8.536753] Modules linked in: af_packet iptable_nat nf_nat_ipv4 nf_nat nf_log_ipv4 nf_log_common xt_LOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp xt_conntrack nf_conntrack iptable_filter snd_soc_rockchip_hdmi_dp rk_vcodec ip_tables x_tables autofs4 phy_rockchip_pcie
Jul  8 15:18:24 carol kernel: [    8.542598] CPU: 5 PID: 1044 Comm: find Not tainted 4.4.182-rockchip64 #1
Jul  8 15:18:24 carol kernel: [    8.544959] Hardware name: Pine64 RockPro64 (DT)
Jul  8 15:18:24 carol kernel: [    8.547155] task: ffffffc0eb247000 task.stack: ffffffc0e1c78000
Jul  8 15:18:24 carol kernel: [    8.549491] PC is at do_dentry_open+0x234/0x2e4
Jul  8 15:18:24 carol kernel: [    8.551687] LR is at do_dentry_open+0x288/0x2e4
Jul  8 15:18:24 carol kernel: [    8.553852] pc : [<ffffff80081f2738>] lr : [<ffffff80081f278c>] pstate: a0000145
Jul  8 15:18:24 carol kernel: [    8.556284] sp : ffffffc0e1c7bbc0
Jul  8 15:18:24 carol kernel: [    8.558403] x29: ffffffc0e1c7bbc0 x28: ffffffc0eb247000 
Jul  8 15:18:24 carol kernel: [    8.560742] x27: 0000000000000000 x26: ffffffc0f26eb000 
Jul  8 15:18:24 carol kernel: [    8.563064] x25: 000000000000011d x24: ffffffc0e1cff690 
Jul  8 15:18:24 carol kernel: [    8.565376] x23: ffffff8008219cb8 x22: 0000000000000000 
Jul  8 15:18:24 carol kernel: [    8.567670] x21: 0000000000000000 x20: ffffffc0f27882b0 
Jul  8 15:18:24 carol kernel: [    8.569954] x19: ffffffc0e1cff680 x18: 0000007fb4979a70 
Jul  8 15:18:24 carol kernel: [    8.572191] x17: 0000007fb48e8848 x16: ffffff80081f3ea4 
Jul  8 15:18:24 carol kernel: [    8.574416] x15: 0000000000000000 x14: ffffffffffffffff 
Jul  8 15:18:24 carol kernel: [    8.576663] x13: 0000000000000000 x12: 0101010101010101 
Jul  8 15:18:24 carol kernel: [    8.578896] x11: 7f7f7f7f7f7f7f7f x10: 0000007fb4a8a140 
Jul  8 15:18:24 carol kernel: [    8.581115] x9 : 0000000000000000 x8 : ffffffc0e1cff7b8 
Jul  8 15:18:24 carol kernel: [    8.583390] x7 : 0000000000000000 x6 : ffffffc0f061d1e9 
Jul  8 15:18:24 carol kernel: [    8.585641] x5 : 0000000000000000 x4 : 00000000000055b1 
Jul  8 15:18:24 carol kernel: [    8.587874] x3 : 00000040eee4a000 x2 : ffffff8008219a20 
Jul  8 15:18:24 carol kernel: [    8.590114] x1 : ffffff8008c02140 x0 : 0000000000000000 
Jul  8 15:18:24 carol kernel: [    8.592341] 
Jul  8 15:18:24 carol kernel: [    8.592341] PC: 0xffffff80081f26b8:
Jul  8 15:18:24 carol kernel: [    8.596219] 26b8  54fffd60 f940c680 f9001660 b4fffd20 aa1603e1 aa1303e0 940c0a2c 2a0003f6
Jul  8 15:18:24 carol kernel: [    8.598764] 26d8  35000700 b9405261 d5033bbf f940ca80 b5000320 b50004b7 f9401660 f9402c17
Jul  8 15:18:24 carol kernel: [    8.601305] 26f8  b5000457 b9405660 370004c0 b9405660 36080100 f9401661 f9400c22 b5000062
Jul  8 15:18:24 carol kernel: [    8.603883] 2718  f9401421 b4000061 320e0000 b9005660 b9405260 12166c00 b9005260 f9409a60
...

Full kern.log boot log:

https://pastebin.com/zcpxB1HQ

Please find attached the full armbianmonitor output here:

https://pastebin.com/NkVAejC6

Any help is greatly appreciated!

deb http://deb.debian.org/debian experimental main contrib non-free

You can then run 'apt update' and install experimental branch packages with 'apt -t experimental install <package>'. To fix the crash in X11, update the following from experimental:

libegl-mesa0
libgbm1
libgl1-mesa-dri
libglapi-mesa
libglx-mesa0
mesa-va-drivers
mesa-vdpau-drivers
mesa-vulkan-drivers

This should allow X11 to run properly.

Thanks to zackw at the Pine64 forums (Original post: https://forum.pine64.org/showthread.php?tid=8915&pid=61701#pid61701 )

It was orginal one topic but split. The other is https://forum.armbian.com/topic/12936-how-to-control-fan-on-rockpro64

@deathisunknown Which kernel are you using? 5.3.xxx?

Until this week end, I was using Ayufan's kernel in order to have ats working (I have the nas box with a harddrive so I want to have some ventilation). I've switched to Armbian's current kernel (5.3.xxx, I don't remember the exact subversion) and noticed that the fan would not spin. Then I tried Armbian's dev kernel (5.4.0-rc1) and my fan works fine. I stumbled upon this thread in the mean time, but since as I remember the latest current kernel got compiled in November, it would not have this change included. On the other hand, I did not call "modprobe" while (quickly) testing the "current" kernel so It could have been there but I missed it...

Using his SPI flash image,  and then using armbian-config   flash from SPi/system on NVME  option worked.  I had commented out the

set the uboot partition section to what is started booting from lines in boot cmd to do the initial testing. 

I have been booting mainline for a while on this device.  It boots much faster,  and two or three weeks agoTobias Schramms  atf patch made into mainline atf so the device no longer hangs on a soft reboot.  

I have booted from sd, emmc and the NVME with this u-boot.  I haven't tried usb3 or usb2.  

Hello,

is booting SPI + NVME supported on RockPro64?
If I use armbian-config and installing system SPI + NVME will not boot the system.
When using SD (mmc) + NVME is OK.

SPI + USB also OK.
Thank you for your help.

I'm using Armbian with Ayufan's 5.3.0rc4 kernel (until ~1 month ago when I decided to freeze the dev kernels, they were not able to expose the pwmon for the fan that I need to keep running to cool my nas case). But I've seen lots of updates flying around about uboot. So I am wondering: are there significant improvements to uboot? I am currently using an old version of uboot on the SPI flash (so it is a little painful to test new version) and I am wondering if I should disable my SPI in order to have uboot on my emmc (to boot off the emmc) or if there is even a newer option to reflash my spi with a newer uboot...

Thanks,

Mathias

PS: so far, every time I've reflashed my SPI with Ayufan's sd-card image, it was very, very slow and I never got any visual feedback so I had to leave it for several hours to be sure it would work

I'm using a RockPro64 boards inside one of my projects and I just noticed an issue related to the reset process. When pushing the reset button, the boards hangs in a reset loop. Using the oscilloscope, I found that the reset signal (OTP_OUT_H) is toggled every 330ms by the CPU and the only way to get it back to work is to power off the board, wait a few seconds, and power it back. The same issue is found if, after a working boot, a quick power cycle is performed.

I tried disconnecting everything from the board but still, when pushing the reset button, the boards hangs in a loop condition (as if it’s constantly crashing at boot).

The console doesn’t print anything.

I have already written to Pine support but they told me it's an OS related issue.

The OS in use is:

1) Linux distribution Armbian 5.90 downloaded from this link:

https://dl.armbian.com/rockpro64/archive/Armbian_5.91_Rockpro64_Debian_buster_default_4.4.184_desktop.7z

2) Kernel based on Linux 4.4.182

Thank you

Greatings for the team.

Currently i am using Armbian Bionic Desktop image with my rockpro64. I went through this link for GPU supported libs installation-

I can see there are libMali.so files in /usr/lib/aarch... folder.

I also installed armnn from this link-

https://developer.arm.com/solutions/machine-learning-on-arm/developer-material/how-to-guides/configuring-the-arm-nn-sdk-build-environment-for-tensorflow-lite/build-arm-nn

And successfully done and tested.

But when i am running on of my tenseflowlite based project, it is throughing error-

Loaded model mobilenet_ssd.tflite
resolved reporter
nn version: 1.0.0
findAvailableDevices
filename:libarmnn-driver.so    d_info:256608     d_reclen:40s
ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:
##Exception: Could not initialize the CL runtime. Error description: clGetDeviceIDs. CL error code: -6
[E][ArmnnDriver]: ArmnnDriver: Failed to setup CL runtime: Could not initialize the CL runtime. Error description: clGetDeviceIDs. CL error code: -6. Device will be unavailable.
[D][ArmnnDriver]: Register Service: armnn (version: 1.0.0)!
[ERROR]: IDevice::getCapabilities returned the error DEVICE_UNAVAILABLE
first invoked time: 488.432 ms

Please suggest any solution related to this Mali GPUs issue. 

Will appreciate your help.

Thanks.

Update!  I manged to build the Panfrost X11 driver.  Here's how I did it:

https://panfrost.freedesktop.org/building-panfrost-mesa.html

Before you create the build directory update the meson_options.txt file

change platforms from auto to x11

change dri_driver from auto to swrast

change gallium-drivers to panfrost

cd to the build directory

meson .. . -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost -Dlibunwind=false --prefix=/{wherever you want}

ninja install

before you start a program

export LD_LIBRARY_PATH=/{wherever your path is}

glmark2-es2

When I get home from work I will test further.

I will update later.  I wanted to post just in case anyone else wishes to try it.

I got to go to sleep, work tomorrow.

This is a serious issue for me as for one of the project i am using more than 20 numbers of rockpro64.

I have installed them in my different locations of office.

I have used two types of OS-
*) LXDE-ubuntu-0.7.9-1067-arm64
*) bionic-containers-rockpro64-0.8.3-1141-arm64

Issue is- Whenever i flash these images to rockpro64, for some days autoboot works well such as if light goes and comes back then machines auto boot itself but after few  days, auto boot does not happens with few machines and i have to press the "power button" to boot up.
I thought with latest OS this issue will solve but same result with latest OS.

Please suggest what can be the exact issue? is it OS related? if yes then why it is not happening in all the machines. Which OS should i use with rockpro64?

Note- When i reflash the OS, then again auto boot happanes but again same result after few days.

Eagerly waiting for the suggesstions.
Thanks

I need rt_preempt in order to run linuxcnc.
I started with the 5.0.21.tar.gz kernel source from <https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/> and the rt_preempt patch 5.0.21-rt16.patch.gz from <https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/>. I applied the patch to the kernel source and compiled it on a 4gb RockPro64. It boots fine into a remote terminal using ssh but there is no display on my HDMI monitor.  The white LED is showing but the red LED is not lit.

I had an earlier version of linux-5.0-rt running on armbian stretch so I mistakenly thought this would be a walk in the park.

Any ideas where to start looking?

Alan

I've had for quite a while the following error messages at startup:

[   39.095667] zswap: default zpool zbud not available
[   39.095670] zswap: pool creation failed

This has happened with various 5.0, 5.1, 5.2 and now 5.3 kernels. Any idea what I should do to fix it?

Mathias

https://github.com/andreiw/rk3399-edk2/

I am building a project that requires Vulkan support for gpu acceleration.

Can someone please suggest how can i get vulkan driver for rk3399?

Thanks.

On my RockPro64, I usually run Armbian with Ayufan's 5.1 kernel (it runs very well and after manually compiling the dtb file most of the error messages at startup are gone). I've tried a few days ago to run Armbian's dev kernel (5.0), and both the sdcard and my usb3 attached ssd could not be detected. The network was also missing. I have pasted the output of armbianmonitor -U here. 

Mathias

Kernel crash when PCIE card is installed (thus pcie host root complex initialize).

Will try previous tags soon, BTW, if anyone successfully run the "mainline" kernel with PCIE cards?

[  161.895780] io scheduler mq-deadline registered                              
[  161.897340] io scheduler kyber registered                                    
[  161.911264] io scheduler bfq registered                                      
[  162.136905] vcc5v0_host: supplied by vcc5v0_usb                              
[  162.740884] rockchip-pcie f8000000.pcie: no vpcie12v regulator found         
[  162.746764] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found         
[  162.750391] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found         
[  163.280713] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:  
[  163.284059] rockchip-pcie f8000000.pcie:   MEM 0xfa000000..0xfbdfffff -> 0xf0
[  163.286820] rockchip-pcie f8000000.pcie:    IO 0xfbe00000..0xfbefffff -> 0xf0
[  163.302884] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00      
[  163.305119] pci_bus 0000:00: root bus resource [bus 00-1f]                   
[  163.306968] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff]   
[  163.310027] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus add)
[  163.542130] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reg
[  163.560746] SError Interrupt on CPU5, code 0xbf000002 -- SError              
[  163.560932] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G             L    5.1.0-3
[  163.561051] Hardware name: Pine64 RockPro64 (DT)                             
[  163.561157] pstate: 60000085 (nZCv daIf -PAN -UAO)                           
[  163.561258] pc : rockchip_pcie_rd_conf+0x1e8/0x280                           
[  163.561356] lr : rockchip_pcie_rd_conf+0x214/0x280                           
[  163.561440] sp : ffff00001004b7f0                                            
[  163.561527] x29: ffff00001004b7f0 x28: 0000000000000000                      
[  163.561800] x27: 0000000000000000 x26: 0000000000000000                      
[  163.562047] x25: 0000000000000004 x24: ffff800004de13c0                      
[  163.562275] x23: 0000000000000000 x22: ffff8000f61d6800                      
[  163.562499] x21: ffff00001004b894 x20: 0000000000100000                      
[  163.562718] x19: 0000000000000000 x18: 0000000000000000                      
[  163.562936] x17: 00000000250ca3fe x16: 000000009ae7c865                      
[  163.563154] x15: ffffffffffffffff x14: ffff00001153d6c8                      
[  163.563374] x13: ffff8000ec3df91c x12: ffff8000ec3df190                      
[  163.563592] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f                      
[  163.563811] x9 : ff72646268756463 x8 : 00000000000003bd                      
[  163.564030] x7 : 0000000000000000 x6 : 0000000000000001                      
[  163.564248] x5 : ffff00001060f630 x4 : 0000000000000000                      
[  163.564466] x3 : 0000000000000000 x2 : 0000000000c00008                      
[  163.564686] x1 : ffff000017c00008 x0 : 0000000000000000                      
[  163.564961] Kernel panic - not syncing: Asynchronous SError Interrupt        
[  163.565098] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G             L    5.1.0-3
[  163.565196] Hardware name: Pine64 RockPro64 (DT)                             
[  163.565276] Call trace:                                                      
[  163.565367]  dump_backtrace+0x0/0x168                                        
[  163.565452]  show_stack+0x24/0x30                                            
[  163.565535]  dump_stack+0xac/0xd4                                            
[  163.565617]  panic+0x150/0x2e8                                               
[  163.565705]  __stack_chk_fail+0x0/0x28                                       
[  163.565798]  arm64_serror_panic+0x80/0x8c                                    
[  163.565884]  do_serror+0x11c/0x120                                           
[  163.565968]  el1_error+0x84/0xf8                                             
[  163.566064]  rockchip_pcie_rd_conf+0x1e8/0x280                               
[  163.566164]  pci_bus_read_config_dword+0xb8/0x108                            
[  163.566271]  pci_bus_generic_read_dev_vendor_id+0x40/0x1b8                   
[  163.566368]  pci_bus_read_dev_vendor_id+0x58/0x88                            
[  163.566464]  pci_scan_single_device+0x84/0xf8                                
[  163.566556]  pci_scan_slot+0x44/0x108                                        
[  163.566653]  pci_scan_child_bus_extend+0x5c/0x350                            
[  163.566749]  pci_scan_bridge_extend+0x37c/0x518                              
[  163.566849]  pci_scan_child_bus_extend+0x204/0x350                           
[  163.566945]  pci_scan_root_bus_bridge+0x60/0xd0                              
[  163.567042]  rockchip_pcie_probe+0x5ec/0x718                                 
[  163.567135]  platform_drv_probe+0x58/0xa8                                    
[  163.567223]  really_probe+0x1f0/0x3d8                   

I'm running latest Armbian Bionic on Pine64 RockPro64, trying to connect a Midi Keyboard device (having several of them for testing), but it is not recognized by ALSA. 

If I run 

acconnect -l

After connecting the keyboard, it's not listed (same behavior with different keyboards).  

Does anyone possibly knows what module might be missing in the kernel?

Thanks..

I got my RockPro64 board several days ago, and got *UPSTREAM* kernel (v5.1-rc5) and uboot (v2019.04) running on it using Archlinux ARM. (Sorry guys, I like upstream and Alarm more)

The pull request for uboot-rockpro64 can be found here:

https://github.com/archlinuxarm/PKGBUILDs/pull/1691

The upstream kernel is in the official core repor of Archlinuxarm (and that's why I like Alarm so much).

It boots and runs mostly OK on full upstream kernel/u-boot setup.

On rc-kernel it even has HDMI output working, but no hardware acceleration. I'm waiting panfrost as the open-source driver, so far it doesn't matter much as I don't plan to use it with X11/wayland anyway.

But it's awesome that you can just run GNOME3 on wayland, using llvmpipe.

And I even compiled mesa with panfrost natively on that board, so the future looks super bright.

However the biggest problem I hit is, upstream (5.0.8 and 5.1-rc5) kernel has random panic.

The panic itself is Async SError, and mostly happens for memory heavy operations (memtester and heavy file operations like checking out the whole kernel code).

The last panic I hit has no meaningful kernel calltrace, just el0_error_naked (user space triggered, and memtester is running)

At first I thought it's faulty ram, but when using the rockchip kernel from Armbian, it no longer crashes any more.

I have no clue what's going wrong, device tree? idbloader? trust.img? Uboot? Or just upstream kernel sucks? (I really hate to admit the last one)

Is there any upstream kernel precompiled in armbian for me to test so I could rule out one more problem?

Thanks.

https://github.com/chwe17/build/tree/rk3399merge

I would happily give it into 'someone others' hands cause time in the next month might be really rare.

Basically it needs testing on the boards which got newly merged into rockchip64 (don't own any nanopi *4 board so I can't test it). And probably a small helper script to adjust the 'living' boards config so that they'll get updates in the future from their new boardfamily (this might be tricky and needs for sure a lot of testing, to ensure we don't break them)

Would be nice if someone can review it and test it on the nanopis

I wanted preempt-rt kernel for my armbian rockpro64 so i have compiled and generated preempt-rt 4.4.167 deb kernel package.

I have installed my custom kernel deb package but after reboot the system boot in old kernel not the custom kernel.

How i can set the system to boot from custom installed kernel ?(4.4.167-rt176 is my custom kernel)

$ ls -a /boot
.                               boot.cmd                   dtb-4.4.174-rockchip64         System.map-4.4.174-rockchip64
..                              boot-desktop.png           Image                          uInitrd
armbianEnv.txt                  boot.scr                   initrd.img-4.4.167-rt176       uInitrd-4.4.167-rt176
armbianEnv.txt.out              config-4.4.167-rt176       initrd.img-4.4.174-rockchip64  uInitrd-4.4.174-rockchip64
armbian_first_run.txt.template  config-4.4.174-rockchip64  .next                          vmlinuz-4.4.167-rt176
boot.bmp                        dtb                        System.map-4.4.167-rt176       vmlinuz-4.4.174-rockchip64

Board start only without wifi & pcie. But i got this error.

https://pastebin.com/gq2DpXaF

Wondering if you could start support for rp64 or maybe update the wip since kernel has greatly improved.

https://daenney.github.io/2017/01/07/geoip-filtering-iptables.html

I got most of things work until getting problem on installing xtables-addons-dmks

# apt-get install --reinstall xtables-addons-dkms

------------------------------

Deleting module version: 2.12

completely from the DKMS tree.

------------------------------

Done.

Unpacking xtables-addons-dkms (2.12-0.1) over (2.12-0.1) ...

Setting up xtables-addons-dkms (2.12-0.1) ...

Loading new xtables-addons-2.12 DKMS files...

Building for 4.4.174-rk3399

Building initial module for 4.4.174-rk3399

Error! Build of xt_ACCOUNT.ko failed for: 4.4.174-rk3399 (aarch64)

Consult the make.log in the build directory

/var/lib/dkms/xtables-addons/2.12/build/ for more information.

# cat /var/lib/dkms/xtables-addons/2.12/build/make.log

DKMS make.log for xtables-addons-2.12 for kernel 4.4.174-rk3399 (aarch64)

Mon Mar 25 18:58:27 PDT 2019

make: Entering directory '/usr/src/linux-headers-4.4.174-rk3399'

Makefile:667: arch//Makefile: No such file or directory

make: *** No rule to make target 'arch//Makefile'. Stop.

make: Leaving directory '/usr/src/linux-headers-4.4.174-rk3399'

I have both kernel headers and source installed from armbian-config.

Any pointer to get correct commands to solve this problem would be appreciated. 

Thanks,

Just upgraded and after a reboot Armbian wont boot into desktop.

Xorg Looks good with no errors and I can see the kernel boot screen and log in via ssh.

If I disconnect and reconnect the HDMI I get the following ... but nothing appears on the monitor

[ 1733.805014] rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11

The screen remains on as it can detect the graphics display .... its just blank

what display manager does Armbian use ?

About a week ago, I was able to successfully build Armbian for RockPro64 in the standard Vagrant build environment, creating a bootable image using the compilation GUI without any special kernel configuration.

I tried again yesterday, both with the GUI and the CLI command below, but the build process always fails:

$ sudo ./compile.sh BOARD=rockpro64 PROGRESS_LOG_TO_FILE=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no RELEASE=stretch BUILD_DESKTOP=no BRANCH=default
...
CC [M]  drivers/net/wireless/rockchip_wlan/rtl8723bu/core/rtw_mp_ioctl.o
CC [M]  drivers/net/wireless/rockchip_wlan/rtl8723bu/core/rtw_bt_mp.o
LD [M]  drivers/net/wireless/rockchip_wlan/rtl8723bu/8723bu.o
LD      drivers/net/wireless/built-in.o
LD      drivers/net/built-in.o
LD      drivers/built-in.o
[ error ] ERROR in function compile_kernel [ compilation.sh:389 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated 

In the `compilation.log` there are two main errors. First example (occurs maybe 10+ times):

In file included from drivers/net/wireless/rockchip_wlan/mvl88w8977/mlan/mlan.h:32:0,
                 from drivers/net/wireless/rockchip_wlan/mvl88w8977/mlan/mlan_shim.c:26:
drivers/net/wireless/rockchip_wlan/mvl88w8977/mlan/mlan_ioctl.h:1797:1: note: offset of packed bit-field ‘MaxAMSDU’ has changed in GCC 4.4
 } MLAN_PACK_END ExtCap_t, *pExtCap_t;
 ^

Second example (occurs 50+ times):

In file included from ./arch/arm64/include/asm/compat.h:25:0,
                 from ./arch/arm64/include/asm/stat.h:23,
                 from include/linux/stat.h:5,
                 from include/linux/module.h:10,
                 from drivers/net/wireless/rtl8812au/include/basic_types.h:76,
                 from drivers/net/wireless/rtl8812au/include/drv_types.h:26,
                 from drivers/net/wireless/rtl8812au/core/rtw_cmd.c:17:
include/linux/sched.h:1211:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
 const struct sched_group_energy * const(*sched_domain_energy_f)(int cpu);
 ^~~~~
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’

Initially I was suspecting the virtualbox image, going back to the exact release I've been using last week (two updates from Vagrant since), but to no avail. After looking at Github issues, reading posts and sifting through the scripts, I got the build process working by explicitly using BRANCH="dev".

I am especially wondering why it worked wihtout issues a week ago, but not anymore. Any recent changes? Might this have something to do with these ongoing changes? In that regard, I'd rather expect the "dev" branch to fail than the default one.

Please find attached the various compilation.log files:

• compilation.log for BRANCH="default": https://pastebin.com/wMLiAHdA (compilation fails with error shown at the beginning)
• compilation.log for BRANCH="dev": https://pastebin.com/i5UXZZys (compilation successful)

I'm thankful for any insights or pointers to getting a stable RockPro64 image, as I'd like to later customize it with additional software (definitely not there yet).

i would like to know if there will be armbian stretch for rock64pro. I tried images on official website, but there are all with alot of buggs + they have everything messed up with user.

I need that clean new image for emmc card. I would start from basic debian stretch image, but i couldnt make it work with etcher.

p.s. sorry for my bad English, this is not my native language

Best regards, Bekim

rockpro64

Linux rockpro64 4.4.174-rockchip64 #16 SMP Sun Feb 10 16:50:35 CET 2019 aarch64 aarch64 aarch64 GNU/Linux

as root:

# btrfs qgroup show /   

--> ERROR: can't list qgroups: quotas not enabled     (thats not the problem)

but  a dmesg

BTRFS error (device sda1): could not find root 8

occurs ..

There is a old (2015) discussion about a missing group

(create a dedicated qgroup ioctl)

https://www.spinics.net/lists/linux-btrfs/msg49628.html

https://www.spinics.net/lists/linux-btrfs/msg49635.html

May you have a idea ?!

Best regards - and you make a great job!

Jean