Jump to content

Search the Community

Showing results for tags 'rockpro64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

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

Product Groups

  • Misc
  • Support

Categories

  • Armbian
  • Armbian releases

Categories

  • Volunteering opportunities

Calendars

  • Community Calendar

Categories

  • Members

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. 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.
  2. 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?
  3. 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
  4. 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>
  5. 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
  6. 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
  7. 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
  8. 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?
  9. 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.
  10. 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?
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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 .
  16. Myy

    Mainline VPU

    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.
  17. 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:
  18. 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)
  19. 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
  20. 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?
  21. 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?
  22. 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.
  23. 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.)
  24. 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.
  25. 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?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines