Skip to content

AES accelerator support for STM32U5xx#4859

Open
theonlytruealex wants to merge 111 commits into
tock:masterfrom
OxidosAutomotive:board_nucleo_u545re_q_aes
Open

AES accelerator support for STM32U5xx#4859
theonlytruealex wants to merge 111 commits into
tock:masterfrom
OxidosAutomotive:board_nucleo_u545re_q_aes

Conversation

@theonlytruealex

Copy link
Copy Markdown

Pull Request Overview

Depends on OxidosAutomotive:board_nucleo_u545re_q

This pull request adds support for the AES driver accelerator for the stm32u5xx chip series and it generalises the AES hil. Where previously it was, necessarily AES128, it now supports 256 bit keys. The size of the key is now a const generic of the type AES: AES and AES. Modified older code accordingly.

  1. AES impementation for stm32u5xx
  • Created three files, mod.rs, gcm_ccm.rs and registers.rs, containing the logic for the AES accelerator for 128 and 256 length keys, for the following modes: ECB, CBC, CTR, GCM, GMAC, CCM
  • updated dma.rs and chip.rs with the necessary code to connect the peripheral to DMA. The addition is, essentially, a way to determine the data width for source and destination, and to determine the padding
  1. AES 256-bit support
  • modified the symmetric_encryption hil to allow for 256 bit keys, renamed constants accordingly
  • modified the aes driver to be independent of the key size
  • added three new testing files, aes256.rs (for ECB, CBC, CTR modes), aes_ccm_256.rs and aes_gcm_256.rs for 256 bit key testing. The vectors used in testing were taken from NIST
  • modified old code to use AES instead of AES128

Testing Strategy

  • Deployment: Deployment was performed using probe-rs and openocd.
  • AES functionallity was tested by using the afformentioned test files and the existing test files for aes128: ECB, CBC, CTR, GCM, CCM.

Documentation Updated

  • no updates are required.

Formatting

  • Ran make prepush.

AI Use

AI was used for suggestions to create cleaner code, debugging, and help in the creation of test file as the code for testing is uniform and doesn't require interaction with the peripheral, just sending and checking values. All generated code, register offsets, and memory maps were manually verified against the STM32U545 Reference Manual and validated on live hardware.

  • The PR description details my use of AI in the production of the
    code in this PR, if any, and I have manually checked and
    personally certify the entire contents of this PR.

@bradjc

bradjc commented May 27, 2026

Copy link
Copy Markdown
Contributor

Cool!

Obviously we need to get the board merged first, but two high-level comments:

  1. Can you pull out the HIL changes to their own PR? We need to review those independently.
  2. For the AES DMA, we need the DMA code to be in its own struct (something like nrf5x: Re-write AES driver to use DmaSlice, create nrf5x-unsafe #4856). The vision is we can separate the unsafe portions of code (e.g. DMA) into a small crate, and keep most of the safe part of the chip driver in its own crate.

@theonlytruealex

Copy link
Copy Markdown
Author

Thanks for the quick reply! I will put them in a separate PR tomorrow!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants