Hardware-Referenz

LibreScoot läuft auf zwei ARM-Boards im Roller: dem MDB (Fahrzeugsteuerung) und dem DBC (Dashboard-UI und Navigation).

MDB – Middle Driver Board

Der zentrale Fahrzeug-Controller. Spricht per CAN mit der ECU, liest Keycards und Akkus per NFC und verwaltet Mobilfunk/GPS.

KomponenteDetails
SoCARMv7 Cortex-A
RAMDDR3
SpeichereMMC (A/B-Mender-Partitionen)
CAN-BusECU-Kommunikation (Bosch-/Votol-Motorcontroller)
NFCPN7150 (Keycard-Authentifizierung + BMS-Kommunikation mit dem Akku)
4G-ModemSIM7100E (Mobilfunk + GPS)
Bluetooth/nRFnRF52840-Co-Prozessor per USOCK (UART + CBOR)
IP-Adresse192.168.7.1 (USB-Ethernet-Gadget)

nRF52840-Co-Prozessor

Der nRF52840 kümmert sich um Bluetooth Low Energy und LED-Steuerung. Er kommuniziert mit dem MDB über ein USOCK-Protokoll (UART-Framing mit CBOR-Encoding). Der bluetooth-service auf dem MDB besitzt diese Schnittstelle und stellt den BLE-Status in Redis bereit.

DBC – Dashboard Computer

Betreibt das Dashboard-UI (Qt auf 480×480-Display) und die Offline-Navigation.

KomponenteDetails
SoCNXP i.MX6DL – Dual Cortex-A9 @ 800 MHz
Display480×480 paralleles RGB565 mit 59,1 Hz
GPUVivante GC2000 (3D, etnaviv) + GC355 (2D)
UmgebungslichtOPT3001-Sensor, gelesen vom dbc-backlight-service für Auto-Helligkeit
SpeichereMMC (A/B-Mender-Partitionen + Nutzerpartition /data)
IP-Adresse192.168.7.2 (USB-Ethernet-Gadget, über das MDB)

Display-Pipeline

Die IPU (Image Processing Unit) bedient das parallele Display über /dev/fb0. Die GPU rendert auf eine EGL-Surface über den Render-Node (/dev/dri/renderD128) und kopiert das Ergebnis in den Framebuffer. GPU und Display sind separate Subsysteme; etnaviv hat keine KMS-Connector.

Netzwerk-Topologie

MDB und DBC sind per USB-Ethernet-Gadget verbunden. Das MDB betreibt eine Redis-Instanz; DBC-Services verbinden sich über das Netzwerk damit.

MDB 192.168.7.1

Redis :6379
SSH :22

USB-Ethernet
DBC 192.168.7.2

Redis-Client → 192.168.7.1:6379
SSH :22

Von einem externen Rechner erst auf das MDB einloggen, dann aufs DBC jumpen:

ssh root@<mdb-ip>               # MDB direkt
ssh -J root@<mdb-ip> root@192.168.7.2  # DBC per Jump-Host

UART-Debug-Zugriff

Beide Boards bieten einen 3-poligen UART-Debug-Header mit 115200 Baud, 8N1, ohne Hardware-Flusskontrolle.

MDB-Debug-UART

PinSignal
Pin 1GND
Pin 2TXD (MDB sendet)
Pin 3RXD (MDB empfängt)

Baudrate: 115200

DBC-Debug-UART

6-poliger Header an der Unterseite des DBC, neben den Hauptsteckern. Erreichbar, ohne das Gehäuse zu öffnen.

PinSignal
Pin 1 (quadratisch)GND
Pin 2—
Pin 3—
Pin 4RXD (DBC empfängt)
Pin 5TXD (DBC sendet)
Pin 6—

Baudrate: 115200

Spannung: 3,3-V-Logik – kein 5 V

Wenn du keine Ausgabe bekommst, tausch Pin 4 und 5.

Spannungshinweis: Beide UART-Header arbeiten mit 3,3-V-Logik. Ein 5-V-Adapter beschädigt die Hardware.

Boot-Ablauf

MDB-Boot-Reihenfolge

  1. U-Boot lädt aus der eMMC-Boot-Partition
  2. Kernel entpackt sich und initialisiert die Hardware
  3. systemd startet Services in Abhängigkeitsreihenfolge
  4. vehicle-service geht in den Zustand stand-by, der Roller ist bereit für die Keycard

DBC-Boot-Reihenfolge

  1. U-Boot (in der eMMC-Boot-Partition mmcblk3boot0) lädt Kernel und DTB aus /boot/ der aktiven Rootfs-Partition
  2. Kernel initialisiert i.MX6DL, IPU und etnaviv-GPU
  3. Boot-Animation startet früh (~T+3s), wird von ThorVG nach /dev/fb0 gerendert und läuft bis multi-user.target
  4. scootui-qt Qt-Dashboard startet per dbc-dispatcher
  5. Die /data-Partition (mmcblk3p4) wird ~T+7s nach fsck gemountet, steht frühen Services also noch nicht zur Verfügung

Mender-A/B-Partitionen

Beide Boards nutzen Mender für OTA-Updates mit atomarem A/B-Partitionswechsel. Welche Partition aktiv ist, wählt U-Boot bei jedem Boot. Ein fehlgeschlagenes Update rollt beim nächsten Boot automatisch auf die vorherige Partition zurück.

PartitionInhalt
mmcblk?p1U-Boot-Environment
mmcblk?p2Rootfs A (aktiv)
mmcblk?p3Rootfs B (inaktiv / Update-Ziel)
mmcblk?p4/data, persistente Nutzerdaten (Karten, Einstellungen)

← Architektur Services-Referenz →