Initial PR for MAX32665 and MAX32666 TPU HW Support

[night1rider]

Description

This adds support for the TPU HW acceleration on the MAX32665 and MAX32666 from Analog Devices Code and Limitations where determined from the User Guide UG6971; Rev 3; 2/2022

Maxim SDK can be found here

Setup to run using these defines to run:

#define WOLFSSL_MAX3266X
#define WOLFSSL_MAX3266X_OLD - only needed if with old SDK
#define MAX3266X_RTC - only setup for new sdk and not old for baremetal benchmarking
#define WOLFSSL_SP_MATH_ALL

Testing

• [x] wolfCrypt Test and wolfCrypt Benchmark on Baremetal with the MAX32666FTHR with new SDK
• [x] wolfCrypt Test and wolfCrypt Benchmark on FreeRTOS with custom hardware with MAX32666 with old SDK

Checklist

HW Acceleration

• [x] TRNG
• [x] AES CBC 128, 192, 256
• [x] AES GCM 128, 192, 256 (hardware does not support this mode, using ECB)
• [x] SHA-256
• [x] RSA Math Acceleration
• [x] ECDSA Math Acceleration

Side Items

• [x] Jenkins Test Nightly using the MAX32666FTHR
• [x] Update wolfSSL Manual
• [x] Update Readme in wolfssl/wolfcrypt/port/maxim/

[night1rider]

Bug with MAA report here for visibility: https://github.com/analogdevicesinc/msdk/issues/1089 I will be looking to file a ticket on Analogs website as well.

[night1rider]

I do plan on fixing, max3266x.c and max3266x.h to use proper wolfSSL types. Have had some compile issues when using byte instead of char type

[night1rider]

Jenkins retest this please

[night1rider]

Jenkins retest this please

[douzzer]

retest this please

[night1rider]

Rebased the PR and added expanded mutexing options

[night1rider]

Added in Ability to use Callbacks with ARM ASM AES/SHA along with SHA Callbacks for the Hardware. Also potential fix for SHA Bug when using Callbacks.

ARM ASM Settings:

    #define WOLFSSL_ARMASM
    #define WOLFSSL_ARMASM_INLINE
    #define WOLFSSL_ARMASM_NO_HW_CRYPTO
    #define WOLFSSL_ARMASM_NO_NEON
    #define WOLFSSL_ARM_ARCH 7
    #define GCM_TABLE

[night1rider]

Jenkins retest this please