Espressif/ESP32 S3/C6 support?

[faristonz]

Hi! I am studying the possibility of developing a Trussed platform implementation for ESP32-S3 (and perhaps in future for ESP32-C6, taking advantage of ESP-TEE/PMP-based isolation). Before I begin, I would like to clarify a few questions:

• Has anyone ever started a port for Espressif's chips, even if it was just a prototype or an abandoned project? I'd rather enjoy some existing work if there is, rather than start all over again.

• Is there any interest on the part of maintainers in, in the future, including a platform crite for ESP in the trussed-dev organization if it matures? Or does it make more sense that this type of project remains an independent repository?

• Based on previous port experience (such as nRF52 and LPC55), which interfaces or traits are usually more challenging to implement on a new platform? RNG, flash storage, USB HID or any other part?

My idea is to use the sp-hal (HAL bare-metal, no std and written entirely in Rust of the sp-rs project), instead of the sp-idf-hal, to keep the whole stack in Rust and avoid dependence on the C layer of ESP-IDF/FreeRTOS.

At the moment, this is primarily a personal learning project — I'm still starting in the field of applied encryption. Even so, I want to structure it as correctly as possible and, if it evolves to something really usable, I intend to contribute back to the ecosystem:3

[robin-nitrokey]

Cool that you are interested in using Trussed!

Has anyone ever started a port for Espressif's chips, even if it was just a prototype or an abandoned project?

I’m not aware of that.

Is there any interest on the part of maintainers in, in the future, including a platform crite for ESP in the trussed-dev organization if it matures? Or does it make more sense that this type of project remains an independent repository?

Currently, we don’t have any platform bindings in the trussed-dev organization. The only platform trait that trussed itself defines is UserInterface, and this is very specific to the combination of hardware that is used. Instead, these implementations are currently placed directly in the firmware repositories, e.g. nitrokey-3-firmware or solo2. For ESP32, I would start with a similar approach. If you then think that some parts of your firmware would make more sense as a separate crate in the trussed-dev organization, we can of course discuss that.

Based on previous port experience (such as nRF52 and LPC55), which interfaces or traits are usually more challenging to implement on a new platform? RNG, flash storage, USB HID or any other part?

The interfaces required by Trussed itself are pretty simple and should not be a big problem, at least for a first basic implementation. Probably the flash storage is the most complex part, but it should not be too bad. To have a complete firmware, you need additional components. Probably the USB device class is most complex one (if it’s not provided by the HAL).

[faristonz]

Thank you for the guidance! I want to be upfront: I'm still fairly new to Rust, so my first goal is really to learn — understanding the traits, the crate structure, and how storage/RNG/USB fit together — rather than committing to shipping a production-ready competitor to existing platforms right away. It'll probably take me a while to get to a working prototype, since I want to actually understand each piece before writing code, not just get something to compile. I'll treat this as a learning project for now, and will only frame it as something more serious once it's actually solid and tested. I really appreciate you taking the time to explain the architecture — it's genuinely helpful for someone approaching this for the first time. Thank you again :3