The error would cause one page too much to be marked as read only.
Instead, calculate the appropriate page table indices for the read-only
region together with a comment explaining the subtraction by one.
* Fix two timing issues in delays.rs
These changes correct the implementations of delays::SysTmr::wait_msec_st
and delays::wait_msec to behave correctly and consistently with one another.
* Port delay fix from 09_delays to 0B_exception_levels
I believe this covers all copies of this bug in the codebase.
* Rebuild tutorial kernels with delay fixes
The previous implementation of uart::dec() forced the compiler to emit a
software out-of-bounds acces check into the code, bloating it a bit. Prevent
that by using an iterator instead.
Same is true for the ordinary division operator that was used in multiple places
in the benchmark code. Here, the compiler emitted software-checks for divison by
zero. Prevent this by using `checked_div()` where we can implement our own
"panic" handling.
The previous benchmark function had a few flaws. First of all, it wasn't
idiomatic Rust, because we used a loop construct that you would expect in C.
Revamped that by using an iterator. Also, the previous benchmark got heavily
optimized by the compiler, which unrolled the inner loop it into a huge sequence
of consecutive loads and stores, resulting in lots of instructions that needed
to be fetched from DRAM. Additionally, instruction caching was not turned on.
The new code compiles into two tight loops, fully leveraging the power of the I
and D caches, and providing an great showcase.
The new target is not automatically using PIC.
Need some linker script corrections for errors that were hiding
previously, so that we don't accidentally generate alignment
exceptions on bss size variables that cause the target to fail.
We have a generic target for writing bare-metal code
for 64-bit ARM architectures in upstream Rust now.
Use it to get rid of the fully custom target spec.
\o/
Despite invoking clippy with xargo, it wasnt actually using the custom
target, so we don't need xargo here for now...
The target argument was missing anyways. Using it throws an error.
Needs some more investigation.