| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Bugfix after new port of libcli where this enabling doesn't happen after
every command anymore.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Also rename all instances of GNUmakefile to Makefile.
|
|
|
|
STM32 HAL code directly.
|
|
Makes more sense to keep them together, at least in the cli-test.
|
|
|
|
|
|
|
|
|
|
DMA is more efficient and less prone to miss characters than interrupts.
An open question is if circular mode is really the best. If someone
copy-pastes more than the RX buffer size of configuration into the CLI,
we risk the DMA controller catching up with the reader and overwriting
data not yet read.
Since we don't have flow control back to the users terminal, we will
always fail if too much data is entered before we can process it. The
question is if failing to stuff new data at the end of a buffer might be
better than data being overwritten - thus messing up the commands in
unpredictable ways.
|
|
|
|
|
|
|
|
|
|
|
|
This bootloader is now the application at 0x08000000 (FLASH start),
which the STM32 will execute upon reset.
The other applications are now loaded at 0x08030000 (128 KB into the
flash) and will never get started unless the bootloader has been
programmed into flash too.
|
|
The applications to be uploaded using 'dfu upload' have to have another
FLASH defined in their linker script.
Have to recompile some firmware tomorrow and test if this actually
works.
|
|
Committing my work in progress in case someone else wants to help.
|
|
|
|
Integrated into the cli-test program as such:
cryptech> test sdram
Initializing SDRAM
Starting SDRAM test (n = 0)
Run sequential write-then-read test for the first chip
Run random write-then-read test for the first chip
Run sequential write-then-read test for the second chip
Run random write-then-read test for the second chip
Run interleaved write-then-read test for both chips at once
SDRAM test (n = 0) completed
SDRAM test completed successfully
cryptech>
|
|
|
|
|
|
Hopefully, having this excitement now makes adding commands a little bit
less exciting from here on.
|
|
Also add code to erase FPGA config memory and check status of FPGA_DONE.
|
|
Move the N25Q128 code to it's own file in order to be able to reuse it
for the keystore memory code.
|
|
This code needs more error checking etc. but together with the Python
script 'filetransfer', a new bitstream may be loaded into the FPGA
config memory like this:
filetransfer --fpga /path/to/bitstream
The bitstream is identified by 'file' e.g. like this:
alpha_test_top.bit: Xilinx BIT data - from
alpha_test_top.ncd;UserID=0xFFFFFFFF - for 7a200tfbg484 - built
2016/05/12(13:59:24) - data length 0xe0164
|
|
|
|
|
|
|
|
|
|
|
|
Don't want to wait longer than necessary for firmware file transfers.
|
|
|
|
|
