oreboot
1.0.0
OreBoot es una bifurcación aguas abajo de CoreBoot, es decir, OreBoot es CoreBoot sin 'C'.
OreBoot está escrito principalmente en óxido, con ensamblaje donde sea necesario.
OreBoot actualmente solo planea admitir cargas útiles 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
Construimos en la parte superior de las abstracciones del modelo del Grupo de Trabajo de Rustigado con sus cajas y rasgos, detallados en su libro.
En una palabra: 
Se espera que los proveedores de SOC proporcionen documentación a sus núcleos, periféricos y otros bloques y/o sus archivos SVD, para que podamos generar las cajas PAC y Hal, o idealmente, el proveedor debe proporcionarlos y mantenerlos también.
El libro integrado de Rust ofrece patrones de diseño y pautas de implementación, así como un glosario para comprender la estructura.
Para obtener una comprensión general de cómo funcionan el oreboot y el firmware en general, eche un vistazo a la documentación del flujo de arranque. Describe cómo se almacena el firmware y se inicia en una plataforma / SOC.
Tenga en cuenta que OreBoot no tiene como objetivo convertirse en su propio sistema operativo. En consecuencia, tenemos la intención de mantener baja la cantidad y la funcionalidad de los conductores. Sin embargo, por diseño de SOC, tenemos que implementar algo para cargar código:
En muchos casos, no se necesita un controlador completo, ya que solo necesitamos leer, por ejemplo, el almacenamiento, y no necesitamos sistemas de archivos ricos. Para evitar colisionar con las necesidades y detalles de un sistema operativo, recomendamos separar claramente las piezas de almacenamiento que contienen el firmware y el sistema operativo, respectivamente. Por ejemplo, coloque el firmware en un flash SPI y el sistema operativo en un SSD NVME.
Clone este repositorio e ingrese su directorio, es decir:
git clone https://github.com/oreboot/oreboot.git
cd orebootEn general, necesitará los siguientes paquetes instalados:
device-tree-compilerpkg-configlibsslrustup Para los sistemas basados en Debian, hay un objetivo para instalarlos, que extrae rustup a través de Curl de https://sh.rustup.rs:
make debiansysprepareDe lo contrario, instale el paquete a través del Administrador de paquetes de su sistema.
Independientemente de su sistema operativo, deberá instalar la cadena de herramientas para OreBoot. Este comando solo debe hacerse una vez, pero es seguro hacerlo repetidamente.
make firsttimeCada vez que comienza a trabajar con OreBoot, o incluso a diario:
cd oreboot
make updateDefinitivamente debería hacer esto antes de informar cualquier problema.
Hay dos cosas diferentes en el proyecto:
src/mainboards/* los objetivos reales; Los dependen y comparten cajas, que pueden ser conductores, código de inicio de SOC y similares. Para los mainboards, Cargo.lock debe ser rastreado.src/* todo lo demás; Estas son las cajas antes mencionadas, para las cuales, no rastreamos los archivos Cargo.lock . Verificar en el archivo Cargo.lock de un placa principal registra el estado de sus dependencias en el momento de una compilación exitosa, lo que permite la reproducibilidad. Idealmente, un archivo de bloqueo se actualiza con el arranque exitoso en hardware.
Para obtener más información, ver: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libers
Al crear una nueva placa base, mirar cómo se configuran otros para la misma arquitectura es un buen comienzo. Tenga en cuenta que OreBoot se dirige a metal desnudo, por lo que no hay una biblioteca estándar disponible.
Para construir OreBoot para una plataforma específica, haga esto:
# 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
Root Makefile le permite construir rápidamente todas las plataformas:
# 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
Para construir QEMU a partir de la fuente para 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
Para construir QEMU a partir de la fuente de 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
Similar a CoreBoot, la estructura en OreBoot es por proveedor y placa base. Múltiples arquitecturas y SOC son compatibles respectivamente, y su código común se comparte entre las juntas. Las juntas pueden tener variantes si las desviaciones menores causarían demasiada duplicación de código.
qemu-riscvComo referencia, se documentan los enfoques anteriores. Eche un vistazo a los de X86 y plataformas de brazo y pizarras.
Los objetivos de emulación anteriores se han estacionado en src.broken/mainboard/emulation/ . Se supone que deben proporcionar una comprensión general de cada arquitectura que OreBoot busca apoyar:
qemu-armv7qemu-aarch64qemu-q35Makefile S debe ser simple. Use xtask en su lugar para el flujo de control, por ejemplo, agregando encabezados o suma de verificación a los binarios, imágenes de sitchting, etc.Cargo.toml en los directorios respectivos src/mainboard/$VENDOR/$BOARD (sub) permiten dependencias específicas de la junta y construyendo todas las etapas en paralelo.make format sin excepciones. Un cheque de CI dirá si un cambio no se adhiere a las reglas de formato.Los derechos de autor sobre OreBoot son propiedad de una gran cantidad de desarrolladores y empresas individuales. Consulte los archivos de origen individuales para obtener más detalles.
OreBoot tiene licencia bajo los términos de la Licencia Pública General de GNU (GPL). Algunos archivos tienen licencia bajo el "GPL (versión 2, o cualquier versión posterior)", y algunos archivos tienen licencia bajo la "GPL, versión 2". Para algunas partes, que se derivaron de otros proyectos, pueden aplicarse otras licencias (compatibles con GPL). Consulte los archivos de origen individuales para obtener más detalles.
Esto hace que las imágenes de oreboot resultantes sean licenciadas bajo el GPL, versión 2.
