oreboot is a fork of coreboot, with C removed, written in Rust.

Overview

oreboot README

Build Status

oreboot is a downstream fork of coreboot, i.e. oreboot is coreboot without 'c'.

oreboot is mostly written in Rust, with assembly where needed.

oreboot currently only plans to support LinuxBoot payloads.

Demos

Output sample from the RISC-V demo

Testing DDR...                                                                                              
Starting to fill with data                                                                                  
Starting to read back data                                                                                  
Passed                                                                                                      
Loading payload                                                                                             
Running payload                                                                                             
ACEGHIJLMN                                                                                                  
Linux version 5.3.0-rc5+ (orebootorebootorebootorebooto) (gcc version 8.2.0 (Debian 8.2.0-14+build1)) #9 Tue
 Sep 3 06:42:07 PDT 2019                                                                                    
Zone ranges:                                                                                                
  DMA32    [mem 0x0000000080000000-0x00000000bfffffff]                                                      
  Normal   empty                                                                                            
Movable zone start for each node                                                                            
Early memory node ranges                                                                                    
  node   0: [mem 0x0000000080000000-0x00000000bfffffff]                                                     
Initmem setup node 0 [mem 0x0000000080000000-0x00000000bfffffff]                                            
elf_hwcap is 0x112d                                                                                         
Built 1 zonelists, mobility grouping on.  Total pages: 258560                                               
Kernel command line: console=ttySIF0                                                                        
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)                                   
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)                                      
mem auto-init: stack:off, heap alloc:off, heap free:off                                                     
Memory: 1031428K/1048576K available (814K kernel code, 80K rwdata, 98K rodata, 64K init, 171K bss, 17148K re
served, 0K cma-reserved) 

Getting oreboot

Clone this repo and enter its directory, i.e.:

git clone git://github.com/oreboot/oreboot
cd oreboot

Prerequisites

In general, you will need the following packages installed:

  • device-tree-compiler
  • pkg-config
  • libssl
  • rustup

For Debian based systems, there is a make target to install those, which pulls rustup through curl from https://sh.rustup.rs:

make debiansysprepare

Otherwise, install the package through your system package manager.

Setting up the toolchain

Regardless of your OS, you will need to install the toolchain for oreboot. This command only needs to be done once but it is safe to do it repeatedly.

make firsttime

Keeping build tools up to date

Each time you start to work with oreboot, or even daily:

cd oreboot
make update

You should definitely do this before reporting any issues.

Developing oreboot

There are two different things in the project:

  1. src/mainboards/* the actual targets; those depend on and shared crates, which can be drivers, SoC init code, and similar. For mainboards, Cargo.lock must be tracked.
  2. src/* everything else; these are the aforementioned crates, for which, we do not track the Cargo.lock files.

Checking in a mainboard's Cargo.lock file records the state of its dependencies at the time of a successful build, enabling reproducibility. Ideally, a lock file is updated follwoing successful boot on hardware.

For more, see: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

When creating a new mainboard, looking at how others are set up for the same architecture is a good start. Be aware that oreboot is targeting bare metal, so there is no standard library available.

Building oreboot

If the mainboard uses FSP (Intel platforms), download the blobs with:

git submodule update --init

To build oreboot for a specific platform, do this:

# Go to the mainboard's directory.
cd src/mainboard/sifive/hifive
# Build in release mode.
make
# Build in debug mode.
MODE=debug make
# View disassembly
make objdump
# Run in QEMU simulation.
make run
# Flash with flashrom.
make flash

The root Makefile allows you to quickly build all platforms:

# build all mainboards
make mainboards
# build everything in parallel
make -j mainboards

QEMU

# 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

To build QEMU from source for 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

To build QEMU from source for 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

Oreboot Mainboards

  • Emulation
    • qemu-armv7
    • qemu-aarch64
    • qemu-q35
    • qemu-riscv
  • Hardware

Ground Rules

  • Makefile must be simple. They cannot contain control flow.
  • Cargo.toml files are located in the src/mainboard/x/y directories. which will allow us to build all boards in parallel.
  • All code is auto-formatted with rustfmt with no exceptions. There are no vestiges of the 19th century such as line length limits.
  • There will be no C.
  • We will not run our own Gerrit. We are using Github for now, and the github Pull Request review mechanism.
  • We will not run our own Jenkins. We will use the most appropriate CI; for now, that is Azure but we will be flexible.

Ground Rules for x86

  • We prefer all pieces of the firmware to be open-source; but can accept an ME and FSP binary blob for x86 architectures.
  • Blobs must be essential to boot the system and not provide any extraneous functionality which could not be implemented in Oreboot.
  • Blobs must be redistributable and are ideally available on GitHub.
  • Blobs must not be submitted to github.com/oreboot/oreboot. We prefer blobs to be submitted to github.com/oreboot/blobs, github.com/coreboot/blobs or some other GitHub repository.
  • The blobs must be in a binary format. No additional C code, assembly files or header files are acceptable.
  • Any compromises to the language safety features of Rust must be explicitly stated.

As a "measure" for how open-source firmware is, use the percentage of the final binary size. For example, if 70% of the firmware bytes are closed-source blob and 30% built from Oreboot source code, we would say the firmware is 30% open-source.

Copyright and License

The copyright on oreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details.

oreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details.

This makes the resulting oreboot images licensed under the GPL, version 2.

Issues
  • Add HiFive device tree from coreboot

    Add HiFive device tree from coreboot

    opened by rjoleary 18
  • azure-pipelines: build qemu with x86_64 support, test qemu-q35 board

    azure-pipelines: build qemu with x86_64 support, test qemu-q35 board

    There's at least one other PR related to qemu (#298), but that one uses a prebuilt binary for risc-v where this one adds x86_64 support.

    Thought I'd create the PR anyway and see how well azure liked it. Related: #100, #295.

    Signed-off-by: Mark Pictor [email protected]

    opened by mpictor 13
  • update rust nightly

    update rust nightly

    null

    opened by Rwantare 9
  • Build is broken

    Build is broken

    oreboot is unable to link. I see this error:

    error: linking with `rust-lld` failed: exit code: 1
      |
      = note: "rust-lld" "-flavor" "gnu" "-L" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/riscv64imac-unknown-none-elf/release/deps/hifive-5d67b9f37960cb79.hifive.eefz7yfk-cgu.5.rcgu.o" "-o" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/riscv64imac-unknown-none-elf/release/deps/hifive-5d67b9f37960cb79" "--gc-sections" "-L" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/riscv64imac-unknown-none-elf/release/deps" "-L" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/release/deps" "-L" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib" "-Bstatic" "/home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib" "-Tlink.ld" "-Bdynamic"
      = note: rust-lld: error: undefined symbol: __atomic_load_16
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memcpy_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memmove_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memmove_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              
              rust-lld: error: undefined symbol: __atomic_store_16
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memcpy_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memmove_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memmove_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
              >>> referenced by compiler_builtins.4xlgpysu-cgu.3
              >>>               compiler_builtins-94979fc64732be66.compiler_builtins.4xlgpysu-cgu.3.rcgu.o:(__llvm_memset_element_unordered_atomic_16) in archive /home/vsts/work/1/s/src/mainboard/sifive/hifive/target/sysroot/lib/rustlib/riscv64imac-unknown-none-elf/lib/libcompiler_builtins-94979fc64732be66.rlib
    

    It happens locally and on Azure: https://dev.azure.com/azure0427/Oreboot%20Pipeline/_build/results?buildId=338

    opened by alistair23 8
  • WIP: Update QEMU to 4.2-rc0

    WIP: Update QEMU to 4.2-rc0

    opened by alistair23 7
  • Split HiFive mainboard into hardware and qemu

    Split HiFive mainboard into hardware and qemu

    There were so many difference between hardware and QEMU (especially with device tree) that the is_qemu function did not suffice. We also want to use virt instead of sifive_u machine in QEMU.

    Signed-off-by: Ryan O'Leary [email protected]

    opened by rjoleary 7
  • Move fdt reading code from layoutflash to device_tree lib

    Move fdt reading code from layoutflash to device_tree lib

    While working on #498 I saw some "TODO: Move to lib" comments in the layoutflash code. This MR moves some of the code into /src/lib/device_tree. I am somewhat unsure about the size of the Vecs in the Area struct. Maybe someone has some advice on that.

    Tests run: make test in / make run in /src/mainboard/emulation/qemu-armv7 Both seemed fine.

    opened by derpsteb 6
  • Cargo-make issues

    Cargo-make issues

    cargo-make is deficient in the following areas:

    1. Config variables: Ideally, the end user can customize compile-time constants such as the baudrate. Something like, but not necessarily, kconfig is desired.
    2. Duplication: Each mainboard has a Makefile.toml which is nearly identical. Ideally, some of the logic here can be shared across mainboards.
    3. Incremental builds: Changes to some files do not trigger a rebuild. A few times, I have accidentally used an older build.
    opened by rjoleary 6
  • Created build configuration tool

    Created build configuration tool

    I started working on a build configuration tool. Name is chisel.

    [COMMENCING TOOL NAMING WAR IN 3...2...1...]
    

    :grin:

    opened by sphinxc0re 6
  • Fix azure pipelines patch to qemu by checking out known-good ref of qemu

    Fix azure pipelines patch to qemu by checking out known-good ref of qemu

    The messages are a bit more verbose but it is still better than things like

    error 2

    which we got before

    opened by rminnich 6
  • Replace rpp with global_asm Named Parameters

    Replace rpp with global_asm Named Parameters

    As I proposed in issue #504, we can replace the assembly preprocessor rpp with the Rust built-in features. This PR is based on my PoC https://github.com/retrage/oreboot/tree/asm-const-poc.

    The main change from the PoC branch is introducing a new macro. I added the const_asm!() macro to wrap the named parameter boilerplate code. By the way, I think the name const_asm is too general and does not describe the role well. Could you give me comments on the name?

    opened by retrage 2
  • sunxi: create fully bootable images

    sunxi: create fully bootable images

    So far, only the Nezha / D1 RISC-V board is supported via FEL mode, i.e., the on-chip bootloader for USB OTG, using xfel ddr ddr3 for OOB DRAM init, and executing from memory.

    To get a fully bootable image, suitable for SD cards, SPI flash, etc, we need to create an "eGON" image (magic bytes + header).

    See also: https://linux-sunxi.org/EGON#eGON.BT0

    opened by orangecms 1
  • Replacing Assembly Preprocessor with Rust Built-in Features

    Replacing Assembly Preprocessor with Rust Built-in Features

    I'm new to this project, so correct me if I missed something. As far as I know, PR #458 introduced rpp for preprocessing assembly files. The primary motivation is to improve assembly code reusability because Rust does not provide its macro system to assembly.

    However, I cannot find any reason to employ the C preprocessor-like syntax for the project written in Rust. I think it is better to use rich Rust's compile-time features for preprocessing. The current primary usage of preprocess_asm!() is to define constant value macros and include other files. It can be replaced by nightly Rust's built-in feature because global_asm!() accepts named parameters. Here is my PoC: https://github.com/retrage/oreboot/tree/asm-const-poc

    The macro-defined values are defined in src/consts/asm.rs. The macro references are replaced with Rust named parameters (e.g. Pse -> {pse}). The corresponding const values are given as arguments of global_asm!().

    global_asm!(
        include_str!("../../../../arch/x86/x86_64/src/bootblock_nomem.S"),
        pse = const asm::PSE,
        // snip
        options(att_syntax)
    );
    

    This design also allows us to use other Rust const features like const fn without additional efforts.

    The main drawback of this idea is that the number of global_asm!() arguments may be large, and the code looks redundant. We can hide the arguments by defining a macro that uses default values.

    I can provide PR with more improvements if anyone is interested in my idea.

    opened by retrage 5
  • qemu-q35 debug port print breaks boot

    qemu-q35 debug port print breaks boot

    When running make run for qemu-q35 I can not get past the first print onto the debug port here.

    When this line is commented out I can at least get up to loading the payload (L47), at which a panic will occur and the following message will be printed forever:

    Welcome to oreboot                                                                                       
    boot flag is ffff, not aa55, at ffff,                                                                                                                                                                              
                                                                                                                                                                                                                       
    PANIC: Welcome to oreboot                                                                                                                                                                                          
    boot flag is ffff, not aa55, at ffff,                                                                                                                                                                              
                                                                                                             
    PANIC: Welcome to oreboot                                                                                                                                                                                          
    boot flag is ffff, not aa55, at ffff,
    

    Hopefully I will be able to resolve it myself, but maybe someone knows whats wrong here :)

    opened by derpsteb 3
  • use the device tree to find the payload and variables.

    use the device tree to find the payload and variables.

    we need to start using the device tree.

    A good first step: src/mainboard/emulation/qemu-armv7 in src/main.rs, call print_fdt as found in lib/device_tree/src/lib.rs

    This only sounds simple as stated here :-)

    Feature Request Help Wanted Good First Issue 
    opened by rminnich 4
  • Assembly preprocessor (rpp) improvements

    Assembly preprocessor (rpp) improvements

    rpp does not currently support multiline macros such as

    #define MACRO some \
        stuff
    

    This should be an easy thing to add

    Feature Request Good First Issue 
    opened by jhand2 0
  • FSP QEMU Targets conflict during parallel builds

    FSP QEMU Targets conflict during parallel builds

    The QEMU FSP build outputs to the same directory regardless of architecture. This causes conflicts during a multithreaded build where both targets are built. Need to rework this build to output to different directories.

    Bug Code Health 
    opened by jhand2 0
  • dependencies and license checking

    dependencies and license checking

    @rjoleary made a good point that we should investigate a few things around our dependencies. They come from various sources, and they have various licenses.

    The Fuchsia project has a Rust dependencies license checker: https://fuchsia.googlesource.com/scripts/+/3p-dart-pkg/rust/check_rust_licenses.py

    We should also investigate if our dependencies are up to date, if they are still maintained, if something else has been established here or there, see if we can reduce some to decrease the probability of malicious code sneaking in, etc..

    Code Health 
    opened by orangecms 0
  • Use rustsbi for SBI support for Risc-v

    Use rustsbi for SBI support for Risc-v

    @orangecms pointed us at: https://github.com/rustsbi/rustsbi

    This is an implementation of SBI in Rust. We think we can compile it with the rest of oreboot and run from M-Mode.

    opened by rjoleary 0
Opensource diagnostic software for Daimler vehicles, inspired by Xentry and DAS, written in Rust

OPENSTAR An opensource diagnostic application for Daimler vehicles inspired by DAS and Xentry. Some of the work here is based on OpenVehicleDiag If yo

Ashcon Mohseninia 11 Oct 31, 2021
Benchmarking web frameworks written in rust with rewrk tool.

Web Framework Benchmarks Benchmarking web frameworks written in rust with rewrk tool.

null 32 Nov 26, 2021
Yet another ROS2 client library written in Rust

RclRust Target CI Status Document Foxy (Ubuntu 20.04) Introduction This is yet another ROS2 client library written in Rust. I have implemented it inde

rclrust 19 Nov 22, 2021
A little bit fast and modern Ruby version manager written in Rust

A little bit fast and modern Ruby version manager written in Rust Features Pure Rust implementation not using ruby-build Cross-platform support (macOS

Takayuki Maeda 353 Nov 28, 2021
Music bot written in Rust

Akasuki What is Akasuki? Akasuki is a simple discord music bot written in rust. Highlights Select your music using discord's new select menu feature,

Forbidden A 1 Oct 18, 2021
A Discord bot for sending GeoGuessr challenge links that uses the GeoGuessr API written in rust.

GeoGuessr-bot-rs This is a simple implementation of a discord bot that send GeoGuessr-challenge links on demand. Features: Slash-commands Lightning-fa

Luukas P枚rtfors 3 Nov 1, 2021
Some tools for streaming frames to rpi-rgb-led-matrix using ZeroMQ, written in Rust.

led_matrix_zmq Some tools for streaming frames to rpi-rgb-led-matrix using ZeroMQ, written in Rust. This repository includes: Rust client and server l

Dan 1 Nov 7, 2021
A gui api explorer written in Rust.

Zzz - GUI Api platform Pronounced "Zees"; as in "catching some Z's". A pun on RESTful APIs. example URL: https://jsonplaceholder.typicode.com/todos/ T

Ryan Blecher 0 Nov 11, 2021
Cross-platform GUI written in Rust using ADB to debloat non-rooted android devices

Cross-platform GUI written in Rust using ADB to debloat non-rooted android devices. Improve your privacy, the security and battery life of your device.

w1nst0n 1.1k Nov 23, 2021
A variation of the solana helloworld program example with a client written in Rust instead of Typescript

Simple Solana Smart Contract Example This repository demonstrates how to create and invoke a program on the Solana blockchain. In Solana the word prog

zeke 3 Nov 16, 2021
A powerful minecraft bedrock software written in Rust with a powerful Typescript plugin API.

Netrex A powerful minecraft bedrock software written in RustLang. Why Netrex? It's written in Rust. Unique and straight to the point. Typescript Plugi

Netrex 21 Nov 30, 2021
Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs

Alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients*, perfect for self-hosted deploy

Daniel Garc铆a 12.2k Nov 30, 2021
s3d is an S3 daemon for the Edge written in Rust

s3d is an S3 daemon for the Edge written in Rust The goal of s3d is to provide a daemon for edge platforms (e.g. factory servers ?? planes ?? ships ??

null 6 Nov 18, 2021
TAT agent is an agent written in Rust, which run in CVM or Lighthouse instances.

TAT agent is an agent written in Rust, which run in CVM, Lighthouse or CPM 2.0 instances. Its role is to run commands remotely without ssh login, invoked from TencentCloud Console/API. Commands include but not limited to: Shell, PowerShell, Python. TAT stands for TencentCloud Automation Tools. See more info at https://cloud.tencent.com/product/tat.

Tencent 28 Nov 28, 2021
Brainfuck interpreter written in rust

Brainfuck Interpreter Written in Rust Simple Interpreter that runs bare Brainfuck and extends it with debug command # which prints content of first te

Was 1 Nov 28, 2021
Milho (corn in portuguese) is a toy dialect of Lisp written as a way to learn more about compilers

Milho (corn in portuguese) is a toy dialect of Lisp written as a way to learn more about compilers. There are implementations in rust and go

Celso Bonutti 25 Nov 8, 2021
A stupid macro that compiles and executes Rust and spits the output directly into your Rust code

inline-rust This is a stupid macro inspired by inline-python that compiles and executes Rust and spits the output directly into your Rust code. There

William 1 Nov 22, 2021
馃悁 Building a federated alternative to reddit in rust

Lemmy A link aggregator / Reddit clone for the fediverse. Join Lemmy 路 Documentation 路 Report Bug 路 Request Feature 路 Releases 路 Code of Conduct About

LemmyNet 5.6k Nov 29, 2021
Applied offensive security with Rust

Black Hat Rust - Early Access Deep dive into offensive security with the Rust programming language Buy the book now! Summary Whether in movies or main

Sylvain Kerkour 1k Nov 24, 2021