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.

Comments
  • Nightly 2022 01 11

    Nightly 2022 01 11

    doesn't work just yet, needs more work somewhat around linking?

    with .cargo/config.toml

    [build]
    target = "x86_64-unknown-none"
    
    [target.x86_64-unknown-none]
    rustflags = [
      "-C", "relocation-model=pic",
      "-C", "link-arg=-Tlink.ld",
      "-C", "link-arg=-nostdlib",
      "-Z", "emit-stack-sizes",
    ]
    

    this happens:

    error: linking with `rust-lld` failed: exit status: 1
      |
      = note: "rust-lld" "-flavor" "gnu" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/upxtreme-c2a0d6446acbf0ac.upxtreme.f7483b69-cgu.8.rcgu.o" "--as-needed" "-L" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps" "-L" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/release/deps" "-L" "/home/dama/.rustup/toolchains/nightly-2022-02-04-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-none/lib" "-Bstatic" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/libcompiler_builtins-5c6144d7d8f77801.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/dama/.rustup/toolchains/nightly-2022-02-04-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-none/lib" "-o" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/upxtreme-c2a0d6446acbf0ac" "--gc-sections" "-pie" "-zrelro" "-znow" "-Tlink.ld" "-nostdlib"
      = note: rust-lld: error: no memory region specified for section '.dynsym'
              rust-lld: error: no memory region specified for section '.gnu.hash'
              rust-lld: error: no memory region specified for section '.hash'
              rust-lld: error: no memory region specified for section '.dynstr'
              rust-lld: error: no memory region specified for section '.rela.dyn'
              rust-lld: error: no memory region specified for section '.dynamic'
              rust-lld: error: no memory region specified for section '.got'
    

    without the config (current code in main):

    error: linking with `rust-lld` failed: exit status: 1
      |
      = note: "rust-lld" "-flavor" "gnu" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/upxtreme-c2a0d6446acbf0ac.upxtreme.f7483b69-cgu.8.rcgu.o" "--as-needed" "-L" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps" "-L" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/release/deps" "-L" "/home/dama/.rustup/toolchains/nightly-2022-02-04-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-none/lib" "-Bstatic" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/libcompiler_builtins-5c6144d7d8f77801.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/dama/.rustup/toolchains/nightly-2022-02-04-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-none/lib" "-o" "/home/dama/firmware/oreboot/src/mainboard/aaeon/upxtreme/target/x86_64-unknown-none/release/deps/upxtreme-c2a0d6446acbf0ac" "--gc-sections" "-pie" "-zrelro" "-znow"
      = note: rust-lld: error: upxtreme.f7483b69-cgu.8:(.bootblock.boot+0x3039): has non-ABS relocation R_X86_64_PLT32 against symbol '_start'
    
    opened by orangecms 15
  • 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
  • Rearrange oreboot driver modules

    Rearrange oreboot driver modules

    This pull request rearranges oreboot driver modules into one Cargo project. It also includes fixes on dependency for oreboot mainboards and SoCs to comply with this rearrangement.

    It includes following commits:

    1. Rearrange all drivers into one Cargo project
    2. Adjust architecture support modules
    3. Adapt mainboards and SoCs into new structure

    As is discussed in OSF community, the current oreboot project matches the directory structure in C-based coreboot project, it results in every driver folder it includes a complete Cargo crate. It's too heavy for each directory and we can't share incremental compilation caches in one workspace. The current project structure is familiar for C coders, but it resulted in disk usage and existence of makefiles. Also, it would be hard to prepare developing environment, especially for new Rust contributors.

    I'm working to rearrange the project, this pull request would be the first part. Except for the need of changing dependency paths, this PR does not modify working code on mainboards. This pull request does not yet include a reformation of build system.

    I adapted the following mainboards to new structure and they may produce binaries successfully:

    • aaeon/upsquared
    • aaeon/upxtreme
    • amd/romecrb
    • asrock/a300m-stx
    • ast/ast25x0
    • emulation/qemu-aarch64
    • emulation/qemu-armv7
    • emulation/qemu-fsp
    • emulation/qemu-fsp32
    • emulation/qemu-q35
    • emulation/qemu-riscv
    • google/trembyle
    • seeed/beaglev
    • sifive/hifive
    • sunxi/nezha

    After this reformation, we may furtherly arrange the oreboot project under one Cargo workspace. It would share compilation caches, and a xtask-based build framework would be possible to introduce within one arranged workspace.

    opened by luojia65 12
  • Organize oreboot project into cargo workspace

    Organize oreboot project into cargo workspace

    This pull request is a successor to https://github.com/oreboot/oreboot/pull/553, it organizes the Oreboot project into one cargo workspace.

    After this pull request, you may:

    • run cargo fmt to reformat, cargo clippy to clippy check all packages under oreboot
    • run cargo clean to clean the build cache shared by all oreboot packages
    • discover a significant compile speed boost if you build all boards

    The build framework is still based on existing Makefile system, but this reorganization would allow us to write a xtask based build framework in the future, onto project that is arranged under a cargo workspace.

    Checklist

    • [x] A proper commit message

    Details to this change

    Previously, oreboot consists of individual cargo packages. This would comply with C code, but it can't share incremental build caches. In this commit we will organize it into one workspace for cargo, in this case cargo would use the same target path so compilation caches would be shared.

    To orgainze workspace, we rearranged soc and cpu modules, as is done in driver module. This rearrangement does not include any change to working code except only for changes to dependency path.

    This commit includes changes to build.rs file, it's mostly used in FSP build and link script discovery. Changes to them will allow to detect the 3rdparty directory and search for link.ld in every path of organized workspace, so we may build them wherever we are at in the project directory.

    In Cargo [profile.release] is defined in workspace configuration, I remove them from each individual project or Cargo would warn us that this profile configuration is ignored as already been configurated by workspace.

    The commit also includes multiple clippy fixes. The project after this commit would still need makefiles to help building, but this organization to workspace would furtherly allow us to develop a xtask based building framework onto oreboot project.

    opened by luojia65 10
  • 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
  • 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 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
  • Bring back mainboard/emulation/qemu-riscv

    Bring back mainboard/emulation/qemu-riscv

    This builds, as it has been drastically stripped down.

    The sunxi nezha target should indicate how to add back drivers and such.

    Signed-off-by: Ronald G. Minnich [email protected]

    opened by rminnich 6
  • build(deps): bump regex from 1.5.4 to 1.6.0 in /src/mainboard/sunxi/nezha

    build(deps): bump regex from 1.5.4 to 1.6.0 in /src/mainboard/sunxi/nezha

    Bumps regex from 1.5.4 to 1.6.0.

    Changelog

    Sourced from regex's changelog.

    1.6.0 (2022-07-05)

    This release principally includes an upgrade to Unicode 14.

    New features:

    Bug fixes:

    1.5.6 (2022-05-20)

    This release includes a few bug fixes, including a bug that produced incorrect matches when a non-greedy ? operator was used.

    1.5.5 (2022-03-08)

    This releases fixes a security bug in the regex compiler. This bug permits a vector for a denial-of-service attack in cases where the regex being compiled is untrusted. There are no known problems where the regex is itself trusted, including in cases of untrusted haystacks.

    Commits
    • fc9ee6a 1.6.0
    • 8ddc8ec deps: bump regex-syntax to 0.6.27
    • 8c0eccd regex-syntax-0.6.27
    • dee5c25 changelog: 1.6.0
    • 9ca3099 regex: fix clippy lints up to rust 1.41.1
    • de83828 syntax: fix clippy lints up to rust 1.41.1
    • b87cd88 syntax: include only the start of the character class on error
    • 9d1478c doc: fix typos
    • 7d21662 doc: clarify Captures::len includes non-matching captures
    • 5e98788 perf: use is_match_at instead of shortest_match_at
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 6
  • build(deps): bump regex from 1.5.4 to 1.6.0 in /src/mainboard/sunxi/nezha/sbi

    build(deps): bump regex from 1.5.4 to 1.6.0 in /src/mainboard/sunxi/nezha/sbi

    Bumps regex from 1.5.4 to 1.6.0.

    Changelog

    Sourced from regex's changelog.

    1.6.0 (2022-07-05)

    This release principally includes an upgrade to Unicode 14.

    New features:

    Bug fixes:

    1.5.6 (2022-05-20)

    This release includes a few bug fixes, including a bug that produced incorrect matches when a non-greedy ? operator was used.

    1.5.5 (2022-03-08)

    This releases fixes a security bug in the regex compiler. This bug permits a vector for a denial-of-service attack in cases where the regex being compiled is untrusted. There are no known problems where the regex is itself trusted, including in cases of untrusted haystacks.

    Commits
    • fc9ee6a 1.6.0
    • 8ddc8ec deps: bump regex-syntax to 0.6.27
    • 8c0eccd regex-syntax-0.6.27
    • dee5c25 changelog: 1.6.0
    • 9ca3099 regex: fix clippy lints up to rust 1.41.1
    • de83828 syntax: fix clippy lints up to rust 1.41.1
    • b87cd88 syntax: include only the start of the character class on error
    • 9d1478c doc: fix typos
    • 7d21662 doc: clarify Captures::len includes non-matching captures
    • 5e98788 perf: use is_match_at instead of shortest_match_at
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 6
  • 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
  • Supersede probot-auto-merge with GitHub functionality

    Supersede probot-auto-merge with GitHub functionality

    Our "merge bot" (aka probot-auto-merge) is a GitHub App https://github.com/apps/probot-auto-merge which is no longer functional, operational, or maintained.

    Hosting for this project is unmaintained as there are alternatives using GitHub Actions.

    bobvanderlinden/probot-auto-merge@3da1900ecebbfc9b80e1112d4157149279f6fcaa

    • [x] #652
    • [x] #653

    Suggested way forward is to use the Github Feature:

    February 4, 2021 Pull request auto-merge is now generally available on GitHub

    See changelog for more info.

    • [x] #655
    opened by bwerthmann 0
  • Design for cbmem

    Design for cbmem

    cbmem is used throughout coreboot for managing memory regions in ramstage and romstage.

    It looks like there are some pretty unsafe code patterns required by the design currently used in coreboot (e.g. https://github.com/coreboot/coreboot/blob/master/src/include/imd.h#L53-L59).

    Would it make sense to rework the design with something like hashbrown::HashMap as the backing datastore?

    Maybe it would require writing a custom allocator?

    I looked through existing and previous mainboards, but didn't find any reference to cbmem. Is it even needed?

    I'm also new to coreboot and oreboot, so maybe I've misunderstood something.

    opened by rmsyn 4
  • aarch64 startover

    aarch64 startover

    see https://github.com/rust-embedded/aarch64-cpu

    Cortex-A has good support in Rust Embedded already. We can build on top of that and port something like a Rockchip or Allwinner ARM SoC. See also #533 and #602.

    opened by orangecms 0
  • Chromebook support

    Chromebook support

    Hi, I recently started looking at supporting Chromebook builds in oreboot.

    Maybe following a similar pattern to #533, except with the need to include an Intel binary blob (looking at an x86_64 mainboard).

    I have a Chromebook CB311-9H (octopus-bobba) piece of hardware to test on, and have started porting the C code from coreboot in my cb311 branch.

    So far, just have the EC ACPI ASL files copied over, and some of the EC code ported. Will need to add some parser code in a build.rs using the acpi crate.

    Before I go too much further, is this something that oreboot wants to pursue? I'm happy to take this on as a project, and shouldn't need too much oversight.

    Mainly just don't know how more experienced project members feel about the binary blob...

    opened by rmsyn 2
Owner
null
A highly modular Bitcoin Lightning library written in Rust. Its Rust-Lightning, not Rusty's Lightning!

Rust-Lightning is a Bitcoin Lightning library written in Rust. The main crate, lightning, does not handle networking, persistence, or any other I/O. Thus, it is runtime-agnostic, but users must implement basic networking logic, chain interactions, and disk storage. More information is available in the About section.

Lightning Dev Kit 850 Jan 3, 2023
A language server for lua written in rust

lua-analyzer lua-analyzer is a lsp server for lua. This is mostly for me to learn the lsp protocol and language analysis so suggestions are helpful. T

null 61 Dec 11, 2022
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 21 Nov 20, 2022
Benchmarking web frameworks written in rust with rewrk tool.

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

null 103 Dec 8, 2022
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 42 Dec 1, 2022
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 510 Jan 5, 2023
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 0 Dec 19, 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 6 Nov 18, 2022
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 2 Sep 6, 2022
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 6.8k Jan 2, 2023
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 56 Dec 26, 2022
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 51 Dec 26, 2022
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 21.5k Jan 8, 2023
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 36 Dec 27, 2022
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 97 Dec 21, 2022
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
DWARF packaging utility, written in Rust, supporting GNU extension and DWARF 5 package formats.

thorin thorin is an DWARF packaging utility for creating DWARF packages (*.dwp files) out of input DWARF objects (*.dwo files; or *.o files with .dwo

David Wood 19 Nov 16, 2022
A simple twitter -> telegram forwarder written in Rust.

twitter-telegram-forwarder A simple twitter -> telegram forwarder written in Rust. Example channel: https://t.me/nanabunnonijyuuni_tweet How to use it

Tommy Chiang 2 Dec 27, 2021