The code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.
The "main" product line is affected here in that the UART
init is hosted above the trng init. This should have no impact
on security or boot time, but allows us to more easily debug
TRNG init issues. This is necessary because in the vexii test
version the XADC interface is broken by the slower clocking
and I'm not taking the time to trace down that issue as it
does nothing to further the goal of testing the vex-ii core
in a non-production config.
legacy_int handler allows vex-ii to emulate/behave like the vex-i
in terms of interrupt handling.
eventually this will be replaced with/augmeted by a PLIC.
not doing a reformat of the entire project to match
nightly formatting changes, but capturing the published
crates so we can maybe save a version bump later on to get
the project clean.
apply the same techniques in the loader key generator to
the kernel TRNG. Every pull of data from the kernel reseeds
the TRNG state as well. This makes server ID creation somewhat
more expensive, but should greatly improve the security of
the system in the case of a TRNG with occassional drop-outs.
Shoot for 256 bits minimum entropy in the seed pool, gives us
some safety margin over our required 128.
note that the pool only gets more entropy over time, as every
call to the pool folds more entropy in (roughly 2 bits per call).
using the DUART means we don't get console input on the kernel
(because the DUART is incapable of this) but it's a decent compromise
I think because the DUART is fast and efficient, and mostly we want
it to capture kps?
Eventually we'll need an input mode but for now, this will get us
moving.
Disable IRQs during destruction, but only if constructed with
`GdbUart::new()`. This allows characters to buffer when the GDB bridge
is destroyed while avoiding the double-free error we were getting from
creating a new UART in the IRQ handler.
Signed-off-by: Sean Cross <sean@xobs.io>
This adds a basic gdb server. Currently, it is possible to list
processes and inspect memory and threads. It is not yet possible to
actually interact with code (e.g. no breakpoints and no single
stepping).
Signed-off-by: Sean Cross <sean@xobs.io>
Add an initial reimplementation of the gdb-stub using the gdbstub
backing crate.
This supports process enumeration and basic thread investigation.
Processes will pause when the debugger is inspecting them. Memory and
registers can be investigated. Threads can be listed and selected.
It does not yet support breakpoints.
Signed-off-by: Sean Cross <sean@xobs.io>
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>
