ebin-dev

I tried armbian built 6.7.4 without any modifications but it crashes almost immediately on my system. Even without hs400. The netdev watchdog message looks like the timeout caused by the mainline r8152 driver. Have never seen those events occurring before 'cut here'.

May be it is not a fault but an upstream change that leads to issues with hs400 again ? Good to hear that 6.7.x is quite stable. The remaining issue (short timeout) with the mainline r8152 driver can be reduced (eliminated) if other huge tasks do not have to compete with it. You could use taskset to assign other huge tasks to cpu5 and leave cpu4 to handle i/o.

I copied the 6.7.2 deb files yesterday (trunk-480) and will test them once I am back home next week. 6.1.71 or 5.15.93 should be fine. You could also try 6.7.2 🙂

The 6.6.8 debs were downloaded from an Armbian mirror and are not modified. Everything you need is explained here: in particular that NFS causes trouble with 6.6.x kernels and that 6.1.71 should be used instead or 5.15.93. To implement hs400 and L2 cache information you can use 'dtc'. For your convenience I attached the dtb for 6.6.8 and 5.15.93 (just copy the matching one to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb). It is essential to flash the bootloader to emmc after you have installed the kernel debs, to perform a cold boot and to run 'sbc-bench -r' at least once. rk3399-kobol-helios64.dtb-5.15.93-L2-hs400 rk3399-kobol-helios64.dtb-6.6.8-L2-hs400

Newer kernel versions of the 6.6 branch (6.6.9 to 6.6.12) would not appear to run stable anymore on helios64 (6.6.8 is stable - using the ondemand governor in my use case). In kernel versions 6.6.9 to 6.6.12 energy aware scheduling (EAS) is disabled automatically - it can now only be used combination with the schedutil governor. But using schedutil is currently not a good option.

Bumping rockchip64 current to linux 6.6 (and edge to 6.7) is actually good news. But I do not think that this explains why the entire beta/pool/main folder disappeared from a mirror (but it does not matter). If nothing else is changed (keep fingers crossed), then the new Armbian built rockchip64 6.6.x and 6.7.y kernels should appear i.e. on imola.armbian.com/beta/pool/main/l/ and reappear on the mirrors.

Just to let you know: the directory 'beta/pool/main/l/linux-6.6.8/' has vanished over night (actually the entire folder fi.mirror.armbian.de/beta/pool/main). This was the location we used for downloading linux 6.6.x (6.1.y etc.) (kernel, dtb and headers). My link to the linux 6.6.8 files in this forum (as downloaded on 23.12.2023) remains active - also added links to linux 6.1.71 and 5.15.93 (dropbox).

@prahal So I used the opportunity to fix the settings for the 1G interface in armbian-hardware-optimization: My /etc/armbian-release states BOARDFAMILY=rk3399, Branch=current and I therefore edited the lines starting at line 251 - and that was successful. But I do not know if there is any positive effect on the 1G interface, since I am using 2.5G only. (I will go through the settings in /sys/class/net/end1 and see if something can be tuned for the 2.5G interface.) # cat /etc/armbian-release BOARD=helios64 BOARD_NAME="Helios64" BOARDFAMILY=rk3399 ... BRANCH=current #cat /usr/lib/armbian/armbian-hardware-optimization lines 251 ff: echo 8 > /proc/irq/$(awk -F":" "/end0/ {print \$1}" < /proc/interrupts | sed 's/\ //g')/smp_affinity echo 7 > /sys/class/net/end0/queues/rx-0/rps_cpus echo 32768 > /proc/sys/net/core/rps_sock_flow_entries echo 32768 > /sys/class/net/end0/queues/rx-0/rps_flow_cnt # systemctl status armbian-hardware-optimize.service ● armbian-hardware-optimize.service - Armbian hardware optimization Loaded: loaded (/lib/systemd/system/armbian-hardware-optimize.service; enabled; preset: enabled) Active: active (exited) since Fri 2024-01-12 15:49:01 CET; 33min ago Process: 700 ExecStart=/usr/lib/armbian/armbian-hardware-optimization start (code=exited, status=0/SUCCESS) Main PID: 700 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4374) Memory: 2.1M CPU: 795ms CGroup: /system.slice/armbian-hardware-optimize.service I do not know if the following information is correct: # dpkg -l armbian-bsp-cli-helios64-* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-================================-=========================================-============-===================================================== hi armbian-bsp-cli-helios64-current 23.08.0-trunk--1-PCc73b-Vccab-H1d04-B9c45 arm64 Armbian CLI BSP for board 'helios64' branch 'current'

That is true - in that script eth0 should be replaced by end0 if you wish to apply the Armbian optimisation to the 1G interface. The interrupt for xhci-hcd:usb1 devices is 46 and smb affinity is set to 10 (cpu4) on my system (used by the 2.5G interface): # cat /proc/irq/46/smp_affinity 10 # cat /proc/interrupts | grep xhci 46: 1481 0 261 0 998993 0 GICv3 142 Level xhci-hcd:usb1 93: 0 0 0 0 0 0 GICv3 137 Level dwc3-otg, xhci-hcd:usb5 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5

@prahal There are many values to choose from between 1000 and 40000 (regulator-ramp-delay). Why don't you try 2000, 4000, 10000, 20000 ? (It might solve your problem)

The purpose of the 'armbian-hardware-optimization' is to bind the heavy tasks to one or both big core(s), since the little ones would not be capable of dealing with them. For some heavy tasks the kernel may need more than one big core. So I think this would make sense. Cryptosetup on a raid 5 with 5 spinning disks is definitely a huge load. Dealing with the ethernet traffic on the 2.5G interface is also a heavy load: 280Mbyts/s have to be handled in pieces of 1500bytes (MTU) - simultaneously in both directions. So it might make some sense if you modify the optimization settings depending on your use case.

This is very interesting. For regulator vdd_cpu_b, 'regulator-ramp-delay' is still set to decimal 40000 in the current dtb (6.6.8). You could try reduce that number in your dtb to increase the delay until your frequency switching program finishes its task. If the resulting value is large enough for your cpu to still respond quickly enough to tasks scheduled then you could have eliminated a source of instability. Since kernel 6.6.8 uses a more efficient scheduler you could use that one for your experiments. I actually do not think that the Kobol Team was mistaken: in their commit it is stated that the 'existing value make clock transisition time large and could causing random kernel crash'. Therefore the regulator-ramp-delay was increased from decimal 1000 to 40000 thereby decreasing the clock transition time. This was a step in the right direction - may be that one was too large ...

The r8152 driver is using xhci-hcd. The above code assigns cpu4 to those processes (echo 10 ...). I tried to assign cpu4 and cpu5 to xhci processes (echo 30) and to assign only cpu5 to ahci (sata) (echo 20), but nic offloading turned out to be more beneficial. P.S.: I am not using RAID to keep it simple (but I maintain at least 4 separate backups). The file system itself also has some impact ext4 -> btrfs -> zfs.

Thank you for trying - also very useful for others. Are you running something demanding for the hardware ? I will stay with 6.6.8 since it is 100 % stable in my use case.

@prahal It would appear that your system has some kind of hardware issue if it is not stable with linux-u-boot-edge-helios64_22.02.1_arm64.deb and kernel 5.15.93. In my use-case it is stable even with kernel 6.6.8. Regarding testing a potentially corrupt Armbian built u-boot: I am a bit reluctant to such endeavors. Helios64 is used 24/7 (by 5 people) and is not easily accessible (stored away in a rack somewhere in the basement). May be someone else could do the u-boot testing (the board on a desk would be useful) ? Otherwise I could give it a try in about 4 weeks time after I returned from some planned absence. Regarding the crash-test switching cpu frequencies: my system died after switching cpu frequencies about 580 times (in less than a second), with linux-u-boot-edge-helios64_22.02.1_arm64.deb on kernel 6.6.8 (see the attached log). Looking at the output of cpufreq-info it can be seen which cpu-frequency states are used most often. My system normally almost exclusively jumps between 600MHz <-> 1.8GHz (big cores) and between 408MHz <-> 600MHz or between 400MHz <-> 1.42GHz (little cores). The only thing I did in that context was running sbc-bench -r which supposedly changed some performance related settings permanently. I think that omitting the intermediate states reduces switching between states and thus enhances responsiveness and stability while reducing the burden on the scheduler. I don't know if this helps, but I attached the cpu frequency transition tables for cpu5 and cpu0 (after about 3h uptime) # cat /sys/devices/system/cpu/cpu5/cpufreq/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 408000: 0 0 0 0 0 0 0 0 600000: 0 0 140 13 7 7 1 1126 816000: 0 130 0 13 3 1 2 48 1008000: 0 15 18 0 4 2 2 1 1200000: 0 5 6 7 0 9 3 7 1416000: 0 3 3 4 10 0 15 9 1608000: 0 2 1 1 8 18 0 18 1800000: 0 1139 29 4 5 7 25 0 # cat /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 408000: 0 1133 14 9 3 1002 600000: 1081 0 5 3 2 134 816000: 12 6 0 46 3 10 1008000: 7 2 44 0 11 21 1200000: 1 4 6 17 0 28 1416000: 1061 79 8 10 37 0 cpufreq-switching-2-b.log

Good news! Did you modify the dtb to support emmc hs400 speed and l2-cache information ? It would be nice if you could also try the 6.1.70 kernel.

@prahal Linux 6.6.8 and linux-u-boot-edge-helios64_22.02.1_arm64 is used since December 23rd without any Linux oops (despite the NETDEV Watchdog having to reset occasionally the mainline r8152 driver during iperf3 stress tests - but not during operation). @alchemist observed however, that NFS causes issues with 6.6.8 but not with 6.1.70 but that would not appear to be Helios64 specific. My use case: 24/7 as a DNS server, file server, nextcloud server, music server, plex server, and for home automation - kept everything simple (i.e. ext4 file system, no NFS).

Which u-boot version do you refer to (the one including pull requests from @prahal) ? P.S.: I included a note that in case you use NFS, kernel 6.1.70 should be used.

@OdyX After executing sbc-bench I switched the governor back to ondemand. I never had issues with it. You may try schedutil too. I added a download link (above in this thread) to the dtb enhanced with hs400 and l2 cache information (for linux 6.6.8). You can safely copy it to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb. Difficult to say if 'linux-cpupower' caused that trouble. # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

In my use case there are no issues so far - using it 24/7 as a DNS server, file server, nextcloud server, music server, plex server, and for home automation. I kept everything simple (i.e. ext4 file system, no NFS). @OdyX The undocumented errors you describe are hard to believe. If your system really behaves like that you should consider to donate your board for testing and buy something else. Otherwise: flash u-boot version 21.08.9. If that does not help, you can easily change the linux kernel: try 5.15.93. Just install linux-image, linux-headers, linux-dtb with dpkg -i linux* and do not forget to delete the remaining 6.6.8 links from / and from /boot. And make sure that you have the right u-boot flashed to emmc.

Did you add 'vendor:device:u' to usbstoragequirks in /boot/armbianEnv.txt ? (here is why this might help) Edit: example with 4 external sata hdds bridged with JMicron 578 (usbstoragequirks=152d:0578:u) # dmesg | grep 2-1.3 [ 2.544431] usb 2-1.3: new SuperSpeed USB device number 3 using xhci-hcd [ 2.565982] usb 2-1.3: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 3.01 [ 2.566017] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.566035] usb 2-1.3: Product: External HDD [ 2.566049] usb 2-1.3: Manufacturer: External USB3.0 [ 2.566062] usb 2-1.3: SerialNumber: 0000007788FC [ 2.567670] usb-storage 2-1.3:1.0: USB Mass Storage device detected [ 2.568719] usb-storage 2-1.3:1.0: Quirks match for vid 152d pid 0578: 1000000 [ 2.569099] scsi host0: usb-storage 2-1.3:1.0 [ 122.172373] usb 2-1.3: USB disconnect, device number 3

Not so easy: Helios64 is installed in a 10" rack in the basement 2m above the floor (so that it can't be easily accessed) and it is frequently used by all my family members 🙂. Current bootloader (linux-u-boot-edge-helios64_22.02.1_arm64.deb): DDR Version 1.25 20210517 In soft reset SRX channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1 Release Time: May 29 2020 17:36:36, version: 1.26 CPUId = 0x0 ChipType = 0x10, 449 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 69151 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3335db8 signature is wrong recovery gpt... GPT 0x3335db8 signature is wrong recovery gpt fail! Trust Addr:0x4000, 0x58334c42 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xea92c RunBL31 0x40000 @ 97786 us NOTICE: BL31: v1.3(release):845ee93 NOTICE: BL31: Built : 15:51:11, Jul 22 2020 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1196): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2021.07-armbian (Feb 27 2022 - 08:44:53 +0000) SoC: Rockchip rk3399 Reset cause: RST DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment If you could point me towards a version of a current u-boot that was built taking into account your recent pull requests, I will give it another try.

The only real issue I had was the r8152 driver for the 2.5G interface. Under load the mainline r8152 driver was reset by the NETDEV Watchdog - more or less often: If I use linux-u-boot-edge-helios64_22.02.1_arm64.deb to boot from emmc I do not observe any problems anymore (see the parallel thread). I assume that the rockchip DDR blob is used. However using the latest u-boot the mainline r8152 driver was reset multiple times during a single download. May be that version still does not contain the rockchip DDR blob...

_ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 23.11.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 System load: 2% Up time: 1:01 Memory usage: 31% of 3.71G IP: 192.168.xx.yy CPU temp: 46°C Usage of /: 49% of 15G storage/: 62% of 3.6T storage temp: 23°C So finally I arrived at a stable Armbian Bookworm configuration for Helios64: Starting from Armbian Bookworm image (Armbian_23.5.4_Helios64_bookworm_current_6.1.36) Disable Armbian updates in /etc/apt/sources.list.d/armbian.list Copy rtl_nic firmware to /lib/firmware/rtl_nic Upgrade kernel to linux-6.6.8 # download link to those debs downloaded 23.12.2023. (Edit: there would appear to be issues with NFS if you use linux 6.6.8 - use linux 6.1.71 in that case; if you still have issues, use linux 5.15.93) Flash u-boot to emmc (linux-u-boot-edge-helios64_22.02.1_arm64) # see here Set nic offload options (ethtool -K end1 tso on gso on gro on) # change 'end1' to your network interface name Apply any changes to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (hs400 support, L2 cache information) # download link for your convenience Execute 'sbc-bench -r' at least once; you may change the cpu governor in /etc/default/cpufrequtils to 'ondemand' ! If you intend to use the 2.5G interface you need to fix the hardware issue first ! # Even if the 2.5G port is connected to a 2.5G switch, interface speed is 1G during autonegotiation for some time ... With this configuration iperf3 measures 2.33 Gb/s transferred from/to the server (one-way), while in bidirectional mode 2x1.71Gb/s are transferred (simultaneously in both directions): # ./iperf3 -c 192.168.xx.yy -p 5201 Connecting to host 192.168.xx.yy, port 5201 [ 6] local 192.168.xx.zz port 55582 connected to 192.168.xx.yy port 5201 [ ID] Interval Transfer Bitrate [ 6] 0.00-1.01 sec 258 MBytes 2.15 Gbits/sec [ 6] 1.01-2.01 sec 282 MBytes 2.36 Gbits/sec [ 6] 2.01-3.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 3.01-4.01 sec 281 MBytes 2.35 Gbits/sec [ 6] 4.01-5.01 sec 280 MBytes 2.35 Gbits/sec [ 6] 5.01-6.01 sec 281 MBytes 2.36 Gbits/sec [ 6] 6.01-7.01 sec 281 MBytes 2.36 Gbits/sec [ 6] 7.01-8.00 sec 279 MBytes 2.35 Gbits/sec [ 6] 8.00-9.01 sec 281 MBytes 2.35 Gbits/sec [ 6] 9.01-10.01 sec 280 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-10.01 sec 2.72 GBytes 2.33 Gbits/sec sender [ 6] 0.00-10.01 sec 2.72 GBytes 2.33 Gbits/sec receiver iperf Done. # ./iperf3 -c 192.168.xx.yy -p 5201 -R Connecting to host 192.168.xx.yy, port 5201 Reverse mode, remote host 192.168.xx.yy is sending [ 6] local 192.168.xx.zz port 55588 connected to 192.168.xx.yy port 5201 [ ID] Interval Transfer Bitrate [ 6] 0.00-1.01 sec 262 MBytes 2.18 Gbits/sec [ 6] 1.01-2.00 sec 278 MBytes 2.34 Gbits/sec [ 6] 2.00-3.01 sec 280 MBytes 2.35 Gbits/sec [ 6] 3.01-4.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 4.01-5.00 sec 278 MBytes 2.34 Gbits/sec [ 6] 5.00-6.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 6.01-7.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 7.01-8.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 8.01-9.01 sec 279 MBytes 2.34 Gbits/sec [ 6] 9.01-10.01 sec 278 MBytes 2.34 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 6] 0.00-10.01 sec 2.71 GBytes 2.33 Gbits/sec 53 sender [ 6] 0.00-10.01 sec 2.71 GBytes 2.33 Gbits/sec receiver iperf Done. # ./iperf3 -c 192.168.xx.yy -p 5201 --bidir Connecting to host 192.168.xx.yy, port 5201 [ 6] local 192.168.xx.zz port 55599 connected to 192.168.xx.yy port 5201 [ 8] local 192.168.xx.zz port 55600 connected to 192.168.xx.yy port 5201 [ ID][Role] Interval Transfer Bitrate [ 6][TX-C] 0.00-1.01 sec 221 MBytes 1.84 Gbits/sec [ 8][RX-C] 0.00-1.01 sec 193 MBytes 1.61 Gbits/sec [ 6][TX-C] 1.01-2.01 sec 166 MBytes 1.39 Gbits/sec [ 8][RX-C] 1.01-2.01 sec 215 MBytes 1.80 Gbits/sec [ 6][TX-C] 2.01-3.01 sec 214 MBytes 1.80 Gbits/sec [ 8][RX-C] 2.01-3.01 sec 198 MBytes 1.67 Gbits/sec [ 6][TX-C] 3.01-4.01 sec 235 MBytes 1.97 Gbits/sec [ 8][RX-C] 3.01-4.01 sec 197 MBytes 1.66 Gbits/sec [ 6][TX-C] 4.01-5.01 sec 222 MBytes 1.87 Gbits/sec [ 8][RX-C] 4.01-5.01 sec 197 MBytes 1.65 Gbits/sec [ 6][TX-C] 5.01-6.01 sec 194 MBytes 1.63 Gbits/sec [ 8][RX-C] 5.01-6.01 sec 210 MBytes 1.76 Gbits/sec [ 6][TX-C] 6.01-7.00 sec 184 MBytes 1.54 Gbits/sec [ 8][RX-C] 6.01-7.00 sec 212 MBytes 1.78 Gbits/sec [ 6][TX-C] 7.00-8.01 sec 192 MBytes 1.61 Gbits/sec [ 8][RX-C] 7.00-8.01 sec 208 MBytes 1.75 Gbits/sec [ 6][TX-C] 8.01-9.01 sec 216 MBytes 1.81 Gbits/sec [ 8][RX-C] 8.01-9.01 sec 203 MBytes 1.70 Gbits/sec [ 6][TX-C] 9.01-10.01 sec 206 MBytes 1.73 Gbits/sec [ 8][RX-C] 9.01-10.01 sec 204 MBytes 1.71 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 6][TX-C] 0.00-10.01 sec 2.00 GBytes 1.72 Gbits/sec sender [ 6][TX-C] 0.00-10.01 sec 2.00 GBytes 1.72 Gbits/sec receiver [ 8][RX-C] 0.00-10.01 sec 1.99 GBytes 1.71 Gbits/sec 17 sender [ 8][RX-C] 0.00-10.01 sec 1.99 GBytes 1.71 Gbits/sec receiver iperf Done. # hdparm -tT /dev/mmcblk1 /dev/mmcblk1: Timing cached reads: 2986 MB in 2.00 seconds = 1493.93 MB/sec Timing buffered disk reads: 706 MB in 3.00 seconds = 235.11 MB/sec # lscpu -C NAME ONE-SIZE ALL-SIZE WAYS TYPE LEVEL SETS PHY-LINE COHERENCY-SIZE L1d Data 1 L1i Instruction 1 L2 Unified 2

@prahal Current helios64-u-boot-edge (2023-Dec-28 08:32) is supposed to include the rockchip DDR blob, but unfortunately stable operation of helios64 is still not possible with it: the r8152 is reset very frequently if this bootloader is used (contrary to linux-u-boot-edge-helios64_22.02.1_arm64.deb, were the r8152 is reset only occasionally under load).