[Cryptech-Commits] [sw/stm32] 02/02: Update and expand README
git at cryptech.is
git at cryptech.is
Tue May 1 21:43:38 UTC 2018
This is an automated email from the git hooks/post-receive script.
paul at psgd.org pushed a commit to branch master
in repository sw/stm32.
commit 6018d41414ef013f79df36d0b232cec8c5de5e47
Author: Paul Selkirk <paul at psgd.org>
AuthorDate: Tue May 1 17:41:11 2018 -0400
Update and expand README
---
README.md | 163 +++++++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 103 insertions(+), 60 deletions(-)
diff --git a/README.md b/README.md
index 6d813ef..e2c10a8 100644
--- a/README.md
+++ b/README.md
@@ -1,80 +1,127 @@
-STM32 software for dev-bridge/Alpha board
-=========================================
+STM32 firmware for Cryptech Alpha board
+=======================================
-The dev-bridge board is a daughterboard for the Novena, which talks to the
-Novena's FPGA through the high-speed expansion connector.
+The Alpha board is our first full prototype for an open-source hardware
+security module (HSM). It is a custom board with an STM32 Cortex-M4
+microcontroller and an Artix-7 FPGA, flash-based keystore, separate memory
+for the Key Encryption Key, etc. See the `hardware` repository for
+schematics and production files. See the wiki for design documents.
-The Alpha board is a stand-alone board with an Artix-7 FPGA, a STM32 Cortex-M4
-microcontroller, two USB interfaces etc.
-
-See user/ft/stm32-dev-bridge/hardware/rev01 for schematics of the bridge
-board. There will be more information on the wiki shortly.
+The code in this repository builds the firmware that provides the HSM
+functionality on the Alpha board.
+There is some residual code here to support the "dev-bridge" board, a
+daughterboard for the Novena, which talks to the Novena's FPGA through the
+high-speed expansion connector. Only a few of these boards were ever made,
+and all development/testing ceased as soon as the Alpha became available,
+so the dev-bridge should be considered deprecated, and support may be
+removed in the future.
Copyrights
==========
The license for all work done on this in the CrypTech project is a
-3-clause BSD license (see LICENSE.txt for details). Some files have
-been generated using the STMicroelectronics initialization code
-generator STM32CubeMX and thus have additional copyright header(s).
+3-clause BSD license.
+
+Third-party components, as well as code generated using the
+STMicroelectronics initialization code generator STM32CubeMX, or adapted
+from STM example/support code, may have different licensing, detailed
+below.
+
+Components
+==========
+
+Libraries
+---------
+
+* `mbed` - A stripped down copy of the ARM CMSIS library, copied from the
+ mbed github (see `libraries/mbed/README.txt` for details). The bulk of
+ this library is covered under 3-clause BSD licenses from either ARM or
+ STMicroelectronics, but one file is covered under an Apache license from
+ ARM.
+
+* `libhal` - Build directory for our own Hardware Adaption Library
+ (hardware-independent Cryptech components). Source is expected to be in
+ `sw/libhal`.
+
+* `libtfm` - Build directory for "Tom's Fast Math", which is used heavily
+ for bignum math in the RSA and ECDSA code. This code is covered under an
+ unrestricted public domain license, and source is expected to be in
+ `sw/thirdparty/libtfm`.
+
+* `libcli` - Build directory for a third-party Command Line Interface
+ library. The source is not currently under `sw/thirdparty` because the
+ license is LGPLv2.1; we are negotiating to see if we can get a
+ BSD-compatible license for it.
+
+* `libprof` - A port of the `gmon` profiling package, to be used in
+ development only, not in production code (obviously). The licensing is a
+ mix of BSD and "Cygwin license", which now seems to be LGPLv3.
+
+Projects
+--------
-The "Noise generator" and "Amplifier" parts of the circuit diagram are
-copied from Benedikt Stockebrand's ARRGH project. ARRGH copyright
-statement is included in LICENSE.txt.
+These directories build different firmware images for the Alpha board.
-A stripped down copy of the ARM CMSIS library version 3.20 is included
-in the Drivers/CMSIS/ directory. Unused parts (and documentation etc.)
-have been removed, but every attempt have been made to keep any
-licensing information intact. See in particular the file
-Drivers/CMSIS/CMSIS END USER LICENCE AGREEMENT.pdf.
+* `hsm` - Firmware providing HSM functionality. Clients communicate via
+ RPC requests on the USER USB port, or interactively on the MGMT USB
+ port.
-A full copy of the STM32F4xx HAL Drivers is included in the
-Drivers/STM32F4xx_HAL_Driver/ directory.
+* `bootloader` - The first thing that runs on the device. It either starts
+ the primary firmware, or installs new firmware.
+* `board-test` - Tests of hardware components.
+
+* `cli-test` - Test of the CLI itself, plus some interactive tests of
+ hardware components. Duplicates way too much of the HSM CLI.
+
+* `libhal-test` - A framework for running the libhal component
+ tests. Hasn't been run in a while, probably still works.
Building
========
-The following packages need to be installed (on Ubuntu 14.04):
+Our primary build environments are Debian and Ubuntu, but this should work
+on any system with Gnu tools installed.
- apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd
+The following packages need to be installed:
-To build the source code, issue "make" from the top level directory
-(where this file is). The first time, this will build the complete STM
-CMSIS library. A subsequent "make clean" will *not* clean away the CMSIS
-library, but a "make distclean" will.
+ $ apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd
+The Makefile assumes that all Cryptech repositories have been fetched into
+a canonical directory structure, e.g. `libhal` and `thirdparty` are
+siblings to this directory, under `sw`.
+
+To build the source code, issue `make` from the top level directory
+(where this file is). The first time, this will build the complete STM
+CMSIS library. A subsequent `make clean` will *not* clean away the CMSIS
+library, but a `make distclean` will.
Installing
==========
-Do "bin/flash-target" from the top level directory (where this file is)
+Do `bin/flash-target` from the top level directory (where this file is)
to flash a built image into the microcontroller. See the section ST-LINK
below for information about the actual hardware programming device needed.
-Example loading the bootloader and the led-test firmware to get some LEDs
-flashing:
+Example loading the HSM firmware:
- $ make bootloader board-test
- $ ./bin/flash-target projects/board-test/led-test
- $ ./bin/flash-target projects/bootloader/bootloader
+ $ make hsm
+ $ ./bin/flash-target projects/hsm/hsm
At this point, the STM32 will reset into the bootloader which flashes the
-blue LED five times in one second, and then execution of the LED test
-firmware will begin. The LED test firmware will flash the green, yellow,
-red and blue LEDs in order until the end of time.
+blue LED five times in one second, and then jumps to the primary firmware.
Once the bootloader is installed, regular firmware can be loaded without
an ST-LINK cable like this:
- $ ./bin/dfu projects/board-test/led-test.bin
+ $ cryptech_upload --firmware -i projects/hsm/hsm.bin
Then reboot the Alpha board.
-
ST-LINK
-=======
+-------
+
To program the MCU, an ST-LINK adapter is used. The cheapest way to get
one is to buy an evaluation board with an ST-LINK integrated, and pinouts
to program external chips. This should work with any evaluation board from
@@ -86,7 +133,7 @@ printed on the circuit board. The pin-outs is shown on the circuit board
(follow the thin white line from J1 to the white box with STM32_SWD
written in it). From left to right, the pins are
- 3V3, CLK, GND, I/O, NRST and N/C
+ 3V3, CLK, GND, I/O, NRST and N/C
This matches the pin-out on the DISCO and NUCLEO boards we have tried.
@@ -94,34 +141,30 @@ First remove the pair of ST-LINK jumpers (CN4 on the DISCO, CN2 on the
NUCLEO). Then find the 6-pin SWD header on the left of the STM board (CN2
on the DISCO, CN4 on the NUCLEO), and connect them to the Alpha board:
- NUCLEO / DISCO CRYPTECH ALPHA
- -------------- --------------
-* 1 VDD_TARGET <-> 3V3
-* 2 SWCLK / T_JTCK <-> CLK
-* 3 GND <-> GND
-* 4 SWDIO / T_JTMS <-> IO
-* 5 NRST / T_NRST <-> NRST
-
-N/C (pin 6) means Not Connected.
+ NUCLEO / DISCO CRYPTECH ALPHA
+ -------------- --------------
+ * 1 VDD_TARGET <-> 3V3
+ * 2 SWCLK / T_JTCK <-> CLK
+ * 3 GND <-> GND
+ * 4 SWDIO / T_JTMS <-> IO
+ * 5 NRST / T_NRST <-> NRST
+ * 6 N/C
The Alpha board should be powered on before attempting to flash it.
-
Debugging the firmware
-======================
-
-This site shows several ways to use various debuggers to debug the
-firmware in an STM32:
+----------------------
- http://fun-tech.se/stm32/OpenOCD/gdb.php
+[This site](http://fun-tech.se/stm32/OpenOCD/gdb.php) shows several ways
+to use various debuggers to debug the firmware in an STM32.
There is a shell script called 'bin/debug' that starts an OpenOCD server
and GDB. Example:
- $ ./bin/debug projects/board-test/led-test
+ $ ./bin/debug projects/hsm/hsm
-Once in GDB, issue "monitor reset halt" to reset the STM32 before debugging.
+Once in GDB, issue `monitor reset halt` to reset the STM32 before debugging.
Remember that the first code to run will be the bootloader, but if you do
-e.g. "break main" and "continue" you will end up in led-test main() after
-the bootloader has jumped there.
+e.g. `break main` and `continue` you will end up in main() after the
+bootloader has jumped there.
More information about the Commits
mailing list