Build-Guide

Die meisten Mitwirkenden brauchen nur einzelne Services zu bauen. Ein komplettes OS-Image baust du erst, wenn du Kernel, Yocto-Rezepte oder die Basiskonfiguration änderst.

Brauchst du einen vollständigen Build?
Wenn du einen Go-Service oder scootui-qt änderst, brauchst du kein Yocto. Binary bauen, per SSH auf den Roller kopieren, Service neu starten. Für Endnutzer*innen übernehmen OTA-Updates den Rest.

Einen Go-Service bauen

MDB und DBC laufen beide auf ARMv7-Prozessoren. Alle Go-Services cross-kompilieren auf dasselbe Ziel.

Für den Roller bauen (ARMv7)

make build        # → bin/<service-name> (ARM-Binary)

Für deinen Rechner bauen (Entwicklung)

make build-host   # → bin/<service-name> (natives Binary)

Stripped Release-Binary

make dist         # Strippedes ARM-Binary zum Ausliefern

Weitere Targets

make test         # Unit-Tests ausführen
make lint         # golangci-lint
make fmt          # gofmt
make deps         # go mod tidy + download

Manuelle Cross-Kompilierung

CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=7 \
  go build -ldflags "-w -s" -o bin/my-service ./cmd/my-service

Alle Services sind statisch gelinkt (CGO_ENABLED=0), auf dem Target werden also keine Shared Libraries gebraucht.

scootui-qt bauen

scootui-qt ist eine Qt-6/QML-Anwendung. Für die Entwicklung kannst du sie nativ unter Linux bauen und starten; für die Cross-Kompilierung auf den i.MX6 des DBC nutzt du Docker.

# Mit eingebautem Simulator auf dem Desktop laufen lassen (keine Hardware nötig)
./run-desktop.sh

# Oder manuell:
cmake -B build -DDESKTOP_MODE=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build -j$(nproc)
SCOOTUI_REDIS_HOST=none ./build/bin/scootui

# Cross-Build für ARM (i.MX6)
./cross-build.sh Release

Der Desktop-Modus enthält ein Simulator-Panel – setze SCOOTUI_REDIS_HOST=none, um Redis zu umgehen und die UI aus dem Simulator heraus zu steuern. Der Cross-Build erzeugt ein deploy-armhf/-Verzeichnis mit Binary, Qt-Plugins und einem Launcher-Skript, bereit zum Deployen per scp.

Komplettes OS-Image (Yocto)

Für komplette Image-Builds nutzen wir Docker, um eine reproduzierbare Yocto-Build-Umgebung bereitzustellen. Das Build-Skript liegt im Meta-Repo librescoot/librescoot.

Setup

git clone https://github.com/librescoot/librescoot
cd librescoot

Komplettes Image bauen

./build.sh

Das startet einen Docker-Container, checkt alle benötigten Yocto-Layer aus (inklusive meta-librescoot) und ruft bitbake auf. Das Ergebnis landet im Verzeichnis deploy/.

Einzelnes Paket bauen

PACKAGE=alarm-service ./build.sh

Sstate-Cache

Yocto nutzt einen Shared-State-Cache, um unveränderte Pakete nicht neu zu bauen. Der erste Build ist langsam (Stunden); weitere Builds einzelner Pakete sind schnell (Minuten). Den Sstate-Cache-Ordner mountest du als Docker-Volume, damit er über Builds hinweg erhalten bleibt.

Zwei Targets

Target	Hardware	Image-Name
MDB	Middle Driver Board (Haupt-Controller)	`librescoot-mdb`
DBC	Dashboard Computer (imx6DL, Display)	`librescoot-dbc`

Beide sind ARMv7 (Cortex-A-Reihe) mit musl libc.

Ein gebautes Image deployen

Die Images werden als Mender-.mender-Artefakte gepackt und lassen sich per OTA installieren:

lsc ota install /path/to/image.mender

Oder direkt auf den Roller übertragen und mit mender-update install anwenden.

Kernel & U-Boot

Kernel- und U-Boot-Änderungen brauchen einen vollständigen Yocto-Build. Das DBC nutzt einen Downstream-linux-fslc-Kernel (NXP-i.MX6-BSP). Details zum MDB-Kernel stehen in den meta-librescoot-Rezepten.

Kernel-Konfigurations-Fragmente liegen in meta-librescoot/recipes-kernel/linux/. Wo möglich, lieber .cfg-Fragmente ergänzen oder anpassen, als die komplette defconfig zu bearbeiten.

← Mitmachen Redis-API →