Removed GET_S_ and GET_NS definitions from max32657.h
Define both DMA instances
Added partition_max32657.h (from CMSIS) to handle SAU memory region partitioning for secure and non-secure code.
Updated linker, startup, and system files (SystemInit, SAU, Stack Sealing, Interrupt Tables)
Both DMA0 and DMA1 need to be defined, so we can't use the single MXC_DMA instance anymore.
DMA0 has a secure and non-secure mapping - accessible for secure and non-secure builds. However, DMA0 can not access secure memory or secure peripherals.
DMA1 only has a secure mapping - accessible for secure builds. But DMA1 can access both secure or non-secure memory and peripherals.
I'll have a separate PR for the remaining SYS register updates that I need to make.
Edit: Removing multiple linkers comment, just saw your changes @Jake-Carter. But I don't think we need multiple vector table definitions and startup_max32657.S startup code.
We can have one vector table defined that includes all secure and non-secure handlers, and we can dynamically switch between secure and non-secure vector tables during startup process using the SCB->VTOR vector table offset register. The SCB->VTOR register is banked into two parts, and the appropriate offset for secure and non-secure is used depending on the security context. We can also explicitly label the secure-only interrupts with the _S names, and include a build warning/error if the non-secure application references a secure handler.
The secure vector table is set up in SystemInit() called from Reset_Handler on startup. We'd have to figure out a mechanism for non-secure builds (non-secure reset handler) to set up the non-secure vector table (using SCB->VTOR again). This is at least my current understanding of how we might go about this for our bare metal MSDK.
There's a lot to think about - but given our schedule and priorities, we can focus on handling the secure mode for now so verification can begin. These changes are geared towards finishing the Secure build system changes that you've made, and to prep the non-secure builds for down the road.
Checklist Before Requesting Review
[ ] PR Title follows correct guidelines.
[ ] Description of changes and all other relevant information.
[ ] (Optional) Link any related GitHub issues using a keyword
[ ] (Optional) Provide info on any relevant functional testing/validation. For API changes or significant features, this is not optional.
Description
Some updates to the CMSIS for Verification.
GET_S_andGET_NSdefinitions from max32657.hBoth DMA0 and DMA1 need to be defined, so we can't use the single
MXC_DMAinstance anymore.I'll have a separate PR for the remaining SYS register updates that I need to make.
Edit: Removing multiple linkers comment, just saw your changes @Jake-Carter. But I don't think we need multiple vector table definitions and startup_max32657.S startup code.
We can have one vector table defined that includes all secure and non-secure handlers, and we can dynamically switch between secure and non-secure vector tables during startup process using the
SCB->VTORvector table offset register. TheSCB->VTORregister is banked into two parts, and the appropriate offset for secure and non-secure is used depending on the security context. We can also explicitly label the secure-only interrupts with the_Snames, and include a build warning/error if the non-secure application references a secure handler.The secure vector table is set up in
SystemInit()called from Reset_Handler on startup. We'd have to figure out a mechanism for non-secure builds (non-secure reset handler) to set up the non-secure vector table (usingSCB->VTORagain). This is at least my current understanding of how we might go about this for our bare metal MSDK.There's a lot to think about - but given our schedule and priorities, we can focus on handling the secure mode for now so verification can begin. These changes are geared towards finishing the Secure build system changes that you've made, and to prep the non-secure builds for down the road.
Checklist Before Requesting Review