Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. ROCKPro64 - DKMS im Release RC12 möglich

ROCKPro64 - DKMS im Release RC12 möglich

ROCKPro64
  • FrankMF

    Mit dem Image 0.8.0rc12 hat Kamil ein paar Infos veröffentlicht.

    # DKMS

The DKMS (Dynamic Kernel Module Support) is convinient method for installing additional drivers
that are outside of kernel tree.

There's awesome documentation about [DKMS](https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support)
on ArchWiki, get familiar with it to understand what and how to use it in general.

To use DKMS you need to have `linux-headers` installed.
This is by default if you use images generated by this repository.

## Install DKMS (arm64)

The first step is to install and configure DKMS:

```bash
sudo apt-get update -y
sudo apt-get install dkms git-core
```

## Install DKMS (armhf)

**This currently does not work due to missing `gcc-aarch64-linux-gnu`.**

## Wireguard

Installing Wireguard is very simple with DKMS and makes Wireguard to be auto-updated
after kernel change.

Following the documentation from https://www.wireguard.com/install/:

```bash
sudo add-apt-repository ppa:wireguard/wireguard
sudo apt-get install python wireguard
```

## RTL 8812AU (WiFi USB adapter)

The Realtek 8812AU is very popular chipset for USB dongles. The 8812AU is being sold by Pine64, Inc.
as well.

```bash
sudo git clone https://github.com/greearb/rtl8812AU_8821AU_linux.git /usr/src/rtl8812au-4.3.14
sudo dkms build rtl8812au/4.3.14
```

## tn40xx driver (10Gbps PCIe adapter)

```bash
sudo git clone https://github.com/ayufan-rock64/tn40xx-driver /usr/src/tn40xx-001
sudo dkms build tn40xx/001
```

## exfat-nofuse

ExFat is by default available in Debian/Ubuntu repositories, but this uses FUSE (Filesystem in Userspace).
There's a very good linux kernel driver available:

```bash
sudo git clone https://github.com/barrybingo/exfat-nofuse /usr/src/exfat-1.2.8
sudo dkms build exfat/1.2.8
```

    Quelle: https://gitlab.com/ayufan-repos/rock64/linux-build/commit/c6ebc51ab5c2e347897f98cab474016d7dce354f

    Da wären

    • DKMS für arm64
    • Wireguard
    • RTL 8812AU (WiFi USB adapter)
    • tn40xx driver (10Gbps PCIe adapter)
    • exfat-nofuse

    DKMS Erklärung gibt es hier. Ich versuche das mal zu erklären.

    DKMS ist ein Programm was es ermöglicht Kernel Module außerhalb des Kernels zu ermöglichen. Diese Kernelmodule werden nach der Installation eines neuen Kernels aber automatisch neu gebaut.

    Das habe ich mit Wireguard ja schon erfolgreich ausprobiert, hier nachzulesen.

    DKMS Status

    Hier sieht man, das wireguard installiert ist.

    root@rockpro64:~# dkms status
    wireguard, 0.0.20190406, 4.4.167-1189-rockchip-ayufan-gea9ef7a80268, aarch64: installed

    Mehr Infos zu DKMS findet man hier.

    Damit kann man nun z.B. diesen USB WiFi Adapter von pine64.org benutzen.

    Außerdem 10Gbps PCIe Netzwerkkarten. Schnelle Datenübertragungen für zu Hause? Nun kein Problem mehr, aber noch ein recht teurer Spaß 🙂

    exFAT ist ein Dateisystem von Microsoft, was speziell für Flash-Wechselspeicher entwickelt wurde.

    Dann viel Spaß beim Ausprobieren 😉

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
Anmelden zum Antworten

  • FrankMF

    ROCKPro64 - Anpassen resize_rootfs.sh

    Angeheftet ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    490 Aufrufe
    FrankMF
    Seit Release 0.10.10 ist das automatische Vergrößern der Root Partition mit drin 0.10.10: Support automated resize when booting from nvme Einfach das Image auf die NVMe SSD schreiben, ab in den ROCKPro64 und fertig! Nach dem Booten wird die Partition dann automatisch auf die maximal mögliche Größe erweitert. Kamil hat das Script auch ein wenig angepasst. case $dev in /dev/mmcblk?p?) DISK=${dev:0:12} PART=${dev:13} NAME="sd/emmc" ;; /dev/sd??) DISK=${dev:0:8} PART=${dev:8} NAME="hdd/ssd" ;; /dev/nvme?n?p?) DISK=${dev:0:12} PART=${dev:13} NAME="pcie/nvme" ;; Das Resultat bei einer Samsung 979 EVO mit 500GB Speicher rock64@rockpro64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 918M 0 918M 0% /dev tmpfs 192M 5.2M 187M 3% /run /dev/nvme0n1p4 459G 1.2G 439G 1% / tmpfs 957M 0 957M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 957M 0 957M 0% /sys/fs/cgroup /dev/nvme0n1p3 229M 44M 169M 21% /boot /dev/nvme0n1p2 12M 0 12M 0% /boot/efi tmpfs 192M 0 192M 0% /run/user/1000 Perfekt. Danke Kamil!
  • FrankMF

    Mainline 5.4.x

    Images
    2
    0 Stimmen
    2 Beiträge
    365 Aufrufe
    FrankMF
    Bootet bei mir weder von USB3-SSD noch von SD-Karte. USB3-SSD -> https://pastebin.com/QAS92sme SD-Karte -> https://pastebin.com/Bsr3WLJ7
  • FrankMF

    Mainline 5.3.x

    Images
    3
    0 Stimmen
    3 Beiträge
    427 Aufrufe
    FrankMF
    5.3.0-1119-ayufan released ayufan: defconfig: enable DRM_PANFROST/DRM_LIMA
  • FrankMF

    ROCKPro64 - Booten von USB3

    ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    412 Aufrufe
    FrankMF
    Yeah, genau das worauf ich auch warte. Wenn ich das richtig mitbekommen habe, könnte das Kamil's nächster Punkt auf seiner Liste sein.
  • FrankMF

    ROCKPro64 - Armbian armbian-config

    Verschoben Armbian
    1
    3
    0 Stimmen
    1 Beiträge
    772 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    OMV Images

    ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    916 Aufrufe
    FrankMF
    Kurzes Update https://github.com/ayufan-rock64/linux-build/releases/download/0.8.0rc10/stretch-openmediavault-rockpro64-0.8.0rc10-1125-armhf.img.xz Startet Incl. WiFi & PCIe NVMe SSD War aber nur ein ganz kurzer Test!!
  • FrankMF

    Release Empfehlung für Einsteiger

    Verschoben Archiv
    2
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    Sieht so aus, als wenn wir ein neues Traumpaar haben. 0.7.7 und rock64@rockpro64:/mnt$ uname -a Linux rockpro64 4.18.0-rc3-1046-ayufan-ge76778b6aa4b #1 SMP PREEMPT Thu Jul 19 14:10:17 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
  • 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