aaf16dcf5e
This is a "no good choice" situation but there is a problem with progress bars. You want progress bars to update quickly, and you don't want to have to context switch out for the entire graphics stack to come back to you to approve the drawing of your progress bar update. On the other hand, you don't want to short-circuit all the checks on drawing stuff to the screen for the sake of progress bars -- right now, there are a number of checks in place to make sure you can't draw stuff on parts of the screen you shouldn't, to avoid fake messages and dialog boxes. I had managed to work out a way to get a dialog box to redraw without violating the security rules -- each redraw is checked by the defacing routine -- however, due to the way I was computing the height of the modal I was causing the dialog box to be resized to its largest size and then shrunk again to fit the text every iteration. This in essence also caused the defacement routine to run repeatedly, which caused the GAM to also issue repeated redraw requests to the main loop. These redraw requests can't be serviced until the task being tracked by the progress bar is completed. As the progress bar gets redrawn almost a hundred times as part of the task, roughly a hundred messages arrive in the server's queue before it can handle a single one. This results in a deadlock situation on completion of the progress bar, because we want to fire off a message to ourselves to go to the next state in the Ux routine. There are a few possible solutions to this: 1. Multi thread the heck out of the routine doing the progress bar, so the dialog box and the slider are each in their own threads with their own responders and then the thing doing the computation is doing some Mutex-guarded-Arc thing. 2. Do some very unsafe bodge to allow sliders to do direct draws that are unchecked 3. Add a check so that if the size of the dialog box doesn't change, defacement isn't recomputed and thus redraw messages aren't sent back. (1) doesn't work for a number of reasons -- in a general case, it's probably OK, but it does cause a lot more memory usage (and we are lean on memory); but more importantly, for this use case, our routine is interacting with CSRs and those don't implement Send so you can't pass them into a thread via a closure. You could maybe put the dialog boxes themselves into an Arc Mutex thing but because this routine was heavily coded to re-use the heavyweight Ux resources this becomes a bit cumersome to code. (2) is terrible (3) ended up working and what is in this commit. I think it's OK because a progress bar generally doesn't require changing the size of a window to update its state; therefore the redraw is deface-safe (since you aren't changing the bounds of what you were already approved to draw in). Of course, if you have some sort of a progress bar implementation that changes the size of the messages reported up top so that the dialog box has to change size over and over again, you still end up in the deadlock situation! |
||
|---|---|---|
| .cargo | ||
| .vscode | ||
| devkey | ||
| docs | ||
| emulation | ||
| imports | ||
| kernel | ||
| LICENSES | ||
| loader | ||
| locales | ||
| macros | ||
| precursors | ||
| services | ||
| svd2repl | ||
| svd2utra | ||
| tools | ||
| utralib | ||
| xous-ipc | ||
| xous-rs | ||
| xtask | ||
| .gitattributes | ||
| .gitignore | ||
| buildpush.bat | ||
| buildpush.sh | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| README.md | ||
| RELEASE-v0.8.md | ||
| start-gdb.sh | ||
| wb-gdb.sh | ||
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
There's some Python scripts to help deal with firmware signing. Ensure the following python packages are available in your environment: pycryptodome (signing - PEM read), cryptography (signing - x509 read), pynacl (signing - ed25519 signatures). If you plan on doing USB firmware updates, you'll also need progressbar2 (updates), pyusb (updates).
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:
rustup target add riscv32imac-unknown-none-elf
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.
An example file may be found under svd2utra/, but this is probably
out of date and won't work with your device.
Pass this .svd file to the hw-image xtask command:
cargo xtask hw-image svd2utra/examples/soc.svd
This will compile all runtime packages for riscv32imac-unknown-none-elf, and
will generate a release image under the target/ directory, which will be printed
on the output.
The image should be written to location 0x2050_0000 (SPI ROM offset 0x50_0000), using
the provision-xous.sh script inside betrusted-scripts
running on a Betrusted provisioning harness, that is a Raspberry Pi 4 with the appropriate debug hat attached, and the Precursor hardware plugged into the debug hat. You can also check out the dvt-hardware branch for the WIP integration of all the above commands.