Re: Porting to ARM Cortex-M7 / Atmel SAM E70 support
On Sep 21, 2016, at 10:18 AM, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:There isn’t any need for the Jira to be accepted to submit code
2) The Jira issue I created is quite broad (I assumed however that it is not broad enough to be turned into an epic). Shall I create an additional task for each thing that needs to be done, e.g.: add Atmel SAM E70 header files, add support for ARM Cortex-M7 processor, add SAM E70 GPIO driver, add SAM E70 UART driver, etc.? Gerrit commits would then be assigned a Jira task number and not the broad Jira issue number.If you want to break up or add sub-tasks to the Jira that is fine, but I wouldn’t get too fine grain with it. I think something like:
* Add Cortex-M7 support
* Add SoC support
* Add Board support
Are there different ASFs per SoC or does Atmel release a single one for all their SoCs?
4) To support Cortex-M7 processor I need to add a new memory_map file. The existing one include/arch/arm/cortex_m/memory_map-m3-m4.h is specific to M3, M4 processors. However, the only differences between M3, M4 and M7 are in _PPB_EXT_* defines and they are never used. So my proposal is to remove all _PPB_EXT_* defines apart from _PPB_EXT_BASE_ADDR, _PPB_EXT_END_ADDR and re-use the file for M7. Very much the same defines could also be used by M0 processors. The only difference in that case is that M0, M0+ do not have ITM (Instrumentation Trace Macrocell) section and FPB section is called BPU. We could put all these defines directly in memory_map.h file and handle the minor differences via preprocessor #if defined() statements. Suggestions are welcomed.Let’s merge these files down and use some #ifdef’s in just memory_map.h. I’ve submitted a patch to start that process: