Jump to content

ebin-dev

Members
  • Posts

    431
  • Joined

  • Last visited

Reputation Activity

  1. Like
    ebin-dev got a reaction from manman in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    There are new Armbian 24.05 images available on the Helios64 download page: both images Bookworm minimal and Jammy Desktop are based on linux 6.6.30 (download them !).
     
    Again, the rtl_nic firmware (in /lib/firmware/rtl_nic) should be replaced by the version downloaded from git.kernel.org, such that the 2.5G LAN interface works correctly.
     
    I would also recommend to copy the dtb attached below to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (execute 'update-initramfs -u' after that). It includes the 75mV bump of the opp states for the fast cores as suggested by @prahal, it enables the L2 cache info and it enables hs400 speed on emmc again. In particular the 75mV bump has a very positive effect on stability.
     
    The bootloader that comes with it would appear to contain the Rockchip DDR blob. It should be fine. If you have an issue with u-boot, just flash linux-u-boot-edge-helios64_22.02.1_arm64 as recommended before.
     
    The cpufreq ondemand governor is still the best choice. Good settings are
    # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand  
    Enjoy.
     
    P.S.: If you like a system more responsive to server tasks or push the 2.5G interface to the limits, some fine tuning is helpful.
     
    rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp
  2. Like
    ebin-dev got a reaction from Gammel in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Thanks for the initiative with the PR. 
     
    Here is what happens:
    The cpufreqpolicy sets a generic value for the sampling_rate of 200000 (this is how often the governor’s worker routine should run, in microseconds). The sampling_rate should be set to a nominal value close to the cpuinfo_transition_latency (49000 and 40000 nanoseconds for the clusters of rk3399) such that it is effectively about 1000 times as large. 
    For rk3399 boards the cluster sampling_rates of 49000 (big) and 40000 (little) are very responsive and not too demanding for the cpus. In that case no problems occur if io_is_busy is set to 1 !
     
    I added a comment to PR6507 and requested that the sampling_rate should be a parameter (per cpu cluster) and be set to the value of the cpuinfo_transition_latency of that cpu.
     
    The fine tuned values for Helios64 are those (io_is_busy set to 1 again, sampling_rate set to more responsive values):
     
    for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done  
    Edit: With these changes the timeout issues of the 2.5G interface are resolved for 6.6.29 and 6.6.30 too.
    Helios64 is one of the best arm based NAS systems I have seen so far. I am not going to replace it anytime soon.
  3. Like
    ebin-dev got a reaction from Gammel in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    It seems that the patches are still missing. Until this is fixed you can use my dtb attached for the kernel 6.6.x branch (just copy it to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb).
     
    The linux files (linux-image, linux-header, linux-dtb) can be downloaded from beta.armbian.com (to be installed with 'dpkg -i linux*). Copy the attached 6.6 dtb to its location and run 'update-initramfs -u' and reboot. Thats it.
     
     I am on 6.10.2 right now - I also include the dtb for the 6.10 branch below. 
     
    rk3399-kobol-helios64.dtb-6.6.34-L2-hs400-opp
    rk3399-kobol-helios64.dtb-6.10.2-L2-hs400-opp
  4. Like
    ebin-dev got a reaction from TRS-80 in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    You may have noticed that Helios64 was moved to the supported section again about two weeks ago: thanks to @prahal who volunteers as a maintainer !
    I think this should be appreciated i.e. by reacting to his last message two postings earlier.
  5. Like
    ebin-dev got a reaction from snakekick in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    You may have noticed that Helios64 was moved to the supported section again about two weeks ago: thanks to @prahal who volunteers as a maintainer !
    I think this should be appreciated i.e. by reacting to his last message two postings earlier.
  6. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    @prahal Current kernel 6.9.6 works just fine on Helios64 (headless) thanks to your PR. I am still using linux-u-boot-edge-helios64_22.02.1_arm64.
     
    Level2 cache-info is now included:
    # lscpu -C NAME ONE-SIZE ALL-SIZE WAYS TYPE LEVEL SETS PHY-LINE COHERENCY-SIZE L1d 32K 192K 4 Data 1 128 64 L1i 32K 224K 2 Instruction 1 256 64 L2 512K 1.5M 16 Unified 2 512 64  
    The modified dtb (hs400,  modified opp-table-1) is attached below (copy to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb ; execute 'update-initramfs -u').
     
    P.S.: sata performance needs to be addressed and helios64-heartbeat-led.service is not working
    rk3399-kobol-helios64.dtb-6.9.6-L2-hs400-opp
  7. Like
    ebin-dev reacted to prahal in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Started work on syncing the helios64 dts to upstream for 6.9: https://github.com/prahal/build/tree/helios64-6.9 .
     
    I removed the overclock disabling patch as the overclock as it disables an overclock that is at least nowadays not in the included rk3399-opp.dtsi (ie cluster0 has no opp6 and cluster no opp8). It was not a high priority beforehand but as the helios64 dts starts to change, thus carries unnecessary work.
     
    The pachtset applies. The helios64 dts compile fine to dtb.
    Kernel built and booted. (see below for network connection, ie ethernet MAC fixup)
     
    There are not many functional changes on my side (there are in upstream dts). There are a few differences with upstream dts I did not bring as I don't know if they are leftover from the initial patch set or new fixups. But this could already have been an issue before 3.9 for most of these changes (there is at least a new upstream change 93b36e1d3748c352a70c69aa378715e6572e51d1  "arm64: dts: rockchip: Fix USB interface compatible string on kobol-helios64") I brought forward.
    I also brought in vcc3v0_sd node "enable-active-high;"  and "gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;".
     
     
    Beware.
    ethernet MAC change (now working as designed). The fact I kept the aliases from upstream fixes the ability for the eth0 (then renamed to end0 by armbian-hardware-optimization) ethernet mac - grabbed from OTP via SPI in u-boot to be applied. Thus if you bound the MAC address that was generated by the kernel instead of from the hardware to a host and IP, you will have to find the new IP assigned by the DHCP server to connect to the helios64.
    I believe this is fine for edge even if not for current (so should be good for 6.9?).
  8. Like
    ebin-dev got a reaction from snakekick in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Actually the changes to the dtb were figured out and were proposed by @prahal and therefore it would be up to Prahal to submit a PR.
     
    From my perspective there is nothing against a PR right now as the changes are sufficiently tested and have a very positive effect on stability.
  9. Like
    ebin-dev got a reaction from SIGSEGV in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Actually the changes to the dtb were figured out and were proposed by @prahal and therefore it would be up to Prahal to submit a PR.
     
    From my perspective there is nothing against a PR right now as the changes are sufficiently tested and have a very positive effect on stability.
  10. Like
    ebin-dev got a reaction from SIGSEGV in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    There are new Armbian 24.05 images available on the Helios64 download page: both images Bookworm minimal and Jammy Desktop are based on linux 6.6.30 (download them !).
     
    Again, the rtl_nic firmware (in /lib/firmware/rtl_nic) should be replaced by the version downloaded from git.kernel.org, such that the 2.5G LAN interface works correctly.
     
    I would also recommend to copy the dtb attached below to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (execute 'update-initramfs -u' after that). It includes the 75mV bump of the opp states for the fast cores as suggested by @prahal, it enables the L2 cache info and it enables hs400 speed on emmc again. In particular the 75mV bump has a very positive effect on stability.
     
    The bootloader that comes with it would appear to contain the Rockchip DDR blob. It should be fine. If you have an issue with u-boot, just flash linux-u-boot-edge-helios64_22.02.1_arm64 as recommended before.
     
    The cpufreq ondemand governor is still the best choice. Good settings are
    # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand  
    Enjoy.
     
    P.S.: If you like a system more responsive to server tasks or push the 2.5G interface to the limits, some fine tuning is helpful.
     
    rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp
  11. Like
    ebin-dev got a reaction from snakekick in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    There are new Armbian 24.05 images available on the Helios64 download page: both images Bookworm minimal and Jammy Desktop are based on linux 6.6.30 (download them !).
     
    Again, the rtl_nic firmware (in /lib/firmware/rtl_nic) should be replaced by the version downloaded from git.kernel.org, such that the 2.5G LAN interface works correctly.
     
    I would also recommend to copy the dtb attached below to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (execute 'update-initramfs -u' after that). It includes the 75mV bump of the opp states for the fast cores as suggested by @prahal, it enables the L2 cache info and it enables hs400 speed on emmc again. In particular the 75mV bump has a very positive effect on stability.
     
    The bootloader that comes with it would appear to contain the Rockchip DDR blob. It should be fine. If you have an issue with u-boot, just flash linux-u-boot-edge-helios64_22.02.1_arm64 as recommended before.
     
    The cpufreq ondemand governor is still the best choice. Good settings are
    # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand  
    Enjoy.
     
    P.S.: If you like a system more responsive to server tasks or push the 2.5G interface to the limits, some fine tuning is helpful.
     
    rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp
  12. Like
    ebin-dev got a reaction from SIGSEGV in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    TLDR;
    The dtb contains a 75 mV bump for all fast cores as suggested by @prahal. You can find the opp-table-1 in this thread above (posted April 19). Use device tree compiler 'dtc' to apply your own changes (link).
    The dtb further contains a fix that enables hs400 speed on emmc also proposed by prahal.
    There is also a change for providing L2 cache information (this is all explained in this post) - and there is also a note that 6.6.29 is stable with those modifications.
     
    However, 6.6.29 and 6.6.30 bugs me with frequent transmit queue timeouts while using the 2.5G interface (NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8584 ms). I could not find any combination of settings to get rid of this. Therefore I switched back to 6.6.8 - it works perfectly fine - absolutely no issues.
     
    I am on linux 6.6.30 with the following configuration were armbian-hardware-optimize.service is disabled and NAS performance is restored:
    (The transfer rate from Helios64 to a MacBook Pro is 280MByte/s using a 2.5G switch in between and a 2.5G USB-C Dongle (StarTech US2GC30 (rtl8156bg)) attached to the Mac)
     
    root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand root@helios64:~# cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done exit 0 root@helios64:~# systemctl disable armbian-hardware-optimize.service root@helios64:~# reboot Edit: 'sampling_rate' reduced, it was not responsive enough - now 49000 (big cores) and 40000 (little cores) in microseconds. The nominal value is the same as 'cpuinfo_transition_latency'.
     
    If you are happy with 6.6.29 or 6.6.30 go ahead. For your convenience I attach the modified dtbs.
    rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp
  13. Like
    ebin-dev got a reaction from lanefu in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    @SteeMan  I tested the latest changes in armbian-hardware-optimize with linux 6.6.8, 6.6.29 and 6.6.30 on a Helios64.
     
    The above cpufreqpolicy does not work if 'io_is_busy' is set to 1 on Helios64 at least if the 2.5G interface is used (transmit queue timeouts). In armbian-hardware-optimize (a-h-o) it is set to 1. It must be set to 0 (kernel default).  If the sampling_rate is set to a more responsive value of 50000 the issues vanish with io_is_busy set to 1.
     
    The optimizations for the 1G interface (eth0/end0) in the armbian script (see below) have the effect that those tasks are not performed in the NIC anymore (hardware) but on the CPUs in software. The effect is a huge additional load on the CPUs. Anyway such settings are not necessary with the new EEVDF scheduler anymore.
     
    The reason why I am disabling armbian-hardware-optimize is that I need a stable system and I want to avoid any random and untested changes on my system.
     
    echo 8 > /proc/irq/$(awk -F":" "/eth0/ {print \$1}" < /proc/interrupts | sed 's/\ //g')/smp_affinity echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 > /proc/sys/net/core/rps_sock_flow_entries echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt  
  14. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    A first test with linux 6.6.27 (downloaded from beta.armbian.com) was successful on my system too - even with the modifications (hs400 speed and cache awareness).
    (here is a link to the linux-6.6.27 debs downloaded today; I also attached modified dtbs for some kernel versions)
    dtbs.zip
  15. Like
    ebin-dev got a reaction from Trillien in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| 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'
     
    Edit: Meanwhile there is a more recent linux 6.6.30 (downloaded from beta.armbian.com on May 3rd), it is absolutely stable on my system if used in combination with a dtb (attached to this message) that implements a 75 mV bump for all states of the fast cores (as suggested by @prahal) (and additionally hs400 support and L2 cache information). Just copy the dtb to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb.
     
    ! 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  
    rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp
  16. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    The old files can of course be deleted in / , /boot , /usr/src , and in /lib/modules .
  17. Like
    ebin-dev got a reaction from magostinelli in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Depending on your use case try kernel 6.6.8, 6.1.71, and 5.15.93 (download links are provided here).
    Armbian built kernels 6.6.x (x>8) are all unstable.
  18. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    I am using the following script to transfer a system to another volume (in this case the running system to emmc) (UUIDs to be adapted to your case (sed -e 's/UUID=<from device>/UUID=<to device>/g' -i /mnt/emmc/etc/fstab)
     
    #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/emmc exec 2>&1 mount --uuid 7268e76f-3e1b-4e01-a6be-987654321098 /mnt/emmc rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/emmc # change fstab sed -e 's/UUID=b790c4d7-5709-4000-91ac-123456789012/UUID=7268e76f-3e1b-4e01-a6be-987654321098/g' -i /mnt/emmc/etc/fstab sed -e 's/UUID=b790c4d7-5709-4000-91ac-123456789012/UUID=7268e76f-3e1b-4e01-a6be-987654321098/g' -i /mnt/emmc/boot/armbianEnv.txt umount /mnt/emmc rm install-exclude echo "All done."  
    On top of that you may wish to manually rsync /var/log and /var/log.hdd to the other device.
    The segmentation fault is probably caused by the wrong bootloader on emmc. Armbian tools might overwrite it. So install again the recommended bootloader to emmc.
    Good luck.
     
  19. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    The uuids containing 'a6be' refer to the 'to device', the ones containing '91ac' refer to the 'from device'.
  20. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Why don't you flash linux-u-boot-edge-helios64_22.02.1_arm64 to both devices mmcblk0 and mmcblk1 and perform the python3 check after a cold start ?
     
    # messages output to the terminal while booting 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 ...  
  21. Like
    ebin-dev got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    Armbian bullseye images can be downloaded from the archive. And if you are having issues with OMV7 you should open another thread.
  22. Like
    ebin-dev got a reaction from snakekick in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    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
  23. Like
    ebin-dev got a reaction from snakekick in Helios64 u-boot does not build anymore after we bumped to 2022.07   
    @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).
  24. Like
    ebin-dev got a reaction from hartraft in Does upgrading from Buster to Bullseye still break the system?   
    @mrjpaxton Dist-upgrade(ing) from bullseye to bookworm did finally complete successfully. However, one should consider that device names have changed (otherwise your system may end up offline 🙂) the new interface names are:
     
    # interface names (bookworm) sd: /dev/mmcblk0 emmc: /dev/mmcblk1 eth0: end0 (1GBase-T ethernet) eth1: end1 (2.5GBase-T ethernet)  
    P.S.: I am currently setting up bookworm from scratch starting from the fresh image to get rid of the stuff that accumulated during the last years.
  25. Like
    ebin-dev reacted to prahal in Helios64 u-boot does not build anymore after we bumped to 2022.07   
    PR https://github.com/armbian/build/pull/4480
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines