Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. ROCKPro64 - USB3 bootet von SSD!

ROCKPro64 - USB3 bootet von SSD!

ROCKPro64
4 1 948
  • FrankMF

    Hmm, da bin ich heute doch nach langer Zeit mal wieder am Spielen, weil ich hier helfen wollte. Da nun der u-boot im SPI Flash war, kam ich auf die Idee, die Testplatte die hier rumliegt mal anzuschließen.

    Es handelt sich um eine SSD von SanDisk mit 240GB, nix Besonderes 😉 Und was stelle ich fest?!? Das Ding bootet 🙂 Kur über die SSH Konsole einen Reboot durchgeführt, habe gedacht das das Zufall war, geht wieder. schaut sehr erstaunt

    Hier das komplette Boot-Log: https://pastebin.com/asLuPk3G

    Eingesetzter u-boot

    U-Boot 2017.09-rockchip-ayufan-1035-gd646df03ac (Oct 26 2018 - 08:36:24 +0000)

    Das ist im Moment, der Aktuellste, den Kamil zur Verfügung stellt.
    https://github.com/ayufan-rock64/linux-u-boot/releases

    Auf der SSD ist folgendes System drauf.

    rock64@rockpro64:~$ uname -a
Linux rockpro64 4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1 #1 SMP Mon Oct 22 20:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

    Die Platte

    rock64@rockpro64:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            992M     0  992M   0% /dev
tmpfs           200M  440K  199M   1% /run
/dev/sda7       220G  1.3G  210G   1% /
tmpfs           996M     0  996M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           996M     0  996M   0% /sys/fs/cgroup
/dev/sda6       112M  4.0K  112M   1% /boot/efi
tmpfs           200M     0  200M   0% /run/user/1000

    Ich bin aktuell etwas verwundert, das es geht. Aber sehr wichtig wenn es jetzt endlich funktioniert.

    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

    Ich denke, ich habe das Problem erkannt. 🙂

    Wenn man den Stecker nicht komplett in die USB3-Buchse des ROCKPro64 einsteckt, dann geht es einwandfrei. Diese Buchse scheint nicht optimal zu funktionieren. Ich kann den Fehler hier ziemlich gut reproduzieren, es benötigt aber noch ein paar Tests.

    Also, wer mal testen will, den Stecker so weit einstecken, bis man leichten Widerstand spürt. Das sollte dann reichen 😉 Kann man dann mit einer UART-Verbindung kontrollieren, ob er das Device erkennt. Kann man da sehr schön sehen.

    Bitte nagelt mich nicht drauf fest, ich hoffe das das noch jemand anders bestätigen kann. Morgen werde ich das noch mit einem anderen ROCKPro64 hier testen.

    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

    Leider ist das immer noch nicht DIE Lösung 😞

    Am ROCKPro64 erreiche ich folgende Geschwindigkeit

    rock64@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, 130.382 s, 32.9 MB/s

    Ok, sieht nach USB2 aus. Mal am Haupt-PC testen, ob die Komponenten USB3 können.

    frank@frank-MS-7A34:/media/frank/linux-root/home/rock64$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
[sudo] Passwort für frank: 
4096+0 Datensätze ein
4096+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 14,7509 s, 291 MB/s

    Sieht gut aus. Und jetzt bin ich genauso schlau wie vorher....

    Mein USB3-Adapter für die SSD

    Bus 002 Device 005: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge

    Und raus. Ich hab keinen Plan, woran es liegt!?!?!?!

    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

    Da oben steht viel Bullshit 🙂 Ich habe mich mal mit dem mechanischen Aufbau einer USB3 Buchse beschäftigt, bzw. dazu recherchiert. Auf dieser Seite ist ein klasse Bild, was das sehr gut verdeutlicht.

    https://kompendium.infotip.de/usb-3-0.html

    Abbildung 28. Dort sieht man das die USB3 Kontakte RX/TX und GND ganz hinten sind. Wenn ich den Stecker jetzt komplett einstecke, wird wohl versucht eine USB3 Verbindung aufzubauen, die ja im Moment aus irgendeinem Grund scheitert. Wenn ich den Stecker nun ein Stück raus ziehe, trenne ich die USB3-Verbindung und es kommt eine USB2-Verbindung zustande.

    So mit ist mir jetzt einiges klarer, aber das Problem ist ungelöst 😞

    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

    Mainline 5.13.x

    Images linux rockpro64
    1
    0 Stimmen
    1 Beiträge
    238 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - Reset & Power Taster (extern)

    Hardware hardware rockpro64
    1
    1
    0 Stimmen
    1 Beiträge
    707 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    IPFire auf dem ROCKPro64

    ROCKPro64 rockpro64
    2
    1
    0 Stimmen
    2 Beiträge
    673 Aufrufe
    FrankMF
    Falls es jemanden da draußen interessiert, hier eine Liste der Dinge die funktionieren GREEN Die LAN-Schnittstelle wird einwandfrei erkannt Webserver läuft, Weboberfläche erreichbar Das war's dann mit den positiven Daten jede Menge Kernelfehler iptables Fehler Modul fehlt?? kein LAN-Adapter, WLan-Adapter wird erkannt Lizenzverbindungen lassen sich nicht bestätigen nach der Installation ist die Konsole weg usw. usf
  • FrankMF

    u-boot-flash-spi-rockpro64.img.xz

    Verschoben Tools rockpro64
    1
    0 Stimmen
    1 Beiträge
    2k Aufrufe
    Niemand hat geantwortet
  • FrankMF

    stretch-openmediavault-rockpro64

    Verschoben Linux rockpro64
    1
    0 Stimmen
    1 Beiträge
    834 Aufrufe
    Niemand hat geantwortet
  • FrankMF

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

    Erste Lebenszeichen

    ROCKPro64 rockpro64
    1
    2
    0 Stimmen
    1 Beiträge
    534 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - PCIe x4

    Verschoben Hardware hardware rockpro64
    13
    6
    0 Stimmen
    13 Beiträge
    5k Aufrufe
    FrankMF
    @Northstar Hallo, laut meinen Info's nicht, hat irgendwas mit der Speicheradressierung zu tuen. Und Grafikkarten benötigen wohl zu viel. Das ist das, was ich bei den vielen Diskussionen im IRC so aufgeschnappt habe. Ich habe es auch schon mal genauso probiert - natürlich ohne Erfolg.