Skip to content

ROCKPro64 - USB3

ROCKPro64
  • Man liest ja immer viel über Probleme mit dem USB3-Port auf dem ROCKPro64. z.B. hier

    Nachdem ich heute mein NAS mal wieder ins Gehäuse eingebaut habe, habe ich ein wenig gespielt. Hier lag eine SanDisk Ultra 3D SSD mit 1TB rum, da die SD-Karte ziemlich voll war, bot es sich an diese SSD zum Rootdevice zu machen.

    Alles so gemacht, wie immer. Alles kopiert, SSD umbenannt in linux-root und neugestartet. So sieht das jetzt aus.

    rock64@rp64v_2_1_NAS:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            978M     0  978M   0% /dev
    tmpfs           198M  664K  198M   1% /run
    /dev/sda        916G   63G  807G   8% /
    tmpfs           990M     0  990M   0% /dev/shm
    tmpfs           5,0M  4,0K  5,0M   1% /run/lock
    tmpfs           990M     0  990M   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4,0K  112M   1% /boot/efi
    tmpfs           198M     0  198M   0% /run/user/1000
    /dev/md0        1,8T  723G 1018G  42% /mnt/raid
    

    Es gibt ein Raid, die SSD am USB3 die das Rootdevice darstellt. Diese Konstruktion hat den Vorteil, das man auch den Kernel updaten kann, weil das Bootdevice weiterhin auf der SD-Karte liegt. Aktuell läuft dieser Kernel.

    rock64@rp64v_2_1_NAS:~$ uname -a
    Linux rp64v_2_1_NAS 5.0.0-1101-ayufan-g41eeb7cd789e #ayufan SMP PREEMPT Fri Mar 8 22:14:59 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
    

    Ok, dann mal ein kleiner Test. Wir kopieren mal alle Star Wars Filme vom Haupt-NAS. Das NAS bilden zwei mechanische HDD's. Der Kopiervorgang erfolgt auf die an USB3 hängende SSD.

    rock64@rp64v_2_1_NAS:~$ scp -r root@192.168.3.243:/mnt/nas/Videos/"Star_Wars" /home/rock64/
    root@192.168.3.243's password: 
    Star_Wars_I.ts                       100% 6753MB  83.7MB/s   01:20    
    Star_Wars_IV.ts                      100% 7668MB  83.5MB/s   01:31    
    Star_Wars_VI.ts                      100% 7871MB  83.4MB/s   01:34    
    Star_Wars_V.ts                       100% 7409MB  83.3MB/s   01:28    
    Star_Wars_III.ts                     100% 7169MB  83.0MB/s   01:26    
    Star_Wars_II.ts                      100% 6268MB  83.3MB/s   01:15
    

    Schwupps, alles da. Hätte ect. noch was schneller sein können, vermute aber das die mechanischen HDD's der Flaschenhals sind.

    So, kurz die SSD testen.

    rock64@rp64v_2_1_NAS:~$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync
    [sudo] password for rock64: 
    4096+0 records in
    4096+0 records out
    4294967296 bytes (4,3 GB, 4,0 GiB) copied, 10,7109 s, 401 MB/s
    

    Der dmesg ist völlig sauber, keine Auffälligkeiten in Bezug auf den USB3-Port. Da @tkaiser öfter von "Undervoltage" schreibt, ich nutze an diesem NAS das Original Netzteil von Pine64 in der 5A Ausführung.

  • 0 Stimmen
    17 Beiträge
    1k Aufrufe
    FrankMF

    Durch diesen Beitrag ist mir mal wieder eingefallen, das wir das erneut testen könnten 😉

    Also die aktuellen Daten von Debian gezogen. Das Image gebaut, könnt ihr alles hier im ersten Beitrag nachlesen. Da die eingebaute Netzwerkschnittstelle nicht erkannt wurde, habe ich mal wieder den USB-to-LAN Adapter eingesetzt.

    Bus 005 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet

    Die Installation wollte ich auf einem NVMe Riegel installieren.

    Die Debian Installation durchgezogen und nach erfolgreicher Installation neugestartet. Und siehe da, ohne das man alles möglich ändern musste, bootete die NVMe SSD 🤓

    Eingesetzter uboot -> 2020.01-ayufan-2013......

    Die nicht erkannte LAN-Schnittstelle müsste an nicht freien Treibern liegen, hatte ich da irgendwo kurz gelesen. Beim Schreiben dieses Satzes kam die Nacht und ich konnte noch mal drüber schlafen. Heute Morgen, beim ersten Kaffee, dann noch mal logischer an die Sache ran gegangen.

    Wir schauen uns mal die wichtigsten Dinge an.

    root@debian:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 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> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: enx000acd26e2c8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff inet 192.168.3.208/24 brd 192.168.3.255 scope global dynamic enx000acd26e2c8 valid_lft 42567sec preferred_lft 42567sec inet6 fd8a:6ff:2880:0:20a:cdff:fe26:e2c8/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:20a:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5426sec preferred_lft 1826sec inet6 fe80::20a:cdff:fe26:e2c8/64 scope link valid_lft forever preferred_lft forever

    Ok, er zeigt mir die Schnittstelle eth0 ja an, dann kann es an fehlenden Treibern ja nicht liegen. Lässt dann auf eine fehlerhafte Konfiguration schließen. Nächster Halt wäre dann /etc/network/interfaces

    Das trägt Debian ein

    # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug enx000acd26e2c8 iface enx000acd26e2c8 inet dhcp # This is an autoconfigured IPv6 interface iface enx000acd26e2c8 inet6 auto

    Gut, bei der Installation hat Debian ja nur die zusätzliche Netzwerkschnittstelle erkannt, folgerichtig ist die auch als primäre Schnittstelle eingetragen. Dann ändern wir das mal...

    # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx000acd26e2c8 allow-hotplug eth0 #iface enx000acd26e2c8 inet dhcp iface eth0 inet dhcp # This is an autoconfigured IPv6 interface #iface enx000acd26e2c8 inet6 auto iface eth0 inet6 auto

    Danach einmal alles neu starten bitte 😉

    systemctl status networking

    Da fehlte mir aber jetzt die IPv4 Adresse, so das ich einmal komplett neugestartet habe. Der Ordnung halber, so hätte man die IPv4 Adresse bekommen.

    dhclient eth0

    Nachdem Neustart kam dann das

    root@debian:/etc/network# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 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 mq 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.172/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 42452sec preferred_lft 42452sec inet6 fd8a:6ff:2880:0:6003:b0ff:fed6:dcb3/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:6003:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5667sec preferred_lft 2067sec inet6 fe80::6003:b0ff:fed6:dcb3/64 scope link valid_lft forever preferred_lft forever 3: enx000acd26e2c8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff

    Fertig, eth0 läuft. Nun kann man den zusätzlichen Adapter entfernen oder halt konfigurieren, wenn man ihn braucht.

    Warum der Debian Installer die eth0 nicht erkennt verstehe ich nicht, aber vielleicht wird das irgendwann auch noch gefixt. Jetzt habe ich erst mal einen Workaround um eine Installation auf den ROCKPro64 zu bekommen.

  • ROCKPro64 - Secondary IP entfernen

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    611 Aufrufe
    FrankMF

    Hallo @mabs,

    es ging bei meinem Post gar nicht um den dhcpd, also den Daemon der die Adressen verteilt. Hintergrund, ich versuche gerade mal wieder einen Router auf Basis eines ROCKPro64 zu bauen. Dabei bin ich in Kamils Debian Minimal über die zweite IP-Adresse gestolpert.

    Danke aber für deine Anregungen.

    Es gibt da aber wohl mit dem Debian Minimal irgendwelche Probleme mit dem Forwarding, so das ich das jetzt auf einem Bionic mache, dort klappt das einwandfrei. Aber dazu später ausführlich in einem anderen Thread.

  • ROCKPro64 - Stromaufnahme wenn OFF

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    430 Aufrufe
    FrankMF

    Die Idee war, das eine evt. sehr kleine Stromaufnahme mit dieser Art "Meßgerät" nicht vernünftig erfasst werden kann.

  • VON USB 4TB HD BOOTEN GEHT NICHT

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    566 Aufrufe
    W

    Hallo FrankM,
    schade das Du mir nicht weiter helfen kannst, aber danke für Deine schnelle Antwort.
    Mit dem Bugreport kenne ich nicht aus, bin noch leihe.

    Einen schönen Abend noch.

    Winne

  • 0 Stimmen
    14 Beiträge
    2k Aufrufe
    K

    halli hallo & zusammen,
    in Allgemeinen lässt sich selten empfehlen, auf verdacht alles zu updaten, sobald irgend etwas nicht tut. Oftmals holt man sich lediglich neue Ungewissheit ins Boot. Es hilft eher zu wissen, wo es (denn ungefähr) hakt.

    Wie Frank in etwa bereits angesprochen hat ist es ungemein hilfreich zu sehen "was ab geht". Sprich die serielle "Schnitte" anzuklemmen. Das ist wirklich kein Hexenwerk, braucht aber einen Pegelwandler.
    Andernfalls ist die Gefahr hoch, dass man mit Rätselraten einen Abend ohne Ergebnis in den Sand setzt. Hab ich einmal mit diesem Board hinter mir, dann die serielle Komm angeklemmt.
    Ein ResetProb hab ich zumindest mit eMMC noch nicht beobachtet. Dabei habe ich viel Kernel gewechselt (nie den uboot) und 'reboot' getippt. Ab und an hängt er anscheinend bei Initialisierung der tty's, aber ich mag mich irren. Für das Prob von @killlah78 fehlt für mehr einfach ein output
    gruß

  • ROCKPro64 - USB-OTG funktioniert!

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    531 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - kein WLan-Modul möglich?

    ROCKPro64
    4
    0 Stimmen
    4 Beiträge
    2k Aufrufe
    FrankMF

    Heute, 5 Monate später, kann ich bestätigen das WLan möglich ist 🙂 Getestet auf einem ROCKPro64 v2.1 mit 2GB RAM.

    Eine Vorabversion von Recalbox machte es das erste Mal für mich möglich das WLan zu benutzen. Bericht

    Und PCIe ist abgeschaltet im dts File.

    pcie-phy { compatible = "rockchip,rk3399-pcie-phy"; #phy-cells = <0x0>; rockchip,grf = <0x15>; clocks = <0x8 0x8a>; clock-names = "refclk"; resets = <0x8 0x87>; reset-names = "phy"; status = "disabled"; phandle = <0x8b>; }; pcie@f8000000 { compatible = "rockchip,rk3399-pcie"; #address-cells = <0x3>; #size-cells = <0x2>; aspm-no-l0s; clocks = <0x8 0xc5 0x8 0xc4 0x8 0x147 0x8 0xa0>; clock-names = "aclk", "aclk-perf", "hclk", "pm"; bus-range = <0x0 0x1f>; max-link-speed = <0x2>; linux,pci-domain = <0x0>; msi-map = <0x0 0x89 0x0 0x1000>; interrupts = <0x0 0x31 0x4 0x0 0x0 0x32 0x4 0x0 0x0 0x33 0x4 0x0>; interrupt-names = "sys", "legacy", "client"; #interrupt-cells = <0x1>; interrupt-map-mask = <0x0 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 0x8a 0x0 0x0 0x0 0x0 0x2 0x8a 0x1 0x0 0x0 0x0 0x3 0x8a 0x2 0x0 0x0 0x0 0x4 0x8a 0x3>; phys = <0x8b>; phy-names = "pcie-phy"; ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x1e00000 0x81000000 0x0 0xfbe00000 0x0 0xfbe00000 0x0 0x100000>; reg = <0x0 0xf8000000 0x0 0x2000000 0x0 0xfd000000 0x0 0x1000000>; reg-names = "axi-base", "apb-base"; resets = <0x8 0x82 0x8 0x83 0x8 0x84 0x8 0x85 0x8 0x86 0x8 0x81 0x8 0x80>; reset-names = "core", "mgmt", "mgmt-sticky", "pipe", "pm", "pclk", "aclk"; status = "disabled";

    Also bleibt weiterhin ungeklärt, ob auch beides zusammen möglich ist. Also gleichzeitig das WLan-Modul und eine PCIe Karte.

  • Wiki zum ROCKPro64 veröffentlicht!

    Verschoben ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet