1 Reply by brett

(1 replies, posted in wolfBoot)

Hi there,

Thanks for your interest in wolfBoot on AURIX!


What is the reason behind it ? Why not 0xA000_0000 ?

This is due to compatibility with one of the demo examples for wolfHSM on the AURIX platform. If you are just using wolfBoot without wolfHSM, then you can feel free to modify how wolfBoot utilizes the address space however you wish, as long as you also update the appropriate wolfBoot configuration preprocessor macros accordingly (ARCH_FLASH_OFFSET, WOLFBOOT_PARTITION_BOOT_ADDRESS, WOLFBOOT_PARTITION_UPDATE_ADDRESS, etc.). Note that this is done for the fixed demo project addresses by the AURIX helper script (tools/scripts/tc3xx/wbaurixtool.sh) when invoked with the "target" sub-command.

- For more information on wolfHSM see: https://www.wolfssl.com/products/wolfhsm/
- For more information on how wolfBoot integrates with wolfHSM, see: https://github.com/wolfSSL/wolfBoot/blo … wolfHSM.md and the wolfHSM integration section of the README you are referencing.
- Further information about the HSM subsystem on AURIX is restricted by Infineon NDA. Please reach out to your Infineon sales representative.

It seems that to edit the UCB STAD address I need a licence for winIDEA that I do not own and I dont know how to get it

You don't need winIDEA specifically to edit the UCBs, you just need to be able to program those flash sectors. This can be done using the Infineon provided memtool and the onboard "mini wiggler DAP", an external programmer like a Lauterbach device, or even from source code running on the device.

Note that the wolfBoot documentation does assume a general understanding of how the AURIX platform works, including how to program and configure the device. The AURIX platform is quite complex and the UCBs are a fundamental aspect of the system configuration, so I would urge you to consult the reference manual for the device to learn more. I would also recommend reach out to your Infineon sales or support contact for more information and training material.

Best,
Brett

Go to forum: wolfBoot

2 Reply by brett

(2 replies, posted in wolfCrypt)

Hi jlewis,

Thanks for reaching out.

The core wolfHSM code does not rely on dynamic memory allocation, so the only thing that would need dynamic allocation would be wolfSSL/wolfCrypt (if configured as such). Some wolfHSM tests, simulated transports, or port-specific code for POSIX targets may use dynamic allocation, but this can be excluded by the end user.

It says:
"You can configure wolfSSL with --enable-staticmemory or by defining the WOLFSSL_STATIC_MEMORY macro. However, this feature is limited to basic TLS connections and currently is not supported in wolfCrypt."
And I've seen elsewhere that wolfCrypt is needed for wolfHSM.

Apologies, that FAQ is slightly outdated - there are wolfCrypt APIs that support static memory, specifically those that take a HEAP_HINT pointer. If you are using those APIs then you can guarantee everything is allocated statically. If APIs are used that don't support it when building with WOLFSSL_STATIC_MEMORY, then those calls will fail.

Also, do I need wolfHSM in order to run wolfSSL on an HSM?  Or is it just helpful?

You can absolutely run just wolfSSL or wolfCrypt in your custom HSM application, but wolfHSM provides built-in functionality that will save you lots of time. We saw many customers spending considerable effort building custom HSM solutions with wolfSSL/wolfCrypt, which is why we developed a complete solution in wolfHSM that will work out-of-the-box.

Best,
Brett

Go to forum: wolfCrypt