Adding Support for SAMS70 SoC

[mcscholtz]

Zephyr already support the SAME70 & SAMV71 SOC's. The SAMS70 is just a cut-down version of the SAME70 so adding support is not that complicated.

We are developing a product based on the SAMS70 so I have a vested interest in getting it officially supported. We already have support in our own fork but would like to upstream the changes. I have attempted this in the past but did not have time or experience to see it through.

Changes Required

• Add the required asf files for the SAMS70 to the atmel_hal. See: Feature/sams70 asf support hal_atmel#37
• Add the pinctrl definitions and headers to atmel_hal [Already Supported]
• Add devicetree support. Refactor devicetree files so the S70 is the base and the E70 and V71 inherits from it.
• Add support for the SoC. Possibly refactor the E70 & V71 soc code since all three are essentially the same, but perhaps that should be done later.
• Add board support in the form of another variant of the sam_e70_xplained board

I am still pretty new to contributing so, got a couple of questions:

• Is adding the board enough to get it tested, or do I have to do something else in that regard?
• Do I create a separate PR for each item on the list or combine them into one PR? (Other than the atmel_hal which has to be seperate)
• Is anything missing from the list?

Thanks

[nandojve]

Hi @mcscholtz ,

Mostly everything is in place to add SAMS70. Your list seems to be everything that needs to move forward with this. The details will be discussed on each PR.

In this process newer drivers won't be accepted. It is more important enable a reference board to build the current drivers with ASF. I recommend add the board with minimal support and not enable all drivers at same time. You need only the serial working to make this. After that, you can enable each driver individually so we can check what could be necessary to include that driver in the tests or sample tests when appropriated. Usually project preference is only enable one board vs one driver since it took time in CI. We add drivers variants to build in CI to avoid get regressions and that may require more than one board or configuration, it depends and it is case by case.

The structure necessary to send this is composed of 2 parts:
P1:
1- make ASF available at hal_atmel on a PR (follow all details mentioned at repo readme)
P2:
1- update west pointing to the hal_atmel/PR as first commit in the series
2- introduce dts changes commit (refactor will be mandatory)
3- add soc commit (refactor for improvements should be made later)
4- add a reference board commit

[mcscholtz]

@nandojve Great thanks. I will get start on this.

[mcscholtz]

@nandojve

About the dts refactoring, could I change the dts files so that there are just 6 of them? like this:
samx7xx19.dtsi,
samx7xx19b.dtsi,
samx7xx20.dtsi,
samx7xx20b.dtsi,
samx7xx21.dtsi,
samx7xx21b.dtsi

Not all peripherals are supported by all devices but they are disabled by default. So unless you turn them on for an unsupported soc it should work well and there will be a lot less files. This will even support samv70 which is also not supported by zephyr currently.

Alternatively you can have something like:

For the SOC's:
sams70.dtsi
same70.dtsi
samv71.dtsi
sams70b.dtsi
same70b.dtsi
samv71b.dtsi

For the different packages:
samx7xj.dtsi
samx7xn.dtsi
samx7xq.dtsi

For the different memory configurations:
samx7x19.dtsi
samx7x20.dtsi
samx7x21.dtsi

Then you can combine them to make different configurations. This will prevent you from trying to enable for example use can1 on a same70j device since it is only supported by n or q devices. Or prevent you from trying to enable ethernet on sams70. However there will be an error regardless so are all of these combinations really worth the extra complexity over a generic one?

Let me know how you think I should proceed with this.

[nandojve]

Hi @mcscholtz ,

The main idea of these is create a tree. This means that it starts from the root device samx7x and grow to many directions. In the board only a leaf of this tree should be chose, ideally speaking.

The way I was thinking is:

1- Rename current same70 to samx7x. It is important do the rename to not lost history.
2- Create the new same7x file and move all non common nodes.
3- Update current files accordingly. We still need to keep the SoC model
4- No need to differentiate the package. The pinctrl binds the driver with pins and since the entry is not available that makes impossible to use the peripheral.
5- About the memories, this is more complex because customer can define cache etc and that reduces the amount of SRAM. You can have a generic definition to be included in a final dts file which represents the PN.
6- We still need to have the A/B variants.

At end, in the mainline we try reuse must we can and give some flexibility to customer pick what is important to create their own custom board. What we can not do is create gaps to have inconsistencies. Having the memory and B variation apart give flexibility to avoid the majority of the issues.

[henrikbrixandersen]

Once the following PRs are merged, the road should be paved for adding Atmel SAM S70/V70 support (requires zephyrproject-rtos/hal_atmel#37 and a similar addition for the V70):

• dts: arm: atmel: samx7x: move SAM E70/V71 DMA header to dt-bindings #83750
• drivers: pwm: sam: move SAM V71 register fixup from SoC to PWM driver #83756
• soc: atmel: samx7x: refactor SoC support for the Atmel SAM E70/V71 #83930