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'S FINALLY HERE... THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons). I. Installation Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es". II. Features Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K). - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV. ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed. III. Sources This is the list of the sources used for the packages: IV. FAQ ¿Why did you use Debian Buster as a base for this implementation? It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal. ¿Why Legacy instead of Mainline? This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels. ¿Will you add new features to this implementation? No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

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

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

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 .

So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason. Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something. The patches applied are here : https://github.com/Miouyouyou/RockMyy64 If someone wants to play with them and determine which one break the boot process.

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: