Skip to content

ROCKPro64 - Armbian - Schnelltest 5.75 Debian Stretch

Armbian
  • Nachdem jetzt wieder was Zeit vergangen ist, mach ich mal einen Schnelltest der Armbian Version 5.75 mit Debian Stretch.
    SD-Karte geflasht, gestartet und nix ging. Moment, da fällt mir ein, meine Version auf dem NAS ist was älter. PCIe NVMe SSD entfernt und es startet. Aber mal von vorne...

    Hardware

    • ROCKPro64 v2.1 mit 2GB RAM
    • WiFi-Modul
    • PCIe NVMe SSD

    Software

    Armbian_5.75_Rockpro64_Debian_stretch_default_4.4.174.img
    

    Test

    Beim ersten Start mit WiFi-Modul und PCIe-Karte findet er kein bootbares Image!? Bitte den Hinweis oben beachten, evt. war meine Version zu alt. Aber da es jetzt gestartet war, konnten wir es einfach mal auf die Nightly Build Version bringen.

    armbian-config
    

    Dann "System" danach "Nightly" auswählen. Dann holt er sich alle aktualisierten Pakete.

    reboot
    

    Danach sind wir auf dem aktuellen Stand.

    frank@frank-MS-7A34:~$ ssh root@192.168.178.32
    root@192.168.178.32's password: 
     ____            _    ____               __   _  _   
    |  _ \ ___   ___| | _|  _ \ _ __ ___    / /_ | || |  
    | |_) / _ \ / __| |/ / |_) | '__/ _ \  | '_ \| || |_ 
    |  _ < (_) | (__|   <|  __/| | | (_) | | (_) |__   _|
    |_| \_\___/ \___|_|\_\_|   |_|  \___/   \___/   |_|  
                                                         
    
    Welcome to ARMBIAN 5.77.190404 nightly Debian GNU/Linux 9 (stretch) 4.4.178-rockchip64   
    System load:   0.00 0.00 0.00  	Up time:       36 min		
    Memory usage:  4 % of 1991MB 	IP:            192.168.178.32
    CPU temp:      40°C           	
    Usage of /:    5% of 30G    	
    
    Last login: Wed Apr 10 16:00:34 2019 from 192.168.178.24
    

    4.4.178 ist im 4.4er Zweig der aktuellste Kernel. https://www.kernel.org/

    Erwähnen möchte ich noch, das ich nach der Aktualisierung natürlich die PCIe NVMe SSD wieder eingesteckt habe. Die Kiste bootet sauber, so weit ich das beurteilen kann.

    Man sieht das das WiFi-Modul vorhanden ist. wlan0 war mit

    ip a
    

    zu sehen. Ein gutes Zeichen 😉

    Dann mal schnell eine Konfigurationsdatei erstellt. /etc/wpa_supplicant/wpa_supplicant.conf

    ctrl_interface=/var/run/wpa_supplicant
    ctrl_interface_group=frank
    # Die Gruppe muss natuerlich angepasst werden
    eapol_version=1
    # 0: Der Treiber des Interfaces kümmert sich um das Scannen von Netzen und die AP-Auswahl.
    #    Dieser Modus sollte benutzt werden, wenn man eine Verschlüsselung auf ein Kabelnetzwerk legt.
    # 1: wpa_supplicant kümmert sich um das Scannen von Netzen und die AP-Auswahl.
    # 2: Fast wie 0, es wird aber mit Hilfe von Sicherheitsrichtlinien und der SSID zu APs verbunden (BSSID wird nicht unterstützt)
    #
    # Normalerweise funktioniert entweder Modus 1 oder Modus 2.
    ap_scan=1
    
    network={
            ssid="SSID"
            scan_ssid=1
            proto=RSN
            key_mgmt=WPA-PSK
            pairwise=CCMP
            group=CCMP
            psk="password"
    }
    

    Hinweis

    Das bitte anpassen!

    ctrl_interface_group=frank
    

    Und daran denken, das gehört so nicht in einen Liveserver! Die Konfig-Datei muss dann in /root usw. Da gehe ich hier aber nicht drauf ein. Wir wollen ja nur Testen 🙂

    interfaces

    In /etc/network/interfaces noch folgendes ergänzen.

    iface wlan0 inet dhcp
      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    auto wlan0
    

    Wir starten das wlan0 und holen uns per DHCP die benötigten Daten.

    reboot
    

    Danach sehen wir folgendes.

    frank@frank-MS-7A34:~$ ssh root@192.168.178.32
    root@192.168.178.32's password: 
     ____            _    ____               __   _  _   
    |  _ \ ___   ___| | _|  _ \ _ __ ___    / /_ | || |  
    | |_) / _ \ / __| |/ / |_) | '__/ _ \  | '_ \| || |_ 
    |  _ < (_) | (__|   <|  __/| | | (_) | | (_) |__   _|
    |_| \_\___/ \___|_|\_\_|   |_|  \___/   \___/   |_|  
                                                         
    
    Welcome to ARMBIAN 5.77.190404 nightly Debian GNU/Linux 9 (stretch) 4.4.178-rockchip64   
    System load:   0.00 0.00 0.00  	Up time:       48 min		
    Memory usage:  4 % of 1991MB 	IP:            192.168.3.9 192.168.178.32
    CPU temp:      40°C           	
    Usage of /:    5% of 30G    	
    
    [ General system configuration (beta): armbian-config ]
    
    Last login: Wed Apr 10 16:33:10 2019 from 192.168.178.24
    

    Zwei IP-Adressen Yeah!

    root@rockpro64:~# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff
        inet 192.168.3.9/24 brd 192.168.3.255 scope global dynamic eth0
           valid_lft 3543sec preferred_lft 3543sec
        inet6 fe80::a50d:c98d:4a55:7943/64 scope link 
           valid_lft forever preferred_lft forever
    3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff
        inet 192.168.178.32/24 brd 192.168.178.255 scope global wlan0
           valid_lft forever preferred_lft forever
    

    Danach mein WiFi-Test, LAN-Kabel entfernen und

    ssh root@192.168.178.32
    

    Und es funktioniert einwandfrei. Was noch??

    fdisk -l
    
    .......(gekürzt).......
    Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    

    Ok, die SSD ist da, WiFi-Modul funktioniert! Wer lieber Armbian mag, hat jetzt eine funktionierende Version.

    Viel Spaß beim Server bauen!

  • NanoPi R4S - Armbian

    NanoPi R4S armbian linux nanopir4s
    2
    0 Stimmen
    2 Beiträge
    416 Aufrufe
    FrankMF
    Müsste seit gestern so weit sein [image: 1612720791407-b20f93d2-1719-40c5-afb8-6b4edafa6793-image.png]
  • ROCKPro64 - RTL8111/8168/8411 Netzwerkkarte

    Hardware rockpro64
    4
    1
    0 Stimmen
    4 Beiträge
    465 Aufrufe
    K
    na denn, tippe ich mal so auf default konfiguriert per dhcp
  • Wireguard

    Verschoben Wireguard linux rockpro64 wireguard
    4
    0 Stimmen
    4 Beiträge
    945 Aufrufe
    FrankMF
    Etwas schnellerer Weg den Tunnel aufzubauen, Voraussetzung wireguard modul installiert Keys erzeugt Danach dann einfach ip link add wg0 type wireguard wg setconf wg0 /etc/wireguard/wg0.conf Datei /etc/wireguard/wg0.conf [Interface] PrivateKey = <Private Key> ListenPort = 60563 [Peer] PublicKey = <Public Key Ziel> Endpoint = <IPv4 Adresse Zielrechner>:58380 AllowedIPs = 10.10.0.1/32 Die Rechte der Dateien von wireguard müssen eingeschränkt werden. sudo chmod 0600 /etc/wireguard/wg0.conf Das ganze per rc.local beim Booten laden. Datei /root/wireguard_start.sh ############################################################################################### # Autor: Frank Mankel # Startup-Script # Wireguard # Kontakt: frank.mankel@gmail.com # ############################################################################################### ip link add wg0 type wireguard ip address add dev wg0 10.10.0.1/8 wg setconf wg0 /etc/wireguard/wg0.conf ip link set up dev wg0 Danach Datei ausführbar machen chmod +x /root/wireguard_start.sh In rc.local /root/wireguard_start.sh eintragen - Fertig!
  • ROCKPro64 - i2c Bus

    Hardware rockpro64
    1
    2
    0 Stimmen
    1 Beiträge
    574 Aufrufe
    Niemand hat geantwortet
  • Zwischenfazit August 2018

    ROCKPro64 rockpro64
    1
    1
    1 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • Bionic Minimal 0.7.7 - Vergleich 4.4.132 & 4.18.0-rc3-1046

    Verschoben Archiv rockpro64
    1
    0 Stimmen
    1 Beiträge
    609 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Wo stehen wir?

    ROCKPro64 rockpro64
    1
    0 Stimmen
    1 Beiträge
    637 Aufrufe
    Niemand hat geantwortet
  • stretch-minimal-rockpro64

    Verschoben Linux rockpro64
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF
    Mal ein Test was der Speicher so kann. rock64@rockpro64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 2812.7 MB/s C copy backwards (32 byte blocks) : 2811.9 MB/s C copy backwards (64 byte blocks) : 2632.8 MB/s C copy : 2667.2 MB/s C copy prefetched (32 bytes step) : 2633.5 MB/s C copy prefetched (64 bytes step) : 2640.8 MB/s C 2-pass copy : 2509.8 MB/s C 2-pass copy prefetched (32 bytes step) : 2431.6 MB/s C 2-pass copy prefetched (64 bytes step) : 2424.1 MB/s C fill : 4887.7 MB/s (0.5%) C fill (shuffle within 16 byte blocks) : 4883.0 MB/s C fill (shuffle within 32 byte blocks) : 4889.3 MB/s C fill (shuffle within 64 byte blocks) : 4889.2 MB/s --- standard memcpy : 2807.3 MB/s standard memset : 4890.4 MB/s (0.3%) --- NEON LDP/STP copy : 2803.7 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 2802.1 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 2800.7 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 2745.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2745.8 MB/s NEON LD1/ST1 copy : 2801.9 MB/s NEON STP fill : 4888.9 MB/s (0.3%) NEON STNP fill : 4850.1 MB/s ARM LDP/STP copy : 2803.8 MB/s ARM STP fill : 4893.0 MB/s (0.5%) ARM STNP fill : 4851.7 MB/s ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 602.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 551.6 MB/s NEON LD1/ST1 copy (from framebuffer) : 667.1 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 605.6 MB/s ARM LDP/STP copy (from framebuffer) : 445.3 MB/s ARM LDP/STP 2-pass copy (from framebuffer) : 428.8 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 4.5 ns / 7.2 ns 131072 : 6.8 ns / 9.7 ns 262144 : 9.8 ns / 12.8 ns 524288 : 11.4 ns / 14.7 ns 1048576 : 16.0 ns / 22.6 ns 2097152 : 114.0 ns / 175.3 ns 4194304 : 161.7 ns / 219.9 ns 8388608 : 190.7 ns / 241.5 ns 16777216 : 205.3 ns / 250.5 ns 33554432 : 212.9 ns / 255.5 ns 67108864 : 222.3 ns / 271.1 ns