Search the Community

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.

I have had major problems trying to use spidev on the pine RockPro64 SBC running Armbian_24.2.1_Rockpro64_jammy_current_6.6.16_xfce. I have posted these comments on the pine.org forum also. I think there is a problem with the spidev device in Armbian as it never toggles the CS line. When I controlled the CS line from my software, I could communicate, but the received data was wrong. I have no experience with the device tree, but I suspect an isue therein. To bypass the problem I wrote a bitbang routine and it works fine and gives the correct data. See the attached file for my discussion. usingspi.txt

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?

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

my Helios64 Board is now so unstable -- it on its own isn't worth putting in more of my time... but the rest of the NAS system "seems" fine -- so is there anything I can replace the logic board with ?? are there any "working" boards to be purchased anywhere? I've looked all over and the board "seems" close to the tinkerboard but I don't think it is one. I believe that it was a custom build. anyone else just try to replace the board and move on? Rich Leonard

@SteeMan the thing is I have a RockPro64 and the only way to get DP alt-mode working on the USB-C port is on the 4.4 kernel which isn't supported by newer versions. Is there any backup repo for buster? Thanks

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?

Hi guys. 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>

Hi, 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

Hello , looking to upgrade from SBC Rock64 to RockPro64< however, on the homepage it is mentioned, that https://wiki.pine64.org/wiki/ROCKPro64_Software_Releases 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

Hi, I use Helios64 from the begin and this board is very unstable according to my experience and many posts here... After many dialogue here and settings shared about Frequency and Governor Kernel... maybe i find the problem and i ask anyone return of experiences about the procedure and setting belong: - Connect USB Wireless Dongle or USB(-c) Ethernet Plug - Configure it - Disconnect all ethernet cable to the board - Use with last time crash configuration and do a endurance test your helios64 board Have a good day

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 haven't touched my ROCKPro64 for quite a while. Pulled it out today and starting playing with it. 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.

Running Armbian 23.8.1 Jammy CLI Minimal. Since my kernel updated to 6.1 I have been having serious stability issues. Uptime is somewhere between 3 and 24 hours before the system becomes completely unresponsive. Prior to the 6.1 update this system was rock solid and would be up for months at a time, only ever rebooted for kernel updates. 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

Hi to all, 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, 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 .

Hi all. I have a Rockpro64 with u-boot flashed to SPI, and Armbian installed to NVMe drive*. When I use the HDMI port on the Rock to a standard HDMI port on a monitor, everything displays without issue. But recently I tried connecting to a Viewsonic va1655 using the HDMI to mini-HDMI cable, and the monitor displays fine while U-boot is doing its thing. But right before Armbian loads, the Viewsonic monitor flashes yellowish orange and then completely loses the signal. Buuut if I unplug the VS monitor and plug in the other HDMI monitor to the rock, the image is restored and Mr. Tux is patiently waiting for me to enter my password. *I'm not sure if this matters, but I used armbian-config to install bootloader on the nvme:

This has happened now on identical brand new boards, new EMMCs, also on SD, identical 5a factory PSU, factory heatsink. OS is Armbian, and it has happened on current desktop and server. This last time I had completed several successful reboots and thought maybe I just hadn't been pushing the plug in all the way. Then it happened again. Prior attempts have been on EMMC, directly burned with Etcher, and brand new Sandisk Ultra in package with bubble. The behavior is while the board is running, white light flashing, system munching it just dies. Throws no errors. Just quits. Green light never goes out. I was tailing the emby log when it crashed this time. No errors at all. Prior times it did not successfully reboot, but this one seems to be ok on reboot. As I have been running Armbian for over 5 years on dozens of boards, this does not seem to be an Armbian problem, despite customer service at Pine claiming that this is a software issue. I have followed this exact same process on boards from Rpi2 and Opi PC to other RK3399 boards like NanoM4v2. Not one has failed. I am writing a book on NAS options (for people who don't actually know anything like me), so this is really relevant to the RP64. I personally bought two boards and NAS boxes and the card and everything. Something is going on, and it is for sure hardware related. This last crash was using an EMMC I got from Hardkernel years ago, and was unused. It seems like there was an issue with the 5 kernels at some point, but there are no notes about it in the current download page, and there are no links to legacy images. 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)

Hi all, In armbian-config I have freeze on firmware. I can see that armbian-firmware-full is kept back. Still my kernel got updated. Kind of an issue as I use zfs (backports) on my omv install and I need to reinstall them to get the module recreated... Now I have a few questions: Is it because I have only armbian-firmware-full held back, and apt works in my case maybe with armbian-firmware? (Or do I misinterpret the list that says upgradable on the full) Or do I have to hold the specific versioned packages and will the armbian-firmware (meta?) package hold not work on the ones I have installed and get upgraded nonetheless? Tia

I am trying to use a tpm module that attaches to GPIO pins and uses SPI. The manufacturer provides examples that use overlays from Raspbian, and those overlays seem to reference infineon and slb9670, neither of which I can find in armbian source. Anyone know if there is a way to enable SPI tpm?

First off this is not a Rockpro64 it is a Rock64 Ver. 2 which the tags field would not let me enter. A couple years ago when I first started playing with the Rock64, I briefly used armbian as the OS. The flickering video was annoying so later I tried Manjaro which worked fairly well. Recently the (Manjaro/Arch) updates (as well as latest images) completely break the HDMI output. Since the system was rendered usless, I downloaded the latest Armbian Jammy hoping for better results. The image loaded from SD fine, I did updates manually fine, and it rebooted fine. The only problem I experience is that that anoying HDMI video flicker. It's worse when there is any system activity, IE: if the mouse is rolled over an Icon, or if that icon is clicked, the screen becomes a blur of random horizontal lines as the screen jumps. I've looked but havn't found a comprehensive solution to this issue; much of what is out there is "old news" can anyone steer me in the right direction to fix this?