Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. Images
  5. Kernel 4.4.x

Kernel 4.4.x

Angeheftet Images

  • FrankMF

    WLan auf der Konsole einrichten

    Angeheftet Linux
    3
    0 Stimmen
    3 Beiträge
    590 Aufrufe
    FrankMF

    Ich kann im Manjaro keine WPA3 Sicherheit auswählen, dann bekomme ich keine Verbindung. Es geht nur WPA2 Personal. Gegenstelle ist eine FRITZ!Box 6591 Cable.

    2021-11-28_16-37.png

    In der Fritzbox sieht das so aus

    50d23aa8-5f67-485e-a994-244ef4f6a270-image.png

    Das kam als Fehlermeldung

    Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: Trying to associate with SSID 'FRITZ!Box 6591 Cable AK' Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to select authenticated key management type Nov 28 11:03:07 frank-pc wpa_supplicant[700]: wlan0: WPA: Failed to set WPA key management and encryption suites

    Ich denke, der Treiber unterstützt das nicht.

  • FrankMF

    Armbian 20.08 (Caple) released

    Armbian
    1
    0 Stimmen
    1 Beiträge
    333 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - USB3

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    281 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Wireguard

    Verschoben Wireguard
    4
    0 Stimmen
    4 Beiträge
    872 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!

  • FrankMF

    Lokale Einstellungen

    Verschoben ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    563 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - Der Bootvorgang

    Verschoben Hardware
    3
    0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF

    Um einen neuen Kernel booten zu können, brauche ich diese 4 Dateien unter /boot

    config-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 System.map-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06

    Und den Ordner /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 mit folgendem Inhalt

    rock64@rockpro64v2_0:/boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06$ ls -la total 104 drwxr-xr-x 26 root root 4096 Sep 30 09:54 . drwxr-xr-x 6 root root 4096 Sep 30 09:55 .. drwxr-xr-x 2 root root 4096 Sep 30 09:54 al drwxr-xr-x 2 root root 4096 Sep 30 09:54 allwinner drwxr-xr-x 2 root root 4096 Sep 30 09:54 altera drwxr-xr-x 2 root root 4096 Sep 30 09:54 amd drwxr-xr-x 2 root root 4096 Sep 30 09:54 amlogic drwxr-xr-x 2 root root 4096 Sep 30 09:54 apm drwxr-xr-x 2 root root 4096 Sep 30 09:54 arm drwxr-xr-x 4 root root 4096 Sep 30 09:54 broadcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 cavium drwxr-xr-x 2 root root 4096 Sep 30 09:54 exynos drwxr-xr-x 2 root root 4096 Sep 30 09:54 freescale drwxr-xr-x 2 root root 4096 Sep 30 09:54 hisilicon drwxr-xr-x 2 root root 4096 Sep 30 09:54 lg drwxr-xr-x 2 root root 4096 Sep 30 09:54 marvell drwxr-xr-x 2 root root 4096 Sep 30 09:54 mediatek drwxr-xr-x 2 root root 4096 Sep 30 09:54 nvidia drwxr-xr-x 2 root root 4096 Sep 30 09:54 qcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 renesas drwxr-xr-x 2 root root 4096 Sep 30 09:54 rockchip drwxr-xr-x 2 root root 4096 Sep 30 09:54 socionext drwxr-xr-x 2 root root 4096 Sep 30 09:54 sprd drwxr-xr-x 2 root root 4096 Sep 30 09:54 synaptics drwxr-xr-x 2 root root 4096 Sep 30 09:54 xilinx drwxr-xr-x 2 root root 4096 Sep 30 09:54 zte

    Unter /boot/extlinux liegt dann die Datei extlinux.conf

    Die sieht bei mir dann so aus

    timeout 10 menu title select kernel label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06-memtest kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 memtest

    Darunter kommen dann evt. die alten Kernel die installiert waren, das habe ich hier im Beispiel weg gelassen.

  • FrankMF

    stretch-minimal-rockpro64

    Verschoben Linux
    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
  • FrankMF

    Images 0.6.x

    Verschoben Images
    30
    0 Stimmen
    30 Beiträge
    6k Aufrufe
    FrankMF

    0.6.60 released

    0.6.60: Fix pcie/nvme/sata support for 4.4, 0.6.60: Fix spi-flash access for 4.4/mainline,

    Ich bin davon ausgegangen, das 0.6.x nict mehr fortgeführt wird, okay - sieht nicht so aus.

    Sollte released werden, ist aber aus irgendeinem Grund gestern nicht passiert (lt. Kamil)