- Remove all text about other software than firmware.
- Remove the Reset section.
- Include a diagram and detailed explanation about the state machine
in close vicinity.
- Describe the test firmware.
Co-authored-by: Joachim Strömbergson <joachim@assured.se>
- Change SPI clock from 16 CPU cyles/flank to one cycle/flank
- Remove separate flank length wait states in the FSM
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
- Changed FSM states to localparams
- Added localparam for SPI clock divisor
- Added internal signal for divisor reached
- Improved comments to clarify code
- Fixed some minor textual nits
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
For Verilator >5.019 `-Wno-GENUNNAMED` needs to be added to LINT_FLAGS
to silence warnings from the cell library.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
- Add more flags to catch the issues seen when linting the FPGA.
- Store issues in separate file for viewing. Remove with make clean.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
The RAM address and data scrambling API was called twice, once before filling
RAM with random values, and once after. Since moving to a significantly
better PRNG (xorwow) this is now deemed unnecessary. See issue #225.
This changes both FPGA and firmware hashes.
Modify the loop to zeroise the FW-RAM instead of the
RAM. RAM is filled with random data at the start of main().
Changes firmware and bitstream digests.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
- NOTE: This is an optional feature, not built by default. Not included
in the tk1 for sale at Tillitis shop.
- This makes it possible to interface the SPI flash onboard TKey.
- To include the SPI master in the build, use `make application_fpga.bin
YOSYS_FLAG=-DINCLUDE_SPI_MASTER`.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
xorwow provides significantly better random data, compared to previously
used function. Making it harder to predict what data RAM is filled with.
It adds a startup time of approx 80 ms, but can be compensated with
optimising other parts of the startup routine.
This changes both firmware and fpga hashes.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
Add simultion models of udi_rom and sb_rbga_drv
to lint-top target.
Add ignore statements in tb_sb_rgba_drv to silence
Verilator on parameters and signals not used in
the sim model.
Use RGBLEDEN in simulation model
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
- Gives a better overview of CI and the different checks, without going
into the logs too deeply.
- Cache: use a unique key for each run, and remove 'restore key' since it
could potentially retrieve the wrong bitstream. The stragegy should be
to fail if a cache is not present, not fetch a bitstream from a
different build.
Describe how the UDI and UDS are actually stored in the FPGA, how they
are accessed, and how they are initialled by the patch_uds_udi.py
script.
Co-authored-by: Joachim Strömbergson <joachim@assured.se>
The memset() responsible for the zeroisation of the secure_ctx under
the compute_cdi() function in FW's main.c, was optimised away by the
compiler. Instead of using memset(), secure_wipe() is introduced
which uses a volatile keyword to prevent the compiler to try to
optimise it. Secure_wipe() is now used on all locations handling
removal of sensitive data.
- Exclude splint from CI, so we make another target for it "splint",
which we might include in the "check" target later.
- Move the analysis runs earlier in CI so they, including indentation
checks, fail first.
- Include printouts of hashen in check-binary-hashes to easier see
what the digest are if it fails in CI.
By patching the UDS and UDI into an already built bitstream, it is now
not necessary to rebuild the entire build flow when changing the UDS
and the UDI. This lowers re-build times significantly.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
Change name of cpu_monitor to security_monitor and increase its
functionality to include RAM access violations. If addresses in RAM
but outside of physical RAM is accessed in any way the
security_monitor traps the CPU in the same way as it already did for
execution violations.
