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


Bibi, Dani <dani.bibi@...>
 

What about the new set of System Control Registers added on M7 ?

__OM uint32_t ICIALLU; /*!< Offset: 0x250 ( /W) I-Cache Invalidate All to PoU */
uint32_t RESERVED6[1U];
__OM uint32_t ICIMVAU; /*!< Offset: 0x258 ( /W) I-Cache Invalidate by MVA to PoU */
__OM uint32_t DCIMVAC; /*!< Offset: 0x25C ( /W) D-Cache Invalidate by MVA to PoC */
__OM uint32_t DCISW; /*!< Offset: 0x260 ( /W) D-Cache Invalidate by Set-way */
__OM uint32_t DCCMVAU; /*!< Offset: 0x264 ( /W) D-Cache Clean by MVA to PoU */
__OM uint32_t DCCMVAC; /*!< Offset: 0x268 ( /W) D-Cache Clean by MVA to PoC */
__OM uint32_t DCCSW; /*!< Offset: 0x26C ( /W) D-Cache Clean by Set-way */
__OM uint32_t DCCIMVAC; /*!< Offset: 0x270 ( /W) D-Cache Clean and Invalidate by MVA to PoC */
__OM uint32_t DCCISW; /*!< Offset: 0x274 ( /W) D-Cache Clean and Invalidate by Set-way */
uint32_t RESERVED7[6U];
__IOM uint32_t ITCMCR; /*!< Offset: 0x290 (R/W) Instruction Tightly-Coupled Memory Control Register */
__IOM uint32_t DTCMCR; /*!< Offset: 0x294 (R/W) Data Tightly-Coupled Memory Control Registers */
__IOM uint32_t AHBPCR; /*!< Offset: 0x298 (R/W) AHBP Control Register */
__IOM uint32_t CACR; /*!< Offset: 0x29C (R/W) L1 Cache Control Register */
__IOM uint32_t AHBSCR; /*!< Offset: 0x2A0 (R/W) AHB Slave Control Register */
uint32_t RESERVED8[1U];
__IOM uint32_t ABFSR; /*!< Offset: 0x2A8 (R/W) Auxiliary Bus Fault Status Register */


Will they be wrapped up as part of the scs.h file ?

-----Original Message-----
From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
Sent: Wednesday, September 21, 2016 20:22
To: Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] 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:

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 https://jira.zephyrproject.org/browse/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:

https://gerrit.zephyrproject.org/r/#/c/4887/

- k
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Join devel@lists.zephyrproject.org to automatically receive all group messages.