oreboot
1.0.0
Oreboot est une fourche en aval de Coreboot, c'est-à-dire que Oreboot est Coreboot sans «C».
Oreboot est principalement écrit en rouille, avec assemblage si nécessaire.
Oreboot prévoit actuellement uniquement de prendre en charge les charges utiles de LinuxBoot.
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
Nous construisons au-dessus des abstractions du modèle du groupe de travail intégré à la rouille avec ses caisses et traits, détaillés dans leur livre.
En un mot: 
Les fournisseurs de SOC devraient fournir de la documentation à leurs noyaux, périphériques et autres blocs et / ou leurs fichiers SVD, afin que nous puissions générer les caisses PAC et HAL, ou idéalement, le vendeur devrait également les fournir et les maintenir .
Le livre intégré Rust propose des modèles de conception et des directives de mise en œuvre ainsi qu'un glossaire pour comprendre la structure.
Pour obtenir une compréhension générale de la façon dont Oreboot et le firmware en général fonctionnent, jetez un œil à la documentation du flux de démarrage. Il décrit comment le firmware est stocké et se met sur une plate-forme / SOC.
Notez que Oreboot ne vise pas à se transformer en son propre système d'exploitation. En conséquence, nous avons l'intention de maintenir la quantité et la fonctionnalité des conducteurs bas. Cependant, par conception de SOC, nous devons implémenter quelque chose pour charger le code:
Dans de nombreux cas, aucun pilote complet n'est nécessaire, car nous n'avons qu'à lire par exemple le stockage, et nous n'avons pas besoin de systèmes de fichiers riches. Pour éviter de collision avec les besoins et les détails d'un système d'exploitation, nous vous recommandons de séparer clairement les pièces de stockage détenant le firmware et le système d'exploitation, respectivement. Par exemple, mettez le firmware dans un flash SPI et le système d'exploitation sur un SSD NVME.
Clone ce dépôt et entrez son répertoire, c'est-à-dire:
git clone https://github.com/oreboot/oreboot.git
cd orebootEn général, vous aurez besoin des packages suivants installés:
device-tree-compilerpkg-configlibsslrustup Pour les systèmes basés sur Debian, il y a une cible pour les installer, ce qui tire rustup à travers la boucle de https://sh.rustup.rs:
make debiansysprepareSinon, installez le package via votre gestionnaire de packages système.
Quel que soit votre système d'exploitation, vous devrez installer la chaîne d'outils pour Oreboot. Cette commande ne doit être fait qu'une seule fois, mais il est sûr de le faire à plusieurs reprises.
make firsttimeChaque fois que vous commencez à travailler avec Oreboot, ou même tous les jours:
cd oreboot
make updateVous devriez certainement le faire avant de signaler tout problème.
Il y a deux choses différentes dans le projet:
src/mainboards/* Les cibles réelles; Ceux-ci dépendent et partagent des caisses, qui peuvent être des conducteurs, du code Init SOC et similaires. Pour les tableaux principaux, Cargo.lock doit être suivi.src/* tout le reste; Ce sont les caisses susmentionnées, pour lesquelles nous ne suivons pas les fichiers Cargo.lock . Enregistrant le fichier Cargo.lock d'une carte principale enregistre l'état de ses dépendances au moment d'une construction réussie, permettant la reproductibilité. Idéalement, un fichier de verrouillage est mis à jour Follwoing Boot réussi sur le matériel.
Pour en savoir plus, voir: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraires
Lors de la création d'un nouveau tableau principal, voir comment les autres sont configurés pour la même architecture est un bon début. Sachez que Oreboot cible le métal nu, il n'y a donc pas de bibliothèque standard disponible.
Pour construire Oreboot pour une plate-forme spécifique, faites-le:
# 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
Le Root Makefile vous permet de créer rapidement toutes les plates-formes:
# 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
Pour construire Qemu à partir de la source de RISC-V:
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
Pour construire Qemu à partir de la source pour Aarch64:
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
Semblable à Coreboot, la structure de Oreboot est par fournisseur et en panneau continu. Plusieurs architectures et SOC sont pris en charge respectivement et leur code commun est partagé entre les conseils. Les conseils peuvent avoir des variantes si les écarts mineurs entraîneraient autrement trop de duplication de code.
qemu-riscvPour référence, des approches antérieures sont documentées. Jetez un œil à ceux pour les plates-formes X86 et ARM et les tableaux principaux.
Des objectifs d'émulation antérieurs ont été stationnés dans src.broken/mainboard/emulation/ . Ils sont censés fournir une compréhension générale de chaque architecture que Oreboot cherche à soutenir:
qemu-armv7qemu-aarch64qemu-q35Makefile s doit être simple. Utilisez à la place xtask pour le flux de contrôle, par exemple, en ajoutant des en-têtes ou des sommes de contrôle aux binaires, des images de galet, etc.Cargo.toml Dans les répertoires src/mainboard/$VENDOR/$BOARD respectifs, permettez les dépendances spécifiques à la carte et la construction de toutes les étapes en parallèle.make format sans exception. Un contrôle CI indiquera si un changement n'adhère pas aux règles de formatage.Le droit d'auteur sur Oreboot appartient à un assez grand nombre de développeurs et d'entreprises individuels. Veuillez vérifier les fichiers source individuels pour plus de détails.
Oreboot est concédé sous licence de la licence publique générale GNU (GPL). Certains fichiers sont sous licence sous le "GPL (version 2, ou n'importe quelle version ultérieure)", et certains fichiers sont sous licence "GPL, version 2". Pour certaines pièces, dérivées d'autres projets, d'autres licences (compatibles GPL) peuvent s'appliquer. Veuillez vérifier les fichiers source individuels pour plus de détails.
Cela rend les images Oreboot résultantes sous licence dans le GPL, version 2.
