| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
We really don't want SysTick_Handler, which runs the task scheduler, to
run at a higher priority than SVC_Handler, which runs supposedly-atomic
operations like mutex locking and unlocking. I've seen a mutex lock/unlock
mismatch which I think is due to interrupting rt_mut_release at a
particularly inopportune moment.
|
|
|
|
|
|
|
|
Apparently it's easier to duplicate source files into multiple project
directories than to write Makefiles that do something sane. Feh.
|
|
|
|
|
|
Fetching a list of keys and all of their metadata isn't an atomic
process, nor, probably, should it be, so we need to cope with things
like a key being deleted via the RPC interface while we're fetching
its metadata for display on the console interface.
|
|
|
|
buffer, because we've observed out-of-order receives under load.
|
|
If hal_rpc_server_dispatch() returns an XDR decode error because the
request packet was too short, don't call Error_Handler() and kill the
dispatch thread, just drop the request.
Add more ibuf_queue entries, but don't panic and kill the dispatch thread
if we can't get one, just drop the incoming character (which will lead to
an XDR decode error if/when we finally get an ibuf).
|
|
|
|
We need to start with a long serial timeout, in order to catch the reboot
messages for a firmware upload (this has to be done through the bootloader).
But once we start sending the file, cut the serial timeout to 1ms. (I've
tested it down to 1us, but that may not work for everyone, and it doesn't
improve performance in a statistically significant way.)
This brings the time to upload a 4.5MB bitstream from 38:23 to 1:25.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The main loop in cryptech_upload:send_file() was much more complicated
than necessary, and also contained some hidden assumptions about
serial I/O timing which happened to fail on the first two machines I
tested. We already had a perfectly good buffered-input function, so
rewrote to use that, and simplified control structure in the process.
In theory, the new code should work in any environment where the old
one did, but this has not yet been confirmed.
|
|
|
|
Bootloader DFU fixes.
|
|
|
|
|
|
to flash. While we're at it, propagate error returns.
|
|
fix to cli-test, commit ae8ebce.
|
|
Drag in UART-related changes from master.
|
|
|
|
|
|
|
|
|
|
Wrong-block-type race condition errors went away after adding the WIP
check after flash write operations, then came back once (isolated
incident) while running a series of tests which had written enough
flash blocks that ks_flash may have finally had to erase something
rather than just zeroing.
Code inspection confirmed that the erase code was not waiting for WIP
to clear before exiting. Difficult to prove that this was the cause
of an unreproducible failure, but seems like a likely candidate given
previous behavior and change should be harmless, so adding it.
Timeout for this flag check is 2000 ms, which is what other
erase-related WIP flag checks were already using.
|
|
Using {-1} as a client handle in the CLI is a kludge, but the new
stricter libhal keystore code really wants us to be consistent about
this, so as long as any part of the CLI is using client {-1}, it all
needs to do so.
This still isn't really right, the CLI probably needs a different set
of access rules than those which apply to the RPC calls, but I'm
deferring that until we know what the "final" (for this branch)
version of the RPC API looks like, and have done whatever refactoring
might be required in the libhal keystore drivers.
|
|
Absence of this check created a nasty race condition in
sw/libhal/ks_flash.c, which didn't show up until we had test code
which attempted to delete a long series of keys in quick succession.
I'm not aware of any sane reason why we would ever want to skip this
check, so it's unconditional and applies to all of the SPI flash code,
not just the keystore flash code.
|
|
|
|
|
|
|
|
Now that we're using more than just the first few sectors of the
keystore flash, we need a command to clear the whole thing.
This is not quite right yet, because it doesn't yet notify libhal's
ks_flash driver that the entire content of the flash has been yanked
out from under it.
In theory, we should be able to erase the entire flash in a single
operation using the bulk erase command command (0xC7), but I couldn't
get that to do anything (no error reported, no visible effect), so,
for now, we erase by sectors.
|
|
|
|
|
|
receive buffer with half-complete callbacks, and raise the dma priority.
|
