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>
Because we unmount the PDDB and put the system in a semi-shutdown
state, backups are not abortable if you type in the wrong root password.
This patch retries the root password forever, but also adds a note
at the beginning of the process that the process cannot be stopped
once started.
rkyv-derived enums throw warnings that they are unused.
Not sure how to get rid of them; I've tried surrounding them in
`#[allow(dead_code)]` directives, and also explicitly creating
each enum variant that I'm aware of through some dummy code and
some log prints of the dummy code calls to ensure the results are
used, and the warnings still persist.
Significantly, the warnings only happen for enums that take
a value. Simple rkyv enums do not throw a warning.
These warnings overwhelm the build logs, so they need to be isolated
in order for us to ensure that the build is clean of other more
important warnings.
The method chosen to isolate them is to take the enums that are
problematic, carve them into their own special file, and add
a file-wide `#![allow(dead_code)]` directive. This only happens
in 7 service crates, and this change commits all of the modifications
in a single big commit that could be undone later if this turns out
to be a compiler regression or something similar.
I also opened an issue with the rkyv maintainer to see what his
opinion is on the situation.
https://github.com/rkyv/rkyv/issues/318
every 1MiB block is checksummed with a sha512/256 truncated to
128 bits. This is used to confirm the media and transport integrity
only. It is not intended to be a cryptographic check, it just confirms
that the backup data was transferred correctly assuming no intentionally
malicious actors in the middle.
Most of the changes introduced in this commit were rolled back,
but, there is now a test facility that's hanging out for the PDDB
to help with future debug efforts.
The patch was motivated by a problem observed in FSCB consistency
when it's updated. Ultimately the root cause was traced to a
cache coherence problem and it's fixed by a patch in the spinor
crate.
However, this patch still retains a check that the data is coherent,
in case the flushing routine isn't complete or some other factor
was missed. It also includes a large amount of commented-out code
that keeps a bit of history used to debug the problem -- eventually,
we can just cull that but it's kept around in case we got the
root cause wrong (or there were multiple causes and coherence is
just one of them).
after updating a piece of FLASH memory, there is an inherent
cache coherence issue. This is because the write happens through
a side channel that is outside of the memory model of the system:
writes happen through a CSR that feed data to pages of FLASH.
Reads happen through direct-mapped memory regions that are unaware
of write mutations.
Thus, after writing a page of memory, if you try to access it,
sometimes you'll read the old cached value instead of the new
updated value.
This patch introduces a mandatory dcache flush after every
FLASH write, so that any cached FLASH regions are re-fetched.
this tries to catch the cases that:
- user tried to run the backup without first running "prepare backup..."
- the USB connection is a little flakey and returning bum data
We can only inspect the plaintext portions of the header, which contains
things like protocol version numbers, time stamps, and language codes.
We use the timestamp validation heavily because it's the only field that
isn't almost always going to be a 0 or 1 when correct, which are highly
likely to be reported anyways if there's a problem with the USB link.
This does assume the user sets the time correctly on the device
doing the backup, and on the Precursor itself.
