Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. Armbian
  5. ROCKPro64 - Armbian - NAS umgezogen

ROCKPro64 - Armbian - NAS umgezogen

Armbian
  • FrankMF

    Wie ja einige wohl schon mitbekommen haben, stehe ich im Moment mehr auf Armbian und das hat eigentlich nur einen einzigen Grund - die USB3 Schnittstelle!

    Da ich für einen Job diese USB3-Schnittstelle mit einer HDD bestücken möchte, musste ich dafür extra einen ROCKPro64 mit Armbian laufen lassen. Mein NAS lief mit einem 4.19er Ayufan Kernel (ohne Probleme). Wie schön wäre es jetzt, wenn an dem NAS die USB3 HDD dran hängen würde.

    Wenn man jetzt nachdenkt, bleibt nur eine Lösung. Das NAS braucht ein Armbian als Betriebssystem. Ok, ran an die Arbeit.
    Ich hatte ein Armbian so weit vorbereitet, das übliche mit User, IP-Adresse usw. Das NAS runtergefahren und die neue SD-Karte rein. Das NAS gestartet und dann tauchte dieses Problem mit meinem RAID auf. Die Geschichte ist was länger 😉
    https://forum.frank-mankel.org/topic/421/raid1-platte-verschwunden

    Ok, ein Tag verloren aber das NAS ist wieder stabil 🙂

    root@rockpro64_NAS:~# mdadm --detail /dev/md0 
/dev/md0:
        Version : 1.2
  Creation Time : Sat Oct 20 07:05:51 2018
     Raid Level : raid1
     Array Size : 1953379392 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 1953379392 (1862.89 GiB 2000.26 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Thu Dec 27 12:17:39 2018
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rockpro64v_2_1:0
           UUID : 33ac7964:473fe590:3682dd85:a979b336
         Events : 57884

    Number   Major   Minor   RaidDevice State
       2     253        0        0      active sync   /dev/dm-0
       1     253        1        1      active sync   /dev/dm-1
root@rockpro64_NAS:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 dm-1[1] dm-0[2]
      1953379392 blocks super 1.2 [2/2] [UU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

unused devices: <none>

    Mal für alle, die evt. mit dem gedanken spielen sich einen PCIe SATA Adapter kaufen wollen, ja er hat den Sync problemlos durchgezogen. 10 Stunden! Angeschlossen sind an diesem Adapter zwei 1,8 TB große 2,5 Zoll HDDs.

    Aktuell nutze ich folgendes Armbian

    frank@frank-MS-7A34:~$ ssh root@192.168.3.207
root@192.168.3.207's password: 
 ____            _    ____               __   _  _   
|  _ \ ___   ___| | _|  _ \ _ __ ___    / /_ | || |  
| |_) / _ \ / __| |/ / |_) | '__/ _ \  | '_ \| || |_ 
|  _ < (_) | (__|   <|  __/| | | (_) | | (_) |__   _|
|_| \_\___/ \___|_|\_\_|   |_|  \___/   \___/   |_|  
                                                     

Welcome to ARMBIAN 5.67 stable Debian GNU/Linux 9 (stretch) 4.4.166-rockchip64   
System load:   0.85 0.22 0.08  	Up time:       0 min		
Memory usage:  4 % of 1991MB 	IP:            192.168.3.207
CPU temp:      37°C           	
Usage of /:    16% of 15G

    Ja, ich denke auf dem NAS ist die stable die bessere Wahl 🙂

    Es gibt dort jetzt ein verschlüsseltes RAID 1 mit zwei 1,8TB Platten am SATA Controller. Am USB3 Port hängt eine 1,8TB HDD. So weit bin ich erst mal zufrieden.

    Das NAS steht mir per NFS auf meinen anderen Rechnern zur Verfügung. Gewisse Cronjobs müssen Nachts dann ein paar Daten abholen und hier und dort hin kopieren. Das NAS steht ja die meiste Zeit sinnlos in der Ecke und verbraucht Strom, dann kann das auch nachts ein wenig arbeiten 🙂

    Zum Schluss habe ich dann noch mittels hdparm den Platten beigebracht, das es nach einer eingestellten Zeit Feierabend ist und sich die HDDs schlafen legen.

    Nun wird es Zeit das NAS wieder in den Schrank zu stellen und die nächsten Tage mal zu beobachten, ob alles so läuft wie es soll. Da ich Armbian vorher ausgiebig getestet habe, gehe ich im Moment davon aus. Aber, man weiß ja nie.....

    Mich würde es freuen, wenn Kamil mal wieder Zeit hätte, aber es ist schön das es jetzt auch Armbian gibt. Was man jetzt noch bräuchte, wäre einen Mainline Kernel von Armbian. Ich bin mir sicher, das kommt auch noch.

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

    Das NAS mit den drei 2,5 Zoll HDD Platten läuft an einem 3A Netzteil - ohne Probleme. Hat heute Nacht die Jobs einwandfrei erledigt 😉

    Link Preview Image
    PINE64 Community

    PINE64 is a large, vibrant and diverse community and creates software, documentation and projects.

    favicon

    (www.pine64.org)

    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

  • FrankMF

    ROCKPro64 - 0.9.16 mit Kernel 5.6 auf PCIe NVMe SSD

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

    SATA Adapter - SSD kopieren

    Hardware
    1
    0 Stimmen
    1 Beiträge
    192 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    SATA - Booten jetzt möglich

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

    ROCKPro64 Übersicht - was geht?

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    596 Aufrufe
    FrankMF
    WIFI

    Seit dem Release des Images 0.7.13 ist WiFi auch möglich. Weiterhin ungelöst ist das Problem PCIe & WiFi (also bei mir).

  • FrankMF

    Armbian für den ROCKPro64

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

    ROCKPro64 - Armbian nand-sata-install

    Verschoben Armbian
    14
    0 Stimmen
    14 Beiträge
    2k Aufrufe
    FrankMF

    Ich habe heute, nachdem es einige Updates von Armbian gab, mal nachgeschaut ob ein spezieller Fehler verschwunden ist.
    Und zwar geht es um das Resizen der Partion nachdem wir Armbian auf eine USB-HDD (USB3) installiert haben.

    Ich setze dafür folgendes System ein.

    Hardware ROCKPro64v2.0 4GB RAM SanDisk 240GB 2,5 Zoll HDD (nix tolles) Software Welcome to ARMBIAN 5.67.181217 nightly Debian GNU/Linux 9 (stretch) 4.4.167-rockchip64

    Was sehe ich nach dem Reboot?

    root@rockpro64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 388M 5.3M 383M 2% /run /dev/sda1 220G 1.3G 207G 1% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp /dev/mmcblk0p1 58G 1.3G 57G 3% /media/mmcboot /dev/zram0 49M 3.0M 43M 7% /var/log tmpfs 388M 0 388M 0% /run/user/0

    Korrekt die Größe angepasst!

    Schnell mal den USB3 testen

    root@rockpro64:~# sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.0723 s, 113 MB/s

    Der Adapter

    root@rockpro64:~# lsusb -vvv Bus 004 Device 002: ID 2109:0715 VIA Labs, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2109 VIA Labs, Inc. idProduct 0x0715 bcdDevice 1.31 iManufacturer 1 VLI Manufacture String iProduct 2 VLI Product String iSerial 3 000000123ADA bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 70 bNumDeviceCaps 4 FIXME: alloc bigger buffer for device capability descriptors Device Status: 0x0000 (Bus Powered)

    Ein lästiger Fehler weniger. 😉

  • FrankMF

    ROCKPro64 - Samsung 970 NVMe M.2 500GB

    Hardware
    1
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • 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