When starting, reset the USB controller to only enable the USB CDC
endpoint and the internal command channel. If the app resets firmware,
but had differend endpoints enabled, we want to go back to a known
state.
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.
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
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>
In order to be able to leave data for firmware signalling the
intention with a reset or to leave data for the next app in a chain of
apps, we introduce a part of FW_RAM that can be used to store this
data. In order to do this, we:
- Change size of ROM from 6 KB to 8 KB.
- Change size of FW_RAM, from 2 KB to 4 KB.
- Add RESETINFO memory partition inside FW_RAM.
- Add generation of map file.
- Change CFLAGS from using -O2 to using -Os.
- Update address ranges for valid access to ROM and FW_RAM.
- Move stack to be located before data+bss and the RESETINFO data
above them. This also means we introduce hardware stack overflow
protection through the Security Monitor.
- Revise firmware README to the new use of FW_RAM.
- The API changes name from `_SWITCH_APP` to `_SYSTEM_MODE_CTRL`.
- The registers and wires changes name to `system_mode_*`, instead of a
mix of `switch_app_*` and `fw_app_mode`.
- Remove the define `NOCONSOLE`, add define `QEMU_CONSOLE`
- Inverse the use of it, add the define to have QEMU debug output in fw.
- Add a make target `qemu_firmware.elf` which builds the firmware with
QEMU console enabled.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
- 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>
