Jump to content

Search the Community

Showing results for tags 'rockpro64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • Upcoming Hardware
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families


  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL







  1. 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?
  2. 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.
  3. 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?
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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 -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, port 5201 Cookie: ARNAUD-PC.1692436606.019644.1e8c9a9b [ 4] local port 64985 connected to 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, port 44317 Cookie: ARNAUD-PC.1692436606.019644.1e8c9a9b [ 5] local port 5201 connected to 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 .
  9. 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.
  10. 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:
  11. 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 (0.ubuntu.pool.ntp.org)
  12. 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
  13. 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?
  14. 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?
  15. Hello, I would like to know more informations about this test made with the Asus XG-C100C Network Adapter or, generally, how to optimize the speed from a 10GbE PCIe Network Adapter in the RockPro64. Which version to use of Armbian and how to get that version to have so good performances? Which version of the Adapter driver to use? Were the drivers included in the Kernel or did you use the Asus driver recompiled? I would be very grateful if you will help me. Thank you.
  16. Hello! 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.)
  17. armbian-config has a way to update the kernel within a major version but can one upgrade from 5.15 to 6.1 (current/edge). I assume if not then I have to build my own image? What I am after is jammy or bullseye with 6.1 kernel to support some hardware not supported in 5.15. I know the rolling releases (Lunar/Sid) have this kernel but I need a LTS release with 6.1.
  18. I've got jammy running but I have a dsi display for the board and I'd like that to work (well the tp port too) with jammy. Looking at armbian config I see no setting for it. I know the display works fine as if I load an aryufan android image it works as it is set to use DSI by default. 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?
  19. Hello, I've installed the 22.11 version with the 5.15 kernel on the microSD card. 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,
  20. Dear Armbian community, 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.
  21. is it possible to get edp on rockpro64 working with armbian
  22. 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)?
  23. Hi guys 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!
  24. Im looking for a functioning, easy to install fan script for my RockPro64 installed with Armbian Jammy. 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.
  25. I'm trying to get this rockpro64 board to boot off of pxe/nfs. I'm able to get it to boot into armbian and to the point where it asks for the new root password. But something happens on the device where the network gets disabled which stops the NFS connectivity and the rest of the system with it. All traffic stops on the device and it becomes unreachable. NFS traffic stops, it no longer responds to pings, etc. It's not entirely frozen, for example it prints kernel messages to console if the ethernet is pulled. And after a few minutes the nfs connection times out and it starts printing this over and over. It always happens about 75 seconds after boot. It leads me to think there's some job or process that's running on the base OS install that somehow interrupts the connection. this is the pxe config file I'm using. and I'm using the current bullseye server image from Aug 31, 2022 default l0 menu title U-Boot menu prompt 0 timeout 50 label 10 menu default kernel root/boot/Image fdt root/boot/dtb/rockchip/rk3399-rockpro64.dtb initrd root/boot/uInitrd append loglevel=8 root=/dev/nfs ip=dhcp rootwait rw earlyprintk nfsroot=
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines