Xous SDK (pinned for betrusted transpilation)
Find a file
bunnie fe04f5684f fix a critical bug that prevents root key initialization
This is going to require users to update their devices before
doing a key initialization.

The problem is that we can't trust the length of data presented
to us to self-sign, so we sign the whole area. In v0.9.2 of the
loader, a check was introduced to check the putative length of
the signed area against the actual length of the signed area,
by encoding the length of the signed area within the signed
region.

This would require the rootkeys algorithm to also encode that
new length at the end of the signed area, but this was never
done. However, this bug was never found during testing probably
because I failed to completely erase the original key provisioning
(I was more fixated on checking that existing keys were not damaged by
firmware updates at the time), and thus did not trigger a full
rootkey provisioning cycle when I did the test. I had only just
caught it now while porting the PDDB from simulation to real
hardware.
2022-01-03 19:06:21 +08:00
.cargo
.vscode update a comment in the readme. 2021-11-23 15:55:27 +08:00
devkey beginnings of image signing 2021-07-06 17:31:09 +08:00
docs Update flash.md 2021-10-23 18:35:21 +08:00
emulation fix permissions 2021-10-27 23:06:13 +08:00
imports disastrous first draft of figuring out how to integrate smoltcp using a ping example. 2021-10-10 01:57:31 +08:00
kernel retrofit the seed into an atomicu64 so we can set it elsewhere 2021-12-27 02:49:08 +08:00
LICENSES creating LICENSES directory 2021-01-25 14:52:31 +01:00
loader fix a critical bug that prevents root key initialization 2022-01-03 19:06:21 +08:00
locales fix permissions. windows is sort of stupid and makes everything +x 2021-08-19 23:34:29 +08:00
macros fix permissions. windows is sort of stupid and makes everything +x 2021-08-19 23:34:29 +08:00
precursors add precursors that fix the loader signature check as well 2021-11-02 03:54:15 +08:00
services fix a critical bug that prevents root key initialization 2022-01-03 19:06:21 +08:00
svd2repl emulation: fix betrustedsoci2c implementation 2021-08-30 15:12:13 +08:00
svd2utra clean up some warnings before moving on to further integration 2022-01-02 15:07:48 +08:00
tools make the CI options command line driven 2022-01-02 16:41:23 +08:00
utralib
xous-ipc fix permissions. windows is sort of stupid and makes everything +x 2021-08-19 23:34:29 +08:00
xous-rs commit unsaved changes meant to be part of previous commit 2021-12-27 12:32:18 +08:00
xtask make the CI options command line driven 2022-01-02 16:41:23 +08:00
.gitattributes gitattributes: add txt as lf 2021-03-10 17:36:41 +08:00
.gitignore revert vscode settings for a merge to main 2021-11-23 15:49:25 +08:00
API.md add a note on callback implementations 2021-11-01 03:53:10 +08:00
buildpush.ps1 modify salt generation scheme 2022-01-02 17:53:00 +08:00
buildpush.sh cleanup build script 2021-08-24 21:28:00 +08:00
Cargo.lock add formatting check and UX flow for formatting; redo salt (again) 2022-01-03 16:51:51 +08:00
Cargo.toml basic framework for modal API wrapping in place 2021-12-15 13:46:24 +08:00
CODE_OF_CONDUCT.md
CONTRIBUTING.md initial commit 2020-03-10 12:13:05 +08:00
README.md Update README.md 2021-10-28 00:34:10 +08:00
RELEASE-v0.8.md clean up release notes 2021-09-05 20:46:23 +08:00
RELEASE-v0.9.md update some docs to refer to the modals refactor 2021-12-17 02:59:18 +08:00
rustfmt.toml finalize formatting run 2021-08-20 00:26:16 +08:00
start-gdb.sh try to layer in the fcc agent 2020-12-31 19:31:12 +08:00
wb-gdb.sh add helper script for wishbone gdb 2021-01-13 23:18:30 +08:00

Xous Core

Core files for the Xous microkernel operating system.

You might find this collection of Xous documentation handy.

This repository contains everything necessary to build the Xous kernel from source. It consists of the following projects:

  • kernel: core memory manager, irq manager, and syscallhandler
  • loader: initial loader used to start the kernel
  • tools: programs used to construct a final boot image
  • docs: documentation on various aspects of Xous
  • emulation: Renode scripts used to emulate Xous
  • xous-rs: userspace library

Dependencies

  • Xous requires its own Rust target, riscv32imac-unknown-xous-elf. If you run cargo xtask from the command line, you should be prompted to install the target automatically if it does not already exist.
  • You may need to remove the target/ directory before building, if rustc continues to behave like it can't find the xous target even after it is installed.
  • If you plan on doing USB firmware updates, you'll need progressbar2 (updates) and pyusb (updates). Note that pyusb has name space conflicts with similarly named packages, so if updates aren't working you may need to create a venv or uninstall conflicting packages.
  • If you are doing development on the digital signatures with the Python helper scripts, you will need: pycryptodome (signing - PEM read), cryptography (signing - x509 read), pynacl (signing - ed25519 signatures) (most users won't need this).

Quickstart using Hosted Mode

You can try out Xous in a "hosted mode" wherein programs are compiled for your native platform and are run locally as processes within your current operating system. System calls are replaced with network calls to a kernel that simply shuffles messages around.

Xous uses the xtask convention, where various complex build commands are stored under cargo xtask. This allows for us to create arbitrarily complex build sequences without resorting to make (which is platform-dependent), sh (which requires a lot of external tooling), or another build system.

To build a set of sample programs and run them all using the kernel for communication, clone this repository and run:

cargo xtask run

This will build several servers and a "shell" program to control them all. Most notably, a graphics-server will appear and kernel messages will begin scrolling in your terminal.

Quickstart using an emulator

Xous uses Renode as the preferred emulator, because it is easy to extend the hardware peripherals without recompiling the entire emulator.

Download Renode and ensure it is in your path. Then, build Xous:

cargo xtask renode-image

This will compile everything in release mode for RISC-V, compile the tools require to package it all up, then create an image file.

Finally, run Renode and specify the xous-release.resc REnode SCript:

renode emulation/xous-release.resc

Renode will start emulation automatically, and will run the same set of programs as in "Hosted mode".

Generating a hardware image

To build for real hardware, you must specify an .svd file. This file is generated by the SoC build process and describes a single Betrusted core. These addresses will change as hardware is modified, so if you distribute a modified Betrusted core, you should be sure to distribute the .svd file.

We have included a reference version of the gateware and its SVD file in the precursors directory, so you can compile a gateware for the reference image using this command:

cargo xtask hw-image precursors/soc.svd

The resulting images are in your target directory (typically target/riscv32imac-unknown-xous-elf/release/) with the names xous.img (for the kernel) and loader.bin (for its bootloader). The corresponding gateware is in precursors/soc_csr.bin. These can be written to your device by following the update guide.