To retain the default behaviour from Bellatrix, we introduce a simple
default app. If used on flash app slot 0 we get the same behaviour as
in Bellatrix, that is, waiting for an app from the client.
Since we want to keep the user of the timer to the device apps, remove
the use of the timer for implementing a delay when writing to flash.
Let's try without any delay what so ever, just busylooping the query
to the chip.
- Set LED color to white when firmware has initialized
- Set LED color to black when changing state to loading
- Set LED color to blue when starting testloadapp
- Update mgmt app allowed digest since testloadapp changed
Instead of using 16 byte BLAKE2s with a dummy key, use plain vanilla
unkeyed 32 byte BLAKE2s for partition checksum.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
- Rename functions, defines, et c to indicate that it's a checksum
over the partition, not necessarily a cryptographic hash digest even
though we use a version of BLAKE2s.
- Add comments describing where the checksum is stored and what it is
used for.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
When we pass pointers in system calls these pointers should point to
app RAM, not any other parts of the memory map, and especially not to
memory like FW_RAM that is only available in in a higher privilege
mode.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Limit flash offsets passed to syscalls. Be sure to check the limits
before doing any form of calculation with the passed values.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
The symbol is only used for the check targets (with clangd and splint)
and doesn't include all the source files in the firmware. Let's just
use globbing instead.
- Add per app flash storage
- Adds four data areas. An app can allocate an area. Once allocated
the area is tied to the CDI of the app and can only be
read/written/deallocated by the same app.
- Add two pre loaded app slots to flash
- Load an app from the first slot at boot. The app digest must match a
specific digest specified in firmware.
- Optionally load an app from the second slot
- Add a resetinfo area in FW_RAM which is used to signal an app's intent
of resetting the system and, optionally, pass data to firmware or the
next app in a bootchain.
Co-authored-by: Jonas Thörnblad <jonas@tillitis.se>
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Co-authored-by: Daniel Jobson <jobson@tillitis.se>
The CH552 firmware has an added functionality to control the USB
controller dynamically, turning on and off endpoints with a small
protocol.
Since most of the documentation for the already lives in the ordinary
firmware README, add this documentation there, too.
- Make it possible to enable and disable endpoints on demand
- Add internal FPGA<->CH552 communication channel (IO_CH552)
- Reorder IO endpoint numbering
- Rename endpoint from TKEYCTRL to DEBUG and update related variables
- Rename endpoint from HID to FIDO and update related variables
This is an import of the fw-2 tag of tkey-libs.
We import the entire tkey-libs repo minus dot files into the
tillitis-key1 repo to make it very simple not to make mistakes
regarding which firmware tag depends on which tkey-libs tag,
especially considering locking down with NVCM.
Please see README for information about developing with another
tkey-libs or how to import future tkey-libs.
Since tkey-libs is now a part of the repo we also add tkey-libs to the
clean_fw target.
From now on the canonical home of the tk1_mem.h header file describing
the memory map of the TKey lives in tkey-libs:
https://github.com/tillitis/tkey-libs
Build firmware, testfw and testapp using tkey-libs:
https://github.com/tillitis/tkey-libs
In an effort not to have more or less identical code maintained in two
places, use tkey-libs when developing firmware, testfw and the
firmware testapp, too.
You can place the Git directory directly under hw/application_fpga
and then an ordinary make should work.
Or build with:
make LIBDIR=/path/to/tkey-libs
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
- Revise firmware implementation notes
- Document how to do fw syscalls
- Document how to trigger a syscall function in the firmware, how to
pass arguments, what the caller is responsible for and what is
returned.
- Describe hardware syscall implementation
- how the syscall interrupts are triggered,
- the hardware privilege escalation,
- the UDS protection.
Co-authored-by: Daniel Jobson <jobson@tillitis.se>
Co-authored-by: Michael Cardell Widerkrantz <mc@tillitis.se>
Introduce new syscall TK1_SYSCALL_GET_VIDPID to get Vendor ID and
Product ID from the protected Unique Device Identification number.
UDI is protected from device apps to protect the serial number, so
apps won't know the exact TKey they are running on other than the CDI.
It may, however, be important to know what *kind* of TKey they are
running on, so we want to expose the Vendor ID and Product ID.
- fpga: Allow UDI to be read when doing syscalls.
- Add the new syscall to firmware.
- Add test to testapp directly after negative test of reading UDI to
read out VID/PID through a syscall.
