TockOS Hail: Difference between revisions
(→TockOS) |
|||
Line 4: | Line 4: | ||
'''Idee''' |
'''Idee''' |
||
Bei Tock handelt es sich um ein Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben: |
Bei Tock handelt es sich um ein open-source Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben: |
||
1. Compile-Time Memory-Safety durch den Rust Compiler |
1. Compile-Time Memory-Safety durch den Rust Compiler |
Revision as of 10:41, 12 October 2022
TockOS
Idee
Bei Tock handelt es sich um ein open-source Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben:
1. Compile-Time Memory-Safety durch den Rust Compiler
2. Nutzung von Speicherschutzeinheiten um Anwendungen vom Kernel zu isolieren
Implementierungen
Insbesondere existieren bisher 2 Implementierung von Bibliotheken, welche eine Schnittstelle für die Anwendungsentwicklung in Tock zur Verfügung stellen. Zum einen die libtock-c, welche C-Bindings bereitstellt und die libtock-rs, welche direkt Rust-Bindings fr die Anwendungentwicklung bereitstellt.
Weitere Informationen zu Tock sind in der Dokumentation des Github Repositories von Tock zu finden.
Prozessmanagement
Findet in einer Anwendung ein fehlerhafter Speicherzugriff statt, der zur Compile-Zeit nicht erkannt wird, so crasht nicht nur die Anwendung selbst. Zusätzlich wird im Kernel von TockOS eine panic ausgelöst, welche den Kernel ebenfalls zum Absturz bringt, sodass danach ein Reset erforderlich ist. Der Kernel entscheidet letztendlich, wie er mit der Applikation verfährt.
Dabei wird nach der Art des Fehlers entschieden, wie der Kernel handelt:
fn set_fault_state(&self) {
// Use the per-process fault policy to determine what action the kernel
// should take since the process faulted.
let action = self.fault_policy.action(self);
match action {
FaultAction::Panic => {
// process faulted. Panic and print status
self.state.update(State::Faulted);
panic!("Process {} had a fault", self.process_name);
}
FaultAction::Restart => {
self.try_restart(None);
}
FaultAction::Stop => {
// This looks a lot like restart, except we just leave the app
// how it faulted and mark it as `Faulted`. By clearing
// all of the app's todo work it will not be scheduled, and
// clearing all of the grant regions will cause capsules to drop
// this app as well.
self.terminate(None);
self.state.update(State::Faulted);
}
}
}
Aktuell ist im Kernel festgelegt, dass falls Apps abstürzen, dann auch der Kernel durch ein von selbst ausgelöstes PANIC crasht. Damit soll es für die Entwickler einfacher ist, die Apps zu debuggen. Daher hier ein Ausschnitt aus dem Kernel, welcher genau diese Fehler erzeugt.
// Configure application fault policy
let fault_policy = static_init!(
kernel::process::ThresholdRestartThenPanicFaultPolicy,
kernel::process::ThresholdRestartThenPanicFaultPolicy::new(4)
);
Somit wäre es also leicht möglich, dem Kernel andere Handlungsanweisungen zu geben, falls eine App crasht. Aktuell ist der Panic gesetzt, da es sich hierbei um ein Development Board handelt. Es wäre aber auch einach möglich, das falls eine App crasht, der Prozess, in dem die App läuft, zu terminieren und den Kernel einfach weiterlaufen zu lassen. Diese Einstellungen im Kernel sind spezifisch für jedes Board in einer Konfigurationsdatei editierbar.
Tockloader
Der Tockloader dient dazu, kompilierte Binärdateien auf den Flash-Speicher eines Chips zu laden. Außerdem kann darüber weiterhn mit TockOS kommuniziert werden, welches ebenfalls auf einem solchen Chip laufen muss.
Initialisierung (Linux)
Vor der Installation des Tockloaders müssen zuerst einige wichtige Tools installiert werden:
Rust:
$ curl https://sh.rustup.rs -sSf | sh
Compiler für Cortex-M-Boards:
$ sudo apt install gcc-arm-none-eabi
Nun kann auch der Tockloader installiert werden:
$ pip3 install -U --user tockloader
Compile Kernel
Zusätzlich kann man noch den Tock-Kernel installieren und kompilieren, um ggf. den Kernel auf dem Board zu updaten:
$ git clone https://github.com/tock/tock
Anschließend in das Verzeichnis wechseln und kompilieren:
$ make
Letztendlich kann der neu kompilierte Kernel auch auf das Board geflasht werden.
$ tockloader flash
Bedienung
Hier sind ein paar nützliche Befehle aufgelistet, um Apps mithilfe des Tockloaders mit libtock-c zu installieren/deinstallieren und den Status des Systems abzufragen:
- Apps installieren:
$ tockloader install
- Apps deinstallieren (löscht alle installierten Apps):
$ tockloader erase-apps
- Von serial output lesen:
$ tockloader listen
- Alle installierten Apps anzeigen:
$ tockloader list
- Alle Befehle anzeigen lassen:
$ tockloader help
libtock-c
Die Blbiothek libtock-c ermöglicht es, Anwendungen in C für TockOS zu schreiben, indem dafür die notwendigen C-Bindings zur Verfügung gestellt werden. Dabei werden bereits einige Beispiele für Anwendungen bereitgestellt, welche direkt kompiliert und direkt über den Tockloader installiert werden können. Die libtock-c baisert auf einer eigenen Implementierung der C-Standardbibliothek für Embedded-Systeme, welche auf den Namen 'newlib' getauft wurde und mit der libtock-c mitgeliefert wird. Von daher ist es inherent nicht möglich, den POSIX-Standard einzuhalten während der Entwicklung von Anwendungen mit dieser Bibliothek. Zusätzlich gibt es noch Erweiterungen für Lua und C++, welche ebenfalls direkt mitgeliefert werden.
Beispiel-Apps installieren
Zunächst benötigt man die libtock-c:
$ git clone https://github.com/tock/libtock-c.git
Anschließend in das Verzeichnis wechseln:
$ cd libtock-c/examples
Nun kann eine Beispiel-App ausgewählt werden (z.B. Blink):
$ cd blink
Die Binärdatei des Beispiels kann nun mit 'make' gebaut werden:
$ make
Nun muss diese nur noch mithilfe des Tockloaders installiert werden:
$ tockloader install
Anschließend sollte die App ausgeführt werden (im Falle von Blink sollte die LED aufleuchten).
libtock-rs
Ähnlich zur libtock-c stellt libtock-rs das Rust-Userland von Tock als Rust-Library dar. Bisher sind die Rust-Analoge der alarm-, buttons- und console-APIs verfügbar, weiterhin gibt es Unterstützung für die Konsole des Tock-Kernels und ein Debug-Interface. Um die libtock-rs zu verwenden, muss man einige Eigenheiten der Build-Umgebung beachten: Es sind einige spezielle Flags an rustc vonnöten, welche die Kompilierung für die entsprechenden ARM-Targets ermöglichen und das Linking kontrollieren. Zu finden sind diese Optionen in libtock-rs/.cargo/config, wo auch der mit der Library mitgelieferte "Runner" konfiguriert wird. Dieser ist dafür verantwortlich, die als ELF im cargo-Buildprozess kompilierte Binary in ein Tock Application Bundle (.tab) umzuwandeln, welches dann ebenso mit dem Runner auf das Board geflasht werden kann. Ein typisches Projekt könnte so aussehen:
app
|
+- .cargo
| |
| +- config (mit Linker- und Runner-Konfiguration)
|
+- runner (aus libtock-rs übernommen)
|
+- src (Quellcode der App)
|
+- Cargo.toml:
| [package]
| ...
| [dependencies]
| libtock = { path = "<relativer Pfad zu libtock-rs>" }
| libtock_buttons = { path = "<relativer Pfad zu libtock-rs>/apis/buttons" } # Pro benutzter API von libtock
| ...
| [...]
| ...
| [workspace]
| members = [ "runner" ] # Um den Runner sichtbar zu machen
|
+- build.sh:
export LIBTOCK_PLATFORM=hail # Plattform setzen
cargo build --release --target thumbv7em-none-eabi # Projekt kompilieren
cargo run -p runner --relase target/thumbv7em-none-eabi/release/<App-ELF> --deploy=tockloader # In .tab konvertieren & flashen
Mit dieser Projektstruktur kann man einfache Rust-Apps für Tock programmieren. Es ist jedoch zu beachten, dass das Rust-Userland von libtock-rs nur mit Tock 2.0 funktioniert, wozu wir einen entsprechend neuen Tock-Kernel kompilieren und flashen mussten. Dies hat die Kompatibilität mit Teilen des libtock-c-Userlands zerstört, viele Apps waren aber weiterhin funktionsfähig.
Für das im Board verfügbare Bluetooth-Radio gab es in libtock-rs bislang keine API, daher haben wir im Zuge des Projektes begonnen, eine solche zu implementieren, wobei wir uns recht eng an die C-Implementierung in libtock-c gehalten haben.
Hail Board
Hail ist ein speziell für Tock im Jahre 2017 entwickeltes Board für IoT-Development. Es operiert mit dem vollständig in Rust geschriebenen open-source Betriebssystem TockOS. Zudem exisiert auch ein in Rust geschriebener Bootloader für dieses Board, welcher allerdings augrund eines zu hohen Aufwands für die Entwickler nicht mehr open-source verfügbar ist.
Komponenten des IoT-Boards
Das Tock Hail IoT-Development Board besitzt folgende Komponenten mit folgenden Funktionen:
Name | Spezifikation | Beschreibung | Technische Details |
---|---|---|---|
SAM4L Cortex-M4 | 48 - 120 Mhz, 32 - 160 kB RAM, 128-2048 kB Flash Memory | Microcontroller für sehr energiesparende Embedded-Systeme, ARM CPU | Dokumentation SAM4L-Package |
nRF51822 BLE Radio | 2.4 Ghz, 16/32 kB RAM, 128/256 kB | Das BLE (Bluetooth Low Energy) Radio ist in der Lage, zu anderen Geräten Bluetooth-Verbindungen aufzubauen. | Dokumentation |
SI7021 Temperature and Humidity Sensor | - | Messung von Temperatur und Luftfeuchtigkeit | - |
ISL29035 Light Sensor | 16-Bit ADC, 11s - 105ms RT | Messung von Helligkeit in Lumen | Dokumentation |
FXOS8700CQ 6-axis Accelerometer and Magnetometer | 6-axis e-compass (T range), acceleration, ODR 1.5 Hz - 800 Hz | Sensor zur Bestimmung von Drehungen, Geschwindigkeit etc. Andwendung für digitale Kompasse, Bewegungserkennung oder Erkennung der Orientierung des Geräts. | Dokumentation |
RGB LED | 3 LEDs (R,G,B) | Ansteuerbare LED mit 3 Kanälen (rot,grün,blau) | - |
User push-button | - | Programmierbarer Knopf (sehr klein) | - |
Photon Pinout
Label | Beschreibung |
---|---|
A0-A5 | Analog-to-Digital Pin, |
DAC | Digital-to-Analog Output, kann als digitaler Pin oder DAC genutzt werden |
WKP | Wakeup-Pin, um Modul aus Sleep-Modus zu reaktivieren |
RX | Dient als UART (Universal Asynchronous Receiver / Transmitter) RX, kann aber auch als digitaler GPIO genutzt werden |
TX | Dient als UART (Universal Asynchronous Receiver / Transmitter) TX, kann aber auch als digitaler GPIO genutzt werden |
GND | Ground-Pin, für Spannungmessung |
VIN | Input/output Pin mit (3.6-) |
D0-D7 | Digitale GPIO Input Pins, alternativ auch digitale GPIO Pins |
3V3 | 3V Spannung anliegend, Stromversorgung |
RST | Reset-Pin |
VBAT | Batterie zum sichern von Registern und SRAM und RTC, wenn Strom von 3V3 nicht verfügbar |
Ansteuerbare Pins
Über GPIO (General Purpose Input/Output) lassen sich die einzelnen Pins im Programm ansteuern. Dabei scheint es mehrere Modis zu geben, in denen die Konfiguration der Pins laufen kann:
- JTAG (Joint Test Action Group): Debug- und Testmodus für Hardware und integrierte Schaltungen. Damit können einzelne Komponenten auf Funktionalität getestet werden wobei spezielle Teile von ICs erst dann aktiviert werden.
- SPI1 (Serial Peripheral Interface): Hierbei handelt es sich um ein Bus-System, mit dem digitale Schaltungen nach dem Master-Slave-System miteinander verbunden werden können. Dabei können viele Teilnehmer gleichzeitig über diesen Bus verbunden werden und der Master legt fest, mit welchem Slave er dabei kommunizieren will.
- TIM3: General Purpose Timer
Dabei ist es uns gelungen, in der aktuellen Konfugration die Pins D0,D1,D6 und D7 anzusteuern. Die Pins D2 und D5 waren immer aktiv dabei.
Die Pins lassen sich folgendermaßen über das GPIO-Interface ansteuern dabei:
#include <stdio.h>
#include 'ble.h'
#include 'led.h'
#include 'timer.h'
// Set to test a certain pin
#define PIN_NUM 0
int main (void) {
// LED will light up if a certain pin is activated
gpio_set(PIN_NUM);
gpio_enable_output(PIN_NUM);
led_on(DRIVER_NUM_LEDS);
delay_ms(5000);
gpio_disable(PIN_NUM);
gpio_clear(PIN_NUM);
led_off(DRIVER_NUM_LEDS);
return 0;
}
Dabei haben sich folgende Pins mit einem bestimmten Index ansteuern lassen:
Index | ID |
---|---|
0 | D0 |
1 | D1 |
2 | D6 |
3 | D7 |
BLE API für Rust
Aktuell besitzt das Rust-Userland in der libtock-rs keine BLE-Bindings, um damit in Anwendungen vernünftig Bluetooth-Verbindungen aufzubauen und darüber zu kommunizieren. Daher haben wir uns es als ein Teil unseres Projekts zur Aufgabe gemacht, genau solche Bindings für das Userland in Rust zu schreiben. Dazu ist es notwendig, die vom Treiber bereitgestellten Funktionen und Systemrufe in die neue API für das Userland einzubinden. Alle Treiber von TockOS sind als sog. "Capsules" geschrieben, welche dann direkt mit dem Kernel kommunizieren:
Die finale API beinhaltet Funktionen zum Starten und Stoppen des BLE-Advertisings.
Dennoch werden für eine korrekte Funktionalität noch viele weitere Bibliotheken benötigt, um mit dem BLE-Interface sinnvoll arbeiten zu können. Diese sind bisher nur in der libtock-c vorhanden (im Verzeichnis 'simple_ble'). Der Aufwand für diese zusätzlichen Bibliotheken Rust-Bindings zu entwickeln, wäre um ein vielfaches größer. Zwar existieren Rust Crates für BLE, welche eine API zur Verfügng stellen, jedoch leider nicht für dieses Modell des BLE-Radios, sodass es schwierig ist, jenes im Rust-Userland zum Laufen zu bekommen.
TO-DO
1. GPIO Communication via external devices
2. BLE userland bindings
3. Kernle panic debuggen