When contrasted to official production hardware, this kit is less safe to use for non-development purposes.
Necessarily, different selections were made for key security properties of this developer kit vs. production hardware.
For example, when used as documented here, this kit purposefully leaves debug capabilities enabled, and does not apply write protections to boardloader flash memory.
This is so that developers may repeatedly develop, test, and debug all types of changes.
Production hardware irreversibly disables debug capabilities and Device Firmware Upgrade (DFU) mode, and protects key memory areas as part of reducing attack surface and increasing depth of defenses.
There may be other subtle, yet meaningful, weaknesses as well, depending on your usage and threat model.
This kit is not a perfect analog to the actual production hardware.
It uses a very similar, yet different MCU (STM32F429ZIT6 vs the Model T's STM32F427VIT6).
Certain features, for example the ability to reset the touch panel independently from the display, are not made available on the display module used by this kit.
There are other differences such as the display driver chip not being the same as the one used in production Model T devices (we support both driver chips in the code).
But, this kit is "close enough" and comprised of easily obtainable, relatively inexpensive, off-the-shelf components which allowed it to be developed alongside, and actually used for development of the production Model T.
USE THIS KIT AT YOUR OWN RISK
TREZOR Model T Open Source Hardware Reference Documentation
A nice thing about this kit is that it was used to openly develop the TREZOR Model T. Due to that there is already some detailed documentation about the kit available at the link above.
The purpose of this document is not to duplicate that documentation, but rather to detail how to put the kit together and use it.
Please reference the TREZOR Core hardware documentation for the latest information.
Here's what the completed kit looks like:
Wiring the Dev Board
First, be sure to set the jumpers as seen in Fig H3 and Fig H4.
Second, go through the pinout tables for the display and the touch panel and put wires on the dev board pins (aka MCU pins) that have a corresponding display module pin noted in the tables.
If you need help finding the dev board pins that map to the display module, see Fig H9 and Fig H10.
Next, connect the wires over to the correct display module pin. The display module pins are numbered 1 through 40 (see Fig H5).
All you need to do is connect the wires as stated in the pinout tables.
Finally, add wires to the microSD socket as shown in Fig H6 and use the silkscreen on the microSD socket as your guide to connect those wires over to the dev board pins as specified in the microSD socket pinout table.
When you've completed the wiring, you'll have something that looks like Fig H7. Plug-in the USB cables, and you're done (Fig H8).
TREZOR Model T Open Source Software Main Repository
This setup process comprises steps to install development and debugging tools on a temporary computer, then build and install a boardloader, bootloader, and firmware on the kit's MCU.
The following setup process was documented while running an Ubuntu 18.04 LTS Desktop (Bionic Beaver) Live CD as user ubuntu.
Your kit should look something like this after completing this tutorial (note that you can swipe the screen with your finger to change its orientation). Congratulations!
Q: Must I remove the SDRAM and TFT LCD + resistive touch panel that come attached to the STM32F429I-DISC1 dev board?
A: No, removing those parts is optional.
Q: How can I verify that the code I build will not lock the boardloader flash memory sectors and disable debug features?
A: By default, the PRODUCTION variable is set to 0. Unless you set it to 1, the build will output binaries that will not lock your boardloader flash memory and disable debugging functions.
For more information, search the code repo for PRODUCTION, and/or see the function flash_set_option_bytes.
Q: How do I use OpenOCD to connect under reset to the dev board?
A: openocd -f board/stm32f429disc1.cfg -c "reset_config connect_assert_srst"
For example, to connect under reset and prevent any code running from power on, perform this procedure:
Unplug the dev board
Press and hold the reset button on the dev board
Plug the dev board's USB cables into the host computer's USB ports
For more info on compiling and using the latest version of OpenOCD or upgrading the ST-LINK USB debug adapter firmware, see TREZOR One Dev Kits
Bonus Developer Information
The awesome folks at SatoshiLabs were nice enough to provide me with some prototype development boards as the Model T was being developed.
This helped greatly with development because I could then code and test with the actual MCU and peripherals that were going to be used.
They even sent me a prototype body which is in the photos below.
These photos are included as extra bonus developer information because sometimes it is interesting and/or instructive to see the artifacts that are made and used throughout the development cycle of a product.
As an external contributor, I spent a lot of time developing with the dev kit documented by this tutorial, and then switched to the prototype boards for fine tuning and testing.
The ST-LINK debugger that is on the dev board can be used to debug an external application (e.g.- the prototype board).
To do this, remove/disconnect the dev board's jumpers on CN4 and wire the prototype board to the dev board's SWD pins on CN2.
Here is the pinout:
Prototype Board SWD Pin
Debugger SWD Pin
SWD Clock (SWCLK)
SWD I/O (SWDIO)
One reason to do this is to be able to connect and debug under reset. The other pictured USB debug adapter does not support connecting under reset.
Below are some photos of the prototype board wired to the dev board debugger.