Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
The first "app" is just going to be a whole-framebuffer
demo that gets raw keys and does some stuff on the screen.
It's the starting point if you wanted to eg. write a simple
video game or something for the device, but you didn't care
about much of the other UX sugar.
Add the loader into the main workspace, removing it from its own
sub-workspace. We can do this now that we can specify the linker script
in `build.rs`.
This improves IDE support, and should shrink disk storage requirements.
Signed-off-by: Sean Cross <sean@xobs.io>
This moves the kernel into the main monorepo, allowing it to share
packages with the rest of the system. This change will allow us to
reduce the number of rebuilds that take place, as well as reducing disk
usage.
Note that the loader is still an indepenent project, and the integration
of that into the monorepo is pending.
Signed-off-by: Sean Cross <sean@xobs.io>
- code is merged into shellchat so there's less alignment overhead
and some library reuse
- server is not spawned until it's needed, so the RAM load is less
Saves a bit on resources and the RTC crate doesn't need
to be stand-alone now that the modals crate is a thing;
we are able to split the UX routine to manage the RTC out
of the code that actually manages the hardware.
The hardware code ended up in LLIO, and the UX ended up in the status
routine.
Closes#76
The test vectors in wycheproof-import/x25519_test.json correspond to the upstream commit 4672ff74d6.
For details see wycheproof-import/README.md.
Signed-off-by: Fabian Weißberg <fabian.weissberg@tu-dortmund.de>
we are at least now only requiring users to use our patched
curve25519-dalek crate, which now builds cleanly in both
xous and std environments, but the higher-level crates can be
directly used from crates.io
the engine-25519 server just takes microcode jobs and runs them
on the curve25519 accelerator engine.
all the fancy crypto stuff comes from other crates, which will
be filled in later.
