oreboot
1.0.0
OREBOOT ist eine nachgelagerte Gabel von Corboot, dh Oreboot ist Corboot ohne 'C'.
OreBoot ist hauptsächlich in Rost geschrieben, bei Bedarf an Montage.
OREBOOT plant derzeit nur die Unterstützung von Linuxboot -Nutzlasten.
oreboot ?
v 13
cpu_pll fa001000
cpu_axi 5000100
cpu_axi 5000100
peri0_ctrl was: f8216300
peri0_ctrl lock en
peri0_ctrl PLLs
peri0_ctrl set: f8216300
DDR3@792MHz
test OK
512M ?
NOR flash: c2/2018
load 00018000 bytes to 40000000: ➡️.
load 00fc0000 bytes to 44000000: ➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️.
load 00010000 bytes to 41a00000: ➡️.
{ɕ serial uart0 initialized
RISC-V vendor 5b7 arch 0 imp 0
==== platform CSRs ====
MXSTATUS c0408000
MHCR 00000109
MCOR 00000002
MHINT 00004000
see C906 manual p581 ff
=======================
Set up extension CSRs
==== platform CSRs ====
MXSTATUS c0638000
MHCR 0000017f
MCOR 00000003
MHINT 0000610c
see C906 manual p581 ff
=======================
timer init
reset init
ipi init
RustSBI version 0.3.1
.______ __ __ _______.___________. _______..______ __
| _ | | | | / | | / || _ | |
| |_) | | | | | | (----`---| |----`| (----`| |_) || |
| / | | | | | | | _ < | |
| | ----.| `--' |.----) | | | .----) | | |_) || |
| _| `._____| ______/ |_______/ |__| |_______/ |______/ |__|
Platform Name: T-HEAD Xuantie Platform
Implementation: oreboot version 0.1.0
[rustsbi] misa: RV64ACDFIMSUVX
[rustsbi] mideleg: ssoftstimersext (0x222)
[rustsbi] medeleg: imaialmalasmasauecallipagelpagespage(0xb1f3)
[rustsbi] mie: msoft ssoft mtimer stimer mext sext (00000aaa)
PMP0 0x0 - 0x40000000 (A,R,W,X)
PMP1 0x40000000 - 0x40200000 (A,R)
PMP2 0x40200000 - 0x80000000 (A,R,W,X)
PMP3 0x80000000 - 0x80200000 (A,R)
PMP4 0x80200000 - 0xfffff800 (A,R,W,X)
PMP8 0x0 - 0x0 (A,R,W,X)
DTB looks fine, yay!
Decompress 12375521 bytes from 0x44000004 to 0x40200000, reserved 25165824 bytes
Success, decompressed 21910144 bytes :)
Payload looks like Linux Image, yay!
DTB still fine, yay!
Handing over to SBI, will continue at 0x40200000
enter supervisor at 40200000 with DTB from 41a00000
...
[ 0.000000] OF: fdt: Ignoring memory range 0x40000000 - 0x40200000
[ 0.000000] Machine model: Sipeed Lichee RV Dock
[ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[ 0.000000] printk: bootconsole [sbi0] enabled
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000040200000-0x000000005fffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000040200000-0x000000005fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000040200000-0x000000005fffffff]
[ 0.000000] riscv: SBI specification v1.0 detected
[ 0.000000] riscv: SBI implementation ID=0x4 Version=0x301
[ 0.000000] riscv: SBI TIME extension detected
[ 0.000000] riscv: SBI IPI extension detected
[ 0.000000] riscv: SBI SRST extension detected
[ 0.000000] riscv: base ISA extensions acdfim
[ 0.000000] riscv: ELF capabilities acdfim
[ 0.000000] percpu: Embedded 17 pages/cpu s31912 r8192 d29528 u69632
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 128520
[ 0.000000] Kernel command line: console=tty0 console=ttyS0,115200 loglevel=7 earlycon=sbi
Wir bauen auf den Abstraktionen aus dem Modell der Rost -Embedded Working Group mit ihren Kisten und Merkmalen auf, die in ihrem Buch detailliert sind.
Kurzgesagt: 
Es wird erwartet, dass SOC -Anbieter ihre Kerne, Peripheriegeräte und andere Blöcke und/oder ihre SVD -Dateien dokumentieren, sodass wir die Kisten der PAC- und HAL -Kisten generieren können, oder im Idealfall sollte der Verkäufer auch diese bereitstellen und verwalten .
Das Rost -Embedded -Buch bietet Entwurfsmuster und Implementierungsrichtlinien sowie ein Glossar, um ein Verständnis der Struktur zu erlangen.
Um ein allgemeines Verständnis dafür zu erhalten, wie OreBoot und Firmware im Allgemeinen funktionieren, schauen Sie sich die Kartierflow -Dokumentation an. Es beschreibt, wie Firmware gespeichert wird und auf einer Plattform / SoC startet.
Beachten Sie, dass OreBoot nicht zielt, sich in ein eigenes Betriebssystem zu verwandeln. Dementsprechend beabsichtigen wir, die Menge und Funktionalität der Treiber niedrig zu halten. Durch die Gestaltung von SoCs müssen wir jedoch etwas implementieren, um Code zu laden:
In vielen Fällen wird kein voller Treiber benötigt, da wir nur aus dem Speicher gelesen werden müssen und wir keine reichhaltigen Dateisysteme benötigen. Um mit den Anforderungen und Einzelheiten eines Betriebssystems zu kollidieren, empfehlen wir, Speicherteile eindeutig zu trennen, die die Firmware bzw. das Betriebssystem halten. Legen Sie beispielsweise die Firmware in einen SPI -Blitz und das Betriebssystem auf eine NVME SSD.
Klonen Sie dieses Repo und geben Sie sein Verzeichnis ein, dh:
git clone https://github.com/oreboot/oreboot.git
cd orebootIm Allgemeinen benötigen Sie die folgenden Pakete installiert:
device-tree-compilerpkg-configlibsslrustup Für Debian -basierte Systeme gibt es ein Make -Target, um diese zu installieren, die rustup durch Curl von https://sh.rustup.rs durchquert:
make debiansysprepareInstallieren Sie das Paket ansonsten über Ihren Systempaketmanager.
Unabhängig von Ihrem Betriebssystem müssen Sie die Toolchain für den OreBoot installieren. Dieser Befehl muss nur einmal erledigt werden, aber es ist sicher, es wiederholt zu tun.
make firsttimeJedes Mal, wenn Sie mit dem Erstboot oder sogar täglich arbeiten:
cd oreboot
make updateSie sollten dies auf jeden Fall tun, bevor Sie Probleme melden.
Es gibt zwei verschiedene Dinge im Projekt:
src/mainboards/* Die tatsächlichen Ziele; Diese hängen von Kisten ab und teilen Sie Kisten, die Treiber, Soc Init -Code und ähnlich sein können. Für Mainboards muss Cargo.lock verfolgt werden.src/* alles andere; Dies sind die oben genannten Kisten, für die wir die Dateien Cargo.lock nicht verfolgen. Wenn Sie in der Cargo.lock eines Mainboards einchecken, werden der Status seiner Abhängigkeiten zum Zeitpunkt eines erfolgreichen Builds aufgezeichnet, wodurch die Reproduzierbarkeit ermöglicht wird. Im Idealfall wird eine Sperrdatei aktualisiert, um einen erfolgreichen Start auf Hardware zu erzielen.
Weitere Informationen finden Sie unter: https://doc.rust-lang.org/cargo/faq.html#why-do--inaries-have-cargolock-in-version-control-but-not-library
Beim Erstellen eines neuen Mainboards ist es ein guter Anfang, zu betrachten, wie andere für dieselbe Architektur eingerichtet sind. Beachten Sie, dass OreBoot auf Bare Metal abzielt, sodass keine Standardbibliothek verfügbar ist.
Um OreBoot für eine bestimmte Plattform zu erstellen, tun Sie Folgendes:
# Go to the mainboard's directory
cd src/mainboard/sunxi/nezha
# Build the mainboard target
make mainboard
# View disassembly
make objdump
# Run from RAM without flashing
make run
# Flash to the board
make flash
Mit dem Root Makefile können Sie schnell alle Plattformen erstellen:
# build all mainboards
make mainboards
# build everything in parallel
make -j mainboards
# Install QEMU for your target platform, e.g. x86
sudo apt install qemu-system-x86
# Build release build and start with QEMU
cd src/mainboard/emulation/qemu-q35 && make run
# Quit qemu with CTRL-A X
QEMU aus der Quelle für RISC-V zu bauen:
git clone https://github.com/qemu/qemu && cd qemu
mkdir build-riscv64 && cd build-riscv64
../configure --target-list=riscv64-softmmu
make -j$(nproc)
# QEMU binary is at riscv64-softmmu/qemu-system-riscv64
QEMU aus der Quelle für AARG64 zu erstellen:
git clone https://github.com/qemu/qemu && cd qemu
mkdir build-aarch64 && cd build-aarch64
../configure --target-list=aarch64-softmmu
make -j$(nproc)
# QEMU binary is at aarch64-softmmu/qemu-system-aarch64
Ähnlich wie bei Corboot ist die Struktur im OreBoot pro Anbieter und Mainboard. Mehrere Architekturen und SOCs werden jeweils unterstützt, und ihr gemeinsamer Code wird zwischen den Boards geteilt. Boards haben möglicherweise Varianten, wenn kleinere Abweichungen sonst zu viel Code -Duplikation verursachen würden.
qemu-riscvAls Referenz werden frühere Ansätze dokumentiert. Schauen Sie sich diejenigen für X86- und Armplattformen und Mainboards an.
Frühere Emulationsziele wurden in src.broken/mainboard/emulation/ geparkt. Sie sollen ein allgemeines Verständnis jeder Architektur vermitteln, die OreBoot unterstützen möchte:
qemu-armv7qemu-aarch64qemu-q35Makefile S muss einfach sein. Verwenden Sie stattdessen xtask für den Steuerfluss, z. B. Header oder Prüfsummen zu den Binärdateien, Sitching -Bilder usw.Cargo.toml In den jeweiligen Verzeichnissen src/mainboard/$VENDOR/$BOARD (SUB) ermöglichen die vom Vorstand spezifischen Abhängigkeiten und den Aufbau aller Phasen parallel.make format ohne Ausnahmen formatiert. Eine CI -Überprüfung zeigt, ob eine Änderung die Formatierungsregeln nicht hält.Das Urheberrecht auf dem OreBoot gehört einer ziemlich großen Anzahl einzelner Entwickler und Unternehmen. Bitte überprüfen Sie die einzelnen Quelldateien für Details.
OREBOOT ist nach den Bestimmungen der GNU General Public Lizenz (GPL) lizenziert. Einige Dateien sind unter der "GPL (Version 2 oder einer beliebigen Version)" lizenziert, und einige Dateien sind unter der "GPL, Version 2" lizenziert. Für einige Teile, die aus anderen Projekten abgeleitet wurden, können andere (GPL-kompatible) Lizenzen gelten. Bitte überprüfen Sie die einzelnen Quelldateien für Details.
Dies macht die resultierenden Ostenbilder unter der GPL, Version 2, lizenziert.
