MAX32666 bare-metal SHA accelerator

[mattia-moffa]

Description

Implements the SHA accelerator for MAX32666 as bare-metal, replacing the previous SDK-based one, which only supported one-shot hashing. This is needed to hash big firmwares in wolfBoot without taking up too much RAM.

Also has a fix for F#3076

Testing

Temporary test firmware: https://moffa.xyz/tmp/test_max32666.tar.gz

[Copilot]

Pull request overview

This PR replaces the previous MAX32666 SHA (TPU) integration that relied on SDK one-shot hashing with a bare-metal, incremental (Update/Final) SHA accelerator implementation, enabling hashing of large inputs without buffering the entire message in RAM (e.g., wolfBoot firmware images).

Changes:

• Reworked MAX3266x SHA support to use bare-metal register-level feeding of blocks and saved intermediate state, supporting incremental hashing.
• Simplified crypto callback SHA copy/free handling and removed the prior HASH_KEEP-based message accumulation approach.
• Updated Maxim port README to remove the previous “large hash” limitation note.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
wolfssl/wolfcrypt/port/maxim/max3266x.h	Removes HASH_KEEP/empty-digest helpers and adds bare-metal TPU SHA helper APIs/state sizing constants.
wolfcrypt/src/port/maxim/README.md	Removes outdated note about SDK one-shot SHA limiting large hashes.
wolfcrypt/src/port/maxim/max3266x.c	Implements incremental bare-metal TPU SHA (setup/feed/save/read) and rewires SHA callbacks + per-algorithm wc_Sha* APIs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4

• FLASH: .rodata.pkcs8KeyASN +4 B, .rodata.wolfSSL_ERR_reason_error_string.str1.1 -3 B, .text +448 B (+0.2%, 197,934 B / 262,144 B, total: 76% used)
• RAM: .bss +8 B (+1.0%, 836 B / 65,536 B, total: 1% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .rodata.pkcs8KeyASN +4 B, .text +832 B (+1.3%, 65,739 B / 262,144 B, total: 25% used)
• RAM: .bss +36 B (+5.6%, 680 B / 65,536 B, total: 1% used)

gcc-arm-cortex-m4-min-ecc

• FLASH: .rodata.pkcs8KeyASN +4 B, .text +384 B (+0.5%, 60,717 B / 262,144 B, total: 23% used)
• RAM: .bss +8 B (+1.2%, 676 B / 65,536 B, total: 1% used)

gcc-arm-cortex-m4-tls12

• FLASH: .rodata.pkcs8KeyASN +4 B, .text +320 B (+0.2%, 121,293 B / 262,144 B, total: 46% used)
• RAM: .bss +8 B (+1.0%, 816 B / 65,536 B, total: 1% used)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[night1rider]

Tested locally on hardware, no issues

[night1rider]

It does seem there is a performance regression.

• older code gave:

SHA                          6 MiB took 1.000 seconds,    6.247 MiB/s
SHA-224                      2 MiB took 0.319 seconds,    6.656 MiB/s
SHA-256                      7 MiB took 1.004 seconds,    6.663 MiB/s
SHA-384                      7 MiB took 1.004 seconds,    6.663 MiB/s
SHA-512                      7 MiB took 1.004 seconds,    6.663 MiB/s

• Newer Code Gives:

SHA                          5 MiB took 1.005 seconds,    4.543 MiB/s
SHA-224                      5 MiB took 1.005 seconds,    4.543 MiB/s
SHA-256                      5 MiB took 0.994 seconds,    4.543 MiB/s
SHA-384                      5 MiB took 1.005 seconds,    4.543 MiB/s
SHA-512                      5 MiB took 1.005 seconds,    4.543 MiB/s

I understand the older code buffered the entire message into memory, and then preformed the digest on the entire message.

Not sure it makes sense to have a option to return that older behavior as this refactor is more efficient overall than an accumulate and one shot.

[dgarske]

Let's have a build option to support the old caching option (off by default).

[mattia-moffa]

Jenkins retest this please

[mattia-moffa]

Jenkins retest this please

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[night1rider]

Works and new define returns older performance