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

    [V] RockPro64 V2.1

    Frank's Resterampe
    1
    0 Stimmen
    1 Beiträge
    107 Aufrufe
    Niemand hat geantwortet
  • N

    ROCKPro64: NAS mit PCI-e SATA-III Aufrüsten

    ROCKPro64
    13
    0 Stimmen
    13 Beiträge
    866 Aufrufe
    N

    @frankm Alles Klar!
    Wie schon erwähnt, für meine Zwecke rechts! Die Jahre über hat gute Dienste geleistet (PCI-e und HDD) und wird hoffentlich auch noch ein paar Jahre bis zum nächsten Umbau tun!
    Vielen Dank!

  • FrankMF

    OpenWrt

    Images
    1
    0 Stimmen
    1 Beiträge
    182 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Booten von USB3

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

    ROCKPro64 - RP64.GPIO

    Angeheftet Verschoben Hardware
    6
    0 Stimmen
    6 Beiträge
    6k Aufrufe
    FrankMF

    Hallo zusammen,

    da ich weiß das dieser Artikel recht beliebt ist, wollen wir den heute mal aktualisieren. Vieles aus den vorherigen Beiträgen passt noch. Es gibt aber kleine Anpassungen.

    Hardware ROCKPro64v21. 2GB RAM Software Kamils Release 0.10.9 Linux rockpro64 5.6.0-1132-ayufan-g81043e6e109a #ayufan SMP Tue Apr 7 10:07:35 UTC 2020 aarch64 GNU/Linux Installation apt install python

    Danach laden wir das Projekt

    git clone https://github.com/Leapo/Rock64-R64.GPIO

    PIN Nummern anpassen

    cd Rock64-R64.GPIO/R64 nano _GPIO.py

    Datei ergänzen

    # Define GPIO arrays #ROCK_valid_channels = [27, 32, 33, 34, 35, 36, 37, 38, 64, 65, 67, 68, 69, 76, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 96, 97, 98, 100, 101, 102, 103, 104] #BOARD_to_ROCK = [0, 0, 0, 89, 0, 88, 0, 0, 64, 0, 65, 0, 67, 0, 0, 100, 101, 0, 102, 97, 0, 98, 103, 96, 104, 0, 76, 68, 69, 0, 0, 0, 38, 32, 0, 33, 37, 34, 36, 0, 35, 0, 0, 81, 82, 87, 83, 0, 0, 80, 79, 85, 84, 27, 86, 0, 0, 0, 0, 0, 0, 89, 88] #BCM_to_ROCK = [68, 69, 89, 88, 81, 87, 83, 76, 104, 98, 97, 96, 38, 32, 64, 65, 37, 80, 67, 33, 36, 35, 100, 101, 102, 103, 34, 82] ROCK_valid_channels = [52,53,152,54,50,33,48,39,41,43,155,156,125,122,121,148,147,120,36,149,153,42,45,44,124,126,123,127] BOARD_to_ROCK = [0,0,0,52,0,53,0,152,148,0,147,54,120,50,0,33,36,0,149,48,0,39,153,41,42,0,45,43,44,155,0,156,124,125,0,122,126,121,123,0,127] BCM_to_ROCK = [43,44,52,53,152,155,156,45,42,39,48,41,124,125,148,147,124,54,120,122,123,127,33,36,149,153,121,50]

    Abspeichern.

    Datei test.py anlegen

    nano test.py

    Inhalt

    #!/usr/bin/env python # Frank Mankel, 2018, LGPLv3 License # Rock 64 GPIO Library for Python # Thanks Allison! Thanks smartdave! import R64.GPIO as GPIO from time import sleep print("Output Test R64.GPIO Module...") # Set Variables var_gpio_out = 156 var_gpio_in = 155 # GPIO Setup GPIO.setwarnings(True) GPIO.setmode(GPIO.ROCK) GPIO.setup(var_gpio_out, GPIO.OUT, initial=GPIO.HIGH) # Set up GPIO as an output, with an initial state of HIGH GPIO.setup(var_gpio_in, GPIO.IN, pull_up_down=GPIO.PUD_UP) # Set up GPIO as an input, pullup enabled # Test Output print("") print("Testing GPIO Input/Output:") while True: var_gpio_state_in = GPIO.input(var_gpio_in) var_gpio_state = GPIO.input(var_gpio_out) # Return State of GPIO if var_gpio_state == 0 and var_gpio_state_in == 1: GPIO.output(var_gpio_out,GPIO.HIGH) # Set GPIO to HIGH print("Input State: " + str(var_gpio_state_in)) # Print results print("Output State IF : " + str(var_gpio_state)) # Print results else: GPIO.output(var_gpio_out,GPIO.LOW) # Set GPIO to LOW print("Input State: " + str(var_gpio_state_in)) # Print results print("Output State ELSE: " + str(var_gpio_state)) # Print results sleep(0.5) exit() Beispiel

    Bild Text

    Wenn der Taster im Bild betätigt wird, soll die LED blinken.

    Wir benutzen folgende Ein- Augänge des ROCKPro64.

    # Set Variables var_gpio_out = 156 var_gpio_in = 155

    Das heißt:

    an Pin 1 (3,3V) kommt eine Strippe des Tasters an Pin 29 (Input) kommt eine Strippe des Tasters an Pin 31 (Output) kommt der Plus-Pol der LED an Pin 39 (GND) kommt der Minus-Pol der LED

    Somit wird auf den Eingang (Pin 29) bei Betätigung des Tasters 3,3 Volt angelegt. Damit wird dann der Eingang als High (1) erkannt. Die LED wird über den Ausgang (Pin 31) gesteuert.

    Starten kann man das Script mit

    python test.py

  • FrankMF

    Eure Meinung zum ROCKPro64 ?

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

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

    Verschoben Tools
    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