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.
This relies on a trick I was not aware of previously, which is
that transitive dependencies absorb the additive set of features
enabled within a crate.
see
https://doc.rust-lang.org/cargo/reference/features.html#feature-unification
for the full description. but basically by referring to the feature
required in "aes" despite not being used in the crate but pulled
in by aes-gcm-siv, i can ensure that the transitive dependency
is in fact used.
I think this was always there but previously I just didn't understand
it correctly or didn't use it right when I tried to deploy it, but
this time I think I got it right.
Based on this benchmark of elapsed_ms():
```rust
pub fn elapsed_ms(&self) -> u64 {
let response = send_message(
self.conn,
xous::Message::new_blocking_scalar(api::Opcode::ElapsedMs.to_usize().unwrap(), 0, 0, 0, 0),
)
.expect("Ticktimer: failure to send message to Ticktimer");
if let xous::Result::Scalar2(upper, lower) = response {
upper as u64 | ((lower as u64) << 32)
} else {
panic!("Ticktimer elapsed_ms(): unexpected return value.");
}
}
```
We find the following context switches:
1. send_message -> kernel/src/syscall.rs @ 166 - ss.remember_server_message()
- *context switch round trip* to enqueue the message into the target thread's space, then switch back.
- takes 546ns just in the target context, out of 4430ns round-trip
(measured as leave userspace of caller to enter userspace of callee) (12% of total time)
- emplaces the message in the target queue
- generates "sender_idx" which is the index in the message queue to find the message, which is put into Envelope
2. send_message -> kernel/src/syscall.rs @ 222 - ss.activate_process_thread()
- activates the thread to run
- Total penalty is closer to 1us - 22% of total time - once pre/amble/post-amble overhead considered
This set of patches removes the context-switch round trip to emplace messages in the target's thread
space, as well as to set thread results, by passing them as arguments to `activate_process_thread`.
What then happens is that these items are emplaced after the activation privot to the target
process space occurs, saving a set of TLB-flushes and page table walks.
More testing is required, but at least on a reasonable set of cases the system seems to be stable
with these patcehs, and we get a 24% speedup on blocking scalar messages and 8% speedup on
mutable lends in the case that the target is waiting to receive messages.
The double-flush in activate() has a big impact on performance,
and I'm pretty sure it only needs to happen after the SATP update
not before, at least architecturally. Eliminating the extra
flush improves the fast message passing benchmark time by 9%.
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.
1. Instead of panicing when a page is re-requested, return an
error message to the caller. This allows us to have the UART
pre-allocated by the loader and the kernel to request it prophylactically
2. add A/D flags for R/W pages in vexii-testing. This is a work-around
until we have proper A/D tracking in the page lifecycle mechanism.
cramium-soc i think should be deprecated everywhere because
it is redundant with the board targets: anywhere you see a board
target that includes the crossbar soc it should also transitively
pull in the cramium-soc dependency equivalents.
we'll chase this out more later, but for now we're just trying
to get the PDDB to compile
this is a much simpler, race condition-free version of flash
writing which has the penalty of requiring a copy of the page
to be made by the caller before the write. However the
copy is mostly already paid for because on the initial access
to the page, we had to copy the flash into RAM.
this is a fairly major re-org of where key constants go that
define platform features. things that were in xous-rs that were
platform specific (namely precursor) were moved into a boards file,
and things that are generic to the system (like PAGE_SIZE) are moved
to a public location in xous-rs::arch.
this is probably the most significant source of consternation but
also this code path has been fairly well-trodden.
That being said it might be worth considering if there is any
way to use some of the new Rust const based reasoning logic
to see if we can't tighten this up someday, but today is not
that day.
