Re: Porting to ARM Cortex-M7 / Atmel SAM E70 support

Kumar Gala

On Sep 21, 2016, at 10:18 AM, Piotr Mienkowski <Piotr.Mienkowski(a)> wrote:

I would like to add support for Atmel SAM E70 SoC (Cortex-M7) and keep this thread to discuss all related issues.

A few questions that I have at the moment:

1) I created a relevant Jira issue ZEP-759 However, after reading "Collaboration Guidelines" wiki section I am still not sure if I'm allowed to start submitting commits to Gerrit or I should rather wait until someone officially accepts the Jira issue and assigns it to me?
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.

As discussed in "Porting to Cortex-M0+" thread to add support for Atmel SoCs we would preferably use original Atmel header files provided as part of their ASF (Atmel Software Framework) library. At the moment we are waiting for Atmel to hopefully provide us with header files containing a Zephyr compatible license. As it was suggested in "Porting to Cortex-M0+" thread, I will submit code which adds support for Atmel SAM E70 SoC (and depends on ASF) to Gerrit so it can be reviewed. The commits could be merged later once the license issue is sorted out. Before I can proceed there are still a few things which needs to be decided.
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

3) What should be the location of Atmel header files provided as part of ASF library? Maureen Helm, the ARM maintainer, proposed ext/hal/asf. I would like to suggest ext/hal/atmel on the basis that vendor library names are often cryptic and companies tend to change these names every several years. Within ext/hal/atmel each subfolder would have the name of a SoC family, the same as in arch/arm/soc/atmel.
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:

- k

Join to automatically receive all group messages.