Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Pine64
  3. ROCKPro64
  4. Hardware
  5. Serielle Konsole UART2

Serielle Konsole UART2

Angeheftet Verschoben Hardware
  • FrankMF

    Hier mal die Info's sammeln zur seriellen Konsole.

    • Baudrate: 1500000
    • Data bits: 8
    • Parity: N
    • Stop bits: 1

    Quelle: http://opensource.rock-chips.com/images/f/f9/RK3399_Linux_Debain_V1.1_Development_Guide170620.pdf

    0_1526196275573_Rockpro64 Pi-2 Connector ver0.2.png

    Es sieht so aus, das es auf den SOC's von Pine64 keinen separaten Steckplatz für die serielle Konsole gibt, so wie ich das von den Bananen her kenne. Man nutzt wohl direkt den UART2 Anschluss des Expansions Steckplatzes. Da hätten wir dann:

    Die rote Ader nicht anschließen!

    • Nr. 6 GND - schwarz
    • Nr. 8 UART2_TX - weiß
    • Nr. 10 UART2_ RX - grün

    Update vom 18. März 2019

    Seit dem Image 0.7.14 stört die Verbindung an Pin 10 das Booten des ROCKPro64, wenn dieser mit einem WiFi-Modul und einer PCIe-Karte bestückt ist. Das entfernen der Verbindung löst das Problem, man hat dann aber nur noch lesend Zugriff und kann keine Kommandos über die Konsole absetzen! Aber, das sollte das kleiner Problem sein. Die Entwickler sind informiert, keine Ahnung ob man das Fixen kann.

    0_1526803326819_konsole3.jpg

    Als Gedankenstütze, vom ROCK64 https://forum.pine64.org/showthread.php?tid=5008

    Damit sollten die vorhandenen USB-Adapter genauso wie bei den Bananen funktionieren!

    Achtung!

    Durch die schnelle Übertragungsrate kommt es bei verschiedenen Adaptern zu Darstellungsfehlern. Ein Adapter bei mir funktioniert nicht, fehlerhafte Darstellung. Mein billigster Adapter funktioniert, einwandfreie Darstellung.

    Also, wenn ihr Probleme habt, einfach mal einen anderen Adapter ausprobieren. Die anderen Angaben oben funktionieren!

    Tools zum Flashen

    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 habe ja einige Adapter ausprobiert, habe jetzt eine ordentliche Sammlung davon, aber habe jetzt einen gefunden der mir wohl alles anzeigt 😉

    Problem bei vielen Adaptern scheint die hohe Übertragungsrate zu sein. Wenn ihr als Ausgabe nur Müll bekommt, könnt ihr den Adapter direkt an die Seite legen, korrekter Anschluss vorausgesetzt!

    Einen Adapter den ich jetzt die ganze Zeit benutzt hatte, war folgender.

     Bus 003 Device 017: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light

    Ging, hatte aber das Problem das beim ersten Start die Ausgaben des U-Boots nicht vernünftig angezeigt werden. Wenn man mit den Platinen rumspielt, ist das sehr unvorteilhaft.

    Ok, nächster Versuch

    Bus 003 Device 016: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

    Und der zeigt jetzt auch den U-Boot vernünftig an. Benutzt wird folgendes Linux.

    rock64@rockpro64:~$ uname -a
Linux rockpro64 4.4.126-rockchip-ayufan-239 #1 SMP Sun May 27 18:38:24 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

    Ausgabe

    channel 0 training pass!

channel 1 training pass!

change freq to 800MHz 1,0

ch 0 ddrconfig = 0x101, ddrsize = 0x2020

ch 1 ddrconfig = 0x101, ddrsize = 0x2020

pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD

OUT

U-Boot SPL board init



U-Boot SPL 2017.09-g03a332b (May 27 2018 - 18:34:10)

booted from SD

Trying to boot from MMC2

NOTICE:  BL31: v1.3(debug):d98d16e

NOTICE:  BL31: Built : 15:03:07, May 10 2018

NOTICE:  BL31: Rockchip release version: v1.1

INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3

INFO:    Using opteed sec cpu_context!

INFO:    boot cpu mask: 0

INFO:    plat_rockchip_pmu_init(1151): pd status 3e

INFO:    BL31: Initializing runtime services

WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK

ERROR:   Error initializing runtime service opteed_fast

INFO:    BL31: Preparing for EL3 exit to normal world

INFO:    Entry point address = 0x200000

INFO:    SPSR = 0x3c9





U-Boot 2017.09-g03a332b (May 27 2018 - 18:34:23 +0000), Build: jenkins-linux-build-rock-64-239

    So muss das sein. 🙂

    Mach ich selten, aber um es anderen etwas einfacher zu machen hier ein Amazon Link.

    Link Preview Image
    Amazon.de

    favicon

    (www.amazon.de)

    0_1527938581023_Adapter_bearbeitet2.jpg

    Anschluss

    ROCKPro64 - Adapter

    • GND (6) - GND
    • TX (8) - RX
    • RX (10) - TX

    Zu Pin 10 bitte das Update im ersten Beitrag beachten!

    Die Brücke des Adapters steckt auf VCC / 3V3 und der Anschluss 5V ist frei. Das ist wohl ein Spannungsausgang, den man wahlweise auf 3V3 oder 5V schalten kann, den wir aber nicht benötigen!

    Die Einstellungen der seriellen Schnittstelle findet ihr im Eingangsthread.

    Ihr könnt natürlich, wenn ihr euch einen ROCKPro64 bestellt, direkt einen USB-Adapter mitbestellen!
    https://www.pine64.org/?product=padi-serial-console
    Ich setze mal voraus, das der 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
    C 1 Antwort
    0
  • T

    @FrankM
    Der anschluss 10 RX auf dem Rockpro64 V2.1 und warscheinlich auch anderen da das auf deiner Seite irgendwo erwähnt wurde muss beim booten frei sein.

    Es sieht so aus als ob der Prozessor darüber Spannung bekommt da der TX pin vom adapter "high" gezogen wird da scheint ein fehler in dem Layout oder Prozessor zu sein so das eine versorgung durch diesen pin auch "Rückwärts" funktioniert.

    Sehen kann man das wenn man GND und den pin 10 belegt, Spannung auf das Bord gibt und dann wieder trennt. Danach bleibt die Power LED leicht am glimmen. Nur anstecken des Serial converters reicht da nicht, dabei leuchtet die LED nicht auf. Außerdem geht das auch nur mit 5V Logic Level sonst kommt nicht genug an der LED an um es optisch zu erfassen das müsste man dann Messen, ist aber in jedem fall so nicht richtig.

    Sven

    FrankMF 1 Antwort
    0
  • FrankMF

    Ich mache das seit dem ersten Tag so, noch nie Probleme mit gehabt.

    Das mit der Rückspannung ist mir auch schon aufgefallen.

    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

    @tux_on_tour

    Hallo Sven,

    ich muss mich zu dem Thema noch mal äußern.

    Du hattest Recht! 👏

    Seit dem Image 0.7.14 (wifi & pcie) hatte ich das Problem das der ROCKPro64 nicht mehr booten möchte. Ein entfernen von Pin 10 löste das Problem.

    Vielen Dank nachträglich!!

    Nachteil, man kann von der Konsole aus nichts mehr machen!

    Ich werde das in meinen Anleitungen entsprechend ändern!

    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

    Es gibt Berichte im IRC, das es bei einigen auch mit der Verbindung zu Pin 10 geht. Vielleicht auch abhängig vom Adapter!? Im Zweifel einfach mal 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
  • C

    @FrankM
    Hallo, ich bin noch ganz unerfahren mit Pi's.
    Wenn ich jetzt eine Physische verbindung mit einer USB-TTL UART Konsole habe,
    wie stelle ich da eine Verbindung her?
    Ich habe Linux auch auf meinem Rechner drauf und bin nicht ganz begriffstuzig, was Konsolen angeht.
    Vielen Dank

    Cri

    0
  • FrankMF

    Ich verweise mal auf einen Artikel auf einer Webseite von mir, der Einsteiger Niveau hat.
    https://frank-mankel.de/wichtig/serielle-konsole

    Wenn es dann noch Probleme gibt, einfach fragen.

    Und beachte bitte, das wir hier nicht über PIs schreiben, sondern über ROCKPros. Da könnte es kleine Unterschiede geben. https://www.raspberrypi.org/documentation/configuration/uart.md

    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 - Debian Bullseye Teil 1

    ROCKPro64
    17
    0 Stimmen
    17 Beiträge
    2k 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.

  • FrankMF

    Images 0.10.x

    Angeheftet Images
    10
    0 Stimmen
    10 Beiträge
    441 Aufrufe
    FrankMF

    0.10.12: gitlab-ci-linux-build-184 released

    0.10.12: Be strict on any qemu failures 0.10.12: Build by default mate/lxde/gnome/xfce4 0.10.12: Add pcie scan delay from @nuumio 0.10.12: Add ubuntu-mate-lightdm-theme where possible

    Ich komme gar nicht mehr mit dem Testen hinterher 🙂

  • FrankMF

    ROCKPro64 - USB3

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

    Zwischenfazit April 2019

    Angeheftet ROCKPro64
    1
    1 Stimmen
    1 Beiträge
    555 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    ROCKPro64 - Das erste Mal

    Angeheftet Verschoben Hardware
    5
    1 Stimmen
    5 Beiträge
    869 Aufrufe
    FrankMF

    Ich kann heute die Fragen aller Fragen beantworten 🙂

    Damit ist leider die Frage immer noch unbeantwortet ob WLan und PCIe zusammen nutzbar ist!! Es geht!!

    Ich habe von MrFixit ein Testimage der RecalBox, benutzt das selbe Debian wie oben. Die Tage konnte man im IRC verfolgen, wie man dem Grundproblem näher kam und wohl einen Fix gebastelt hat, damit beides zusammen funktioniert. Mr.Fixit hat das in RecalBox eingebaut und ich durfte testen.

    # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 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: <NO-CARRIER,BROADCAST,MULTICAST,UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.178.27/24 brd 192.168.178.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 2a02:908:1262:4680:ae83:f3ff:fee6:1fb2/64 scope global dynamic valid_lft 7145sec preferred_lft 3545sec inet6 fe80::ae83:f3ff:fee6:1fb2/64 scope link valid_lft forever preferred_lft forever # ls /mnt bin etc media recalbox sd.img test2.img boot home mnt root selinux tmp crypthome lib opt run srv usr dev lost+found proc sbin sys var # fdisk BusyBox v1.27.2 (2019-02-01 22:43:19 EST) multi-call binary. Usage: fdisk [-ul] [-C CYLINDERS] [-H HEADS] [-S SECTORS] [-b SSZ] DISK Change partition table -u Start and End are in sectors (instead of cylinders) -l Show partition table for each DISK, then exit -b 2048 (for certain MO disks) use 2048-byte sectors -C CYLINDERS Set number of cylinders/heads/sectors -H HEADS Typically 255 -S SECTORS Typically 63 # fdisk -l Disk /dev/mmcblk0: 15 GB, 15931539456 bytes, 31116288 sectors 486192 cylinders, 4 heads, 16 sectors/track Units: cylinders of 64 * 512 = 32768 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 * 2,10,9 10,50,40 32768 163839 131072 64.0M c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary /dev/mmcblk0p2 * 16,81,2 277,102,17 262144 4456447 4194304 2048M 83 Linux Partition 2 does not end on cylinder boundary /dev/mmcblk0p3 277,102,18 1023,254,63 4456448 31115263 26658816 12.7G 83 Linux Partition 3 does not end on cylinder boundary Disk /dev/nvme0n1: 233 GB, 250059350016 bytes, 488397168 sectors 2543735 cylinders, 12 heads, 16 sectors/track Units: cylinders of 192 * 512 = 98304 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/nvme0n1p1 1,0,1 907,11,16 2048 488397167 488395120 232G 83 Linux #

    Oben sieht man eine funktionierende WLan-Verbindung, das LAN-Kabel war entfernt. Unten sieht man die PCIe NVMe SSD, gemountet nach /mnt und Inhaltsausgabe.

    Das sollte beweisen, das der Ansatz der Lösung funktioniert. Leider kann ich nicht sagen, das es zum jetzigen Zeitpunkt stabil läuft. Ich habe einfach so Reboots, kann den Fehler aktuell aber nicht fangen. Mal sehen ob ich noch was finde.

    Aber, es ist ein Anfang!

  • 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

    PCI-e X4 to M.2/NGFF NVMe SSD Interface Card

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

    Wiki zum ROCKPro64 veröffentlicht!

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