I've added a `platform` module to store all platform specific code, (not
architecture specific) as some platforms will require custom drivers, e.g.
for debug output and for the random number generation code. The platform
code is in charge of mapping any peripherals needed to work, also to
initialize any other parts of the kernel that require drivers, for example
the debug shell.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
This allows for a more reliable detection of target_os configuration
in build scripts. The target is inconsistent between some architectures,
notably armv7a is `armv7a-none-eabi` skipping the `unknown` (the vendor,
I guess) part. This happen with some of the unrelated Cortex-M targets
present, and others may also be.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
- strip out gdb-stub. Per xobs, the feature never worked, and it
depends upon a branch of a git repo which is not allowed by crates.io
Since the feature hasn't been developed, and crates.io will not
allow even an optional feature that points to a git repo, the feature
was stripped out.
- rename "kernel" to "xous-kernel", so that we can live in a crates.io
package namespace that is specific to Xous.
still have to figure out the riscv package issue.
this will help speed up performance profiling as we can
resolve the physical address of the performance buffer allocated
in RAM and use a USB command to read it out, instead of streaming
it over serial.
Instead of passing a constructed mutable ref from the pagetable entry,
pass a raw pointer and use `read_volatile()` / `write_volatile(x)` on
this pointer.
This should remove a little bit of UB from the kernel.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, the kernel would dutifully try to map memory that was in the
kernel space. It did this by investigating the kernel memory offset,
which immediately causes a double-fault.
Check to make sure a userspace process is not trying to map kernel
memory before checking the valid page.
Signed-off-by: Sean Cross <sean@xobs.io>
Implement the syscall to adjust a process' limit. Currently this
only supports adjusting the heap maximum and the heap size.
In order to adjust a limit, you must first present the current limit.
This can be obtained by requesting a bogus value. The current limit is
returned as part of the result.
Signed-off-by: Sean Cross <sean@xobs.io>
