| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Basic stuff like "keystore show keys", "keystore delete key", and the
PIN commands all work with the new keystore code.
Some of the management commands are still broken. Some of the old
management commands were using libhal-internal APIs for which no real
equivalent exists anymore. Some of the old management commands were
doing things that, um, never could have worked as written.
|
|
|
|
|
|
|
|
|
|
(dropped characters, improper handoff of message buffers).
Fixed by
a) changing the uart receiver from interrupt to DMA mode, and
b) replacing the dispatch mutex and rpc semaphore with a mail queue
(memory pool + message queue).
|
|
|
|
Bugfix after new port of libcli where this enabling doesn't happen after
every command anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'show' commands.
|
|
|
|
|
|
|
|
|
|
as name.
|
|
A lot of the commands were just useful when testing/implementing
features for the Alpha. Remove them now that they have been merged to
projects/cli-test.
|
|
There seems to be a timing issue (?) with the MKMIF. If SCLK_DIV is
set to a higher value (was: 0x20) then the CLI command "test mkmif" will
fail with only occasional success runs. With divisor 0x01, it works most
of the time but not allways.
|
|
|
|
|
|
Command parser now enforces little things like mutually-exclusive
required options so we warn users who attempt something silly.
Preferred source for uploads is now the firmware tarball installed
along with the client software; we still support uploading from an
explictly-specified source file, but one must now say "-i file".
Updating the bootloader is dangerous, we now say so and also require
an additional option before we'll even attempt it. For the record,
while testing this I did manage to brick my Alpha and had to use an
ST-LINK to recover, exactly as predicted by the new dire warning.
|
|
|
|
|
|
like ssh-agent.
|
|
Also, if the UART receive callback fails to re-enable receive (because
dispatch_thread is in the middle of transmitting a response), signal
dispatch_thread to re-enable receive after it's done.
|
|
|
|
|
