Umbau auf Raspberry Pi 3

[enager]

Aktuell ist ein Banana-Pi Pro am laufen. Hier läuft auch alles zufriedenstellend (abgesehen von den ständigen Empfangsabbrüchen bei den NOAA-Satelliten). Aber mich hat die Faszination des Neuen erwischt. Mit rund 35€ ist der Raspberry Pi 3 angenehm günstig und er lockt mit einer 64Bit Quadcore Prozessor. Leider hängt beim RPi3 alles an einem Bus. SD-Card-Reader, USB und Netzwerk, läuft alles auf einer Leitung, während beim Banana-Pi wenigstens der SATA-Anschluss seine eigene Leitung zur CPU hat. Dies ermöglichte hier hohe Datenzugriffsraten. Beim RPi3 hingegen ist mit einem Abfall der Schreib- und Lesegewschwindigkeit zu rechnen, wenn nebenbei noch Daten übers Netzwerk oder dem USB-Port ausgetauscht werden. Allerdings ist der Datendurchsatz im Falle meiner Wetterstation nicht sonderlich wichtig. Die paar KiB an Wetterdaten, welche alle 3 Minuten anfallen... die Webcambilder haben auch keine großartige Größe und für den Upload der Zeitraffervideos bleibt viel Zeit. Also hat Datengeschwindigkeit im Falle der Wetterstation keine besonders hohe Priorität. Rechengeschwindigkeit hingegen schon deutlich eher. Die Satellitenbilder wollen dekodiert werden, die Bildbearbeitung bei den Webcambildern bedeutet Rechenaufwand, ebenso wie die Erstellung der Zeitraffervideos. Und durch das Plus an Rechenleistung rückt auch die Dekodierung der Meteor-Satbilder in Rechweite. Zwar gibt es noch keinen Dekoder, welcher die Rohdaten der Meteor-Satelliten in Bilder dekodiert, für Linux, aber zumindest kann die aufgenommene WAVE-Datei schonmal auf dem RBi3 in eine RAW-Rohdatendatei gewandelt werden. Das spart beim abendlichen Dekodieren der Bilder etwa 15 Minuten. Auch dem RPi3 werde ich sein System auf eine per USB angeschlossene 2,5 Zoll Sata-Platte aufspielen. Denn die SD-Karten haben nach wie vor eine begrenzte Anzahl an Schreib/Lesezyklen je Speicherzelle, so dass diese im Gegensatz zu konventionellen Festplatten nicht endlos gelesen und beschrieben werden können.

Insgesamt bin ich sehr auf den RPi3 gespannt, welcher im Moment irgendwo in einem Pollin-Paket auf dem Postweg unterwegs ist. Ich bin gespannt um wie viel er schneller ist, als der Banana-Pi. Und ich werde hier, in diesem Beitrag ausgiebig über seine Einrichtung als Wetterstationsrechner berichten.

[enager]

Der Raspberry Pi 3 ist zunächst einmal deutlich schneller als der Banana-Pi. Allerdings verwundert mich das nicht, da er 2 CPU-Kerne mehr hat, sowie eine 64Bit Prozessorarchitektur. Allerdings hat es mich die letzten Tage extrem aufgehalten, dass System auf einer USB-Festplatte zum laufen zu bekommen. Mehrere Versuche habe ich mit Sata-Festplatten unternommen, angeschlossen über einen Sata-USB2.x-Konverter. Hier sind die USB-Konverter offenbar zu langsam um in der vom Raspberry akzeptierten Zeit eine gültige Antwort zu geben. Anders sah es dann mit einer 40GB IDE-Festplatte meines alten Laptops aus. Diese habe ich über einen IDE-USB2.x Konverter angeschlossen. Hier wurde die Festplatte von "Berryboot" erkannt und konnte zur Systeminstallation ausgewählt werden. Auch möglich war die Verwendung einer 500GB USB3.0 Sata-Festplatte. Mit dieser habe ich es dann auch gestern Abend geschafft, dass der Raspberry von dieser ganz ohne SD-Karte bootet. Hierzu benötigt man spezielle Dateien in der Boot-Partition der SD-Karte, welche später auf eine FAT32 BootPartition der USB-Festplatte kopiert werden. Ein zu ergänzender Eintrag in die cmdline.txt Datei auf der FAT32 Partition, aktiviert die Möglichkeit des Raspberry von USB-Medien zu booten. Hierzu ist der Raspberry einmal mit diesem neuen Eintrag über die SD-Karte zu starten, da nur beim booten, diese eine Einstellung geändert wird. Die gesamte Prozedur, um den RPI3 von USB-Medien ganz ohne SD-karte booten zu lassen, ist hier zu finden.

Wie gesagt, es funktioniert. Allerdings hatte ich gestern Abend das System zuvor nicht geupdated, wesswegen Maus und Tastatur nicht erkannt wurden. Kurioser Weise funktionierten Maus und Tastatur beim Start von SD-Karte noch. Offenbar werden beim Start von USB-Medien andere Treiber verwendet, als beim Start von SD-Karte.

[enager]

Endlich habe ich es hinbekommen. Der Raspberry Pi 3 bootet nun allein von der USB-Festplatte.

Aber alles der Reihe nach.

• Als erstes muss man sich wie gewohnt ein ganz normales Debian-Jessie Image ziehen.

• Dieses wird mittels "Win32DiskImager" auf eine mind. 8GB große Mirco-SD Karte kopiert.

• Die Bootpartition ist FAT32 und kann daher auh unter Windows gelesen und beschrieben werden. Und dies ist auch ganz gut. Denn so kann die Datei "config.txt" auch gleich editiert werden. Dies ist notwendig um die USB-Boot-Funktin zu aktivieren. Denn diese ist von Werk aus deaktiviert, so dass der RPI3 nur von SD-Karte bootet.

• Auf der FAT32 Partition "BOOT", befindet sich wie gesagt die Datei "config.txt". Dieser ist der folgende Eintrag in der letzten Zeile hinzu zu fügen:
  

  Code: Alles auswählen

  program_usb_boot_mode=1
  Und speichern.

• Nun ist der Raspberry mit dieser SD-Karte zu booten. Beim Booten wird durch die eingefügte Zeile ein Bit in der RPI-Hardware dauerhaft geändert, welches das Booten von USB-Medien aktiviert.

• Sobald der Desktop gestartet ist, kann unter "Einstellungen ->Raspberry-Pi-Konfiguration", alternativ in der Konsole mittels

  Code: Alles auswählen

  sudo raspi-config
  das Tastaturlayout auf deutsch umgestellt werden. Denn von Hause aus, ist beim Rasperry die amerikanische Tastatur aktiv.

• Nun ist das Terminal zu starten und mittels
  

  Code: Alles auswählen

  sudo apt-get update
sudo apt-get upgrade
  das System zu aktualisieren. Dies ist notwendig, da erst ab dem Release 11-2016 Maus und Tastatur auch beim Booten von einem USB-Medium funktionieren.

• Nun muss mittels

  Code: Alles auswählen

  sudo BRANCH=next rpi-update
  auch die Firmware des RPI aktualisiert werden. Denn erst die hiermit heruntergeladene Firmware unterstützt das Booten von USB-Medien. Geschieht dies nicht, wird beim Booten zwar kurz auf die externe Festplatte zugegriffen, kurz danach wird der USB-Anschluss aber wieder deaktiviert und das System entsprechend nicht von der externen Festplatte geladen.

• Kommen wir jetzt zur externen Festplatte. Bei mir haben sich Festplatten mit USB3.0 Anschluss als geeignet erwiesen. Alle hier vorhandenen Daten sind, sofern wichtig, zu sichern, da diese nachfolgend gelöscht werden. Da diese Festplatten meist Ströme von 1 Ampere ziehen, ist hier ein aktiver USB-Hub mit mind. 1,5A Netzteil angeraten. Ich stecke die beiden Netzteile (Raspberry + akt. USB-Hub) in eine schaltbare Steckdose, so dass beide Netzteile zeitgleich eingeschaltet werden. Im abgeschalteten Zustand ist die externe Festplatte in den USB-Hub zu stecken und dieser wiederum am RPI3 anzustecken. Beide Netzteile werden über die schaltbare Steckdose zeitgleich eingeschaltet. Der RPI3 bootet wie gewohnt von der SD-Karte, da auf der externen Festplatte noch kein System aufgespielt wurde.

• Weiter geht es mit dem überspielen des Systems von der SD-Karte auf die externe Festplatte. Hierbei kommt das Terminal zum Einsatz:

• Ist der Raspberry hoch gefahren, benötigen wir Gparted, welches ganz einfach mittels

  Code: Alles auswählen

  sudo apt-get install gparted
  installiert wird. Bevor nachfolgend das Dateisystem für die externe Festplatte erstellt wird, sollte Gparted kurz in der Desktop-Version gestartet werden um die Laufwerksbezeichnung zu prüfen. Ist nur eine einzige externe Festplatte angeschlossen, so hat sie sie meist die Bezeichnung SDA, und ihre Partitionen entsprechend SDA1, SDA2, ... je nach Anzahl der Patiotionen. Diese Bezeichnung wird in den kommenden Schritten wichtig. Es wird immer von SDA ausgegangen, also nur einer angeschlossenen USB-Festplatte.a

• Mit Gparted wird nun die MSDOS - Tabelle erstellt:

  Code: Alles auswählen

  sudo parted /dev/sda

(parted) mktable msdos
Warning: The existing disk label on /dev/sda will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
(parted) mkpart primary fat32 0% 100M
(parted) mkpart primary ext4 100M 100%
(parted) print
Model: SanDisk Ultra (scsi)
Disk /dev/sda: 30.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  99.6MB  98.6MB  primary  fat32        lba
 2      99.6MB  30.8GB  30.7GB  primary  ext4         lba
  Der FAT32 Boot-Partition werden also 100MB zugewiesen, der ext4-Partition der restliche Speicherplatz.

• Diese Tabelle stellt die Grundlage für die beiden Dateisysteme dar, welche nachfolgend erstellt werden:

  Code: Alles auswählen

  sudo mkfs.vfat -n BOOT -F 32 /dev/sda1
sudo mkfs.ext4 /dev/sda2

• Nun existieren auf der Festplatte 2 leere Partitionen. Da fehlen also noch die Daten, welche nachfolgend von der SD-Karte herüber kopiert werden:

  Code: Alles auswählen

  sudo mkdir /mnt/target
sudo mount /dev/sda2 /mnt/target/
sudo mkdir /mnt/target/boot
sudo mount /dev/sda1 /mnt/target/boot/
sudo apt-get update; sudo apt-get install rsync
sudo rsync -ax --progress / /boot /mnt/target
  Es wird also zuerst ein neuer Ordner namens "target" erstellt, in welchem die Partition SDA2 (die ext4-Partition), gespiegelt wird. Auf dieser Partition wird nachfolgend der Ordner "Boot" erstellt, in welchen die FAT32-Partition gespiegelt wird. Diese Vorgehensweise hat den Vorteil, dass die Boot-Dateien nicht nur in die Boot-Partition geschrieben werden, sondern nochmal als Sicherungskopie auf der EXT4-Partition im Ordner "BOOT" abgelegt werden. Durch den Zusatz "--progress" wird der Verlauf des kopierens angezeigt, so dass man zumindest sieht, ob noch fleißig kopiert wird. Leider fehlt eine Prozentanzeige, so dass man nur hoffen kann, dass die Tasse Kaffee oder Tee nicht schon vor Fertigstellung des Kopiervorgangs leer ist .

Ist der Kopiervorgang erfolgreich beendet worden, kann man mit

Code: Alles auswählen

sudo poweroff

den Raspberry herunter fahren. Nach dem offensichtlichen Abschalten, würde ich dem Raspberry noch runde 20 Sekunden Zeit einräumen um sicher zu gehen, dass die externe Festplatte keine Dateioperationen mehr durchführt und erst dann die Steckdose abschalten. Nun kann die Micro-SD Karte entnommen und die Steckdose wieder eingeschaltet werden. Der Raspberry startet und nach kurzer Zeit fängt die LED der externen Festplatte an zu blinken. Es erscheint ein bunter Bilderschirm, gefolgt einem schwarzen Bildschirm mit 4 Himbeeren (dem Logo des Raspberry). Danach erscheint ein weisses Bild mit dem Titel "Welcome to Pixel" mit der Raspberry-Himbeere in der Bildmitte. Unten rechts steht das aktuelle Release, welches mindestens von November 2016 stammen sollte. Unten links rauschen in schneller Folge die aktuell geladenen Treiber durch. Dieses Bid wird nachfolgend von einem schwarzen Bildschirm abgelöst, welchem die Desktopoberfläche vom Rasbian System folgt. Der gesamte Bootvorgang dauert bei mir mit frischem System nicht länger als 30 Sekunden. Beim Drücken der 3 Tasten ALT+STRG+ENTF erscheint der Taskmanager, welcher rechts 877MB als verfügbaren Arbeitsspeicher anzeigen sollte. Zeigt dieser nur 117MB an, so ist über die Konsole der Befehl

Code: Alles auswählen

sudo BRANCH=next rpi-update

auszuführen. Hiermit wird die Firmware des Raspberry erneut herunter geladen und installiert. Sollte der Raspberry danach nicht mehr von der externen Festplatte booten, sind die Dateien "bootcode.bin" sowie "start.elf" auf der FAT32-Bootpartition mit denen aus dieser ZIP-Datei zu überschreiben. Danach sollte das System wieder von der USB-Festplatte booten und der Taskmanager sollte 877MB verfügbaren Arbeitsspeicher anzeigen. Sind es mehr als 877MB, ist der Grafikeinheit des Raspberry entsprechend weniger Arbeitsspeicher zugewiesen. Denn die CPU als auch die GPU (Zentrale Prozessoreinheit, sowie die Grafische Prozessoreinheit) teilen sich den 1GB-RAM. Der Speicher für die GPU ist über die Raspberry-Pi-Konfiguration unter der Registerkarte "Leistung" unter dem Punkt "GPU-Speicher" im Bereich von 16MB - 896MB einstellbar und steht bei mir aktuell auf 112MB. Entsprechend steht der CPU dann natürlich weniger Arbeitsspeicher zur Verfügung.

So, dass soweit. Ich hoffe ich habe alles richtig wieder gegeben, so dass es auf Anhieb funktioniert. Wer Fragen oder Anregungen hat, kann mich über WS-HoWa[at]gmx.de erreichen. Auch freue ich mich immer über GB-Einträge. Ahja, zur eigentlichen Homepage, geht es hier.

Quellen des Beitrags:
How to boot from a USB Mass Storage Device on a Raspberry Pi 3
Sowie eigene Versuche.

[enager]

Gestern Abend hatte ich nun den RPI3 an der Wetterstation. Den großen Geschwindigkeitsunterschied konnte ich nicht feststellen. Nur das die GNURadio-Programme ein völlig verzerrtes Satellitensignal aufzeichneten. WxToImg hat da noch versucht das Beste draus zu machen, aber es sieht dennoch bescheiden aus:


Auch langes herumprobieren in GnuRadio brachte keine Verbesserung. Als erstes wurde die "Audio-Sink" entfernt, da weder bei "pulse" als Audiotreiber als auch "hw:0,1" kein klares Satellitensignal zu hören war. (Es handelt sich hierbei um die GnuRadio-Scripts, welche beim Banana-Pi ohne Probleme und mit bestem Empfang funktionieren.) Damit wird das SatSignal nur noch als WAVE Datei aufgezeichnet. Vielleicht ist der Unterschied auch darin zu suchen, dass ich mir auf dem Banana-Pi damals GnuRadio aus den Sourcen heraus selbst kompiliert habe, auf dem RPI3 hingegen habe ich mir GnuRadio nur mittels "sudo apt-get install gnuradio" herunter geladen und installiert.

Da mir die Satellitenbilder recht wichtig sind und ich keine Meinung habe, da noch Tage lang herum zu probieren und viele Satellitenübergänge zu "versauen", habe ich in der Frühe noch schnell alles wieder auf den Banana-Pi zurück gebaut. Da funktioniert wenigstens alles. Mal schauen, was ich mit dem RPI3 mache.

---

Nachtrag 02.02.2017:

Mir ist eben eine Idee gekommen, warum es beim RPi3 mit dem SDR-Stick nicht funktioniert hat. Auch wenn ich die Datenrate beim Empfang der NOAA-Satelliten auf 960KBs gesetzt habe, so ist diese vielleicht noch immer zu hoch um die Daten zeitgleich im Arbeitsspeicher zwischen zu speichern oder auf der USB-Festplatte abzulegen. Kurz, der USB-Anschluss des RPi3 macht da einfach nicht mit und ist zu langsam um alles über eine Datenleitung zu quetschen.