Porting to Cortex-M0+


Piotr Mienkowski <piotr.mienkowski@...>
 

Why don’t you submit the code for review to at least let us move that bit along while we
figure out the issues with Atmel.
That's OK, I can do it.

Piotr


Kumar Gala
 

On Sep 20, 2016, at 3:28 AM, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

Hi Niheer,

I have taken the action from Maureen to find out more information from Atmel.
Thanks for taking care about the issue. I understand that Atmel still hasn't reached out to you. Is TSC going to consider accepting existing license from Atmel? Shall we wait a bit longer? Is there some deadline?

I would like to add support for Atmel SAM E70 chipset to Zephyr 1.6 release. I have most of the code ready but submitting it to Gerrit, feedback, fixes will probably take some time so the earlier I can start the better.

Cheers,
Piotr
Why don’t you submit the code for review to at least let us move that bit along while we figure out the issues with Atmel.

- k


Piotr Mienkowski <piotr.mienkowski@...>
 

Hi Niheer,

I have taken the action from Maureen to find out more information from Atmel.
Thanks for taking care about the issue. I understand that Atmel still hasn't reached out to you. Is TSC going to consider accepting existing license from Atmel? Shall we wait a bit longer? Is there some deadline?

I would like to add support for Atmel SAM E70 chipset to Zephyr 1.6 release. I have most of the code ready but submitting it to Gerrit, feedback, fixes will probably take some time so the earlier I can start the better.

Cheers,
Piotr


Patel, Niheer <Niheer.Patel@...>
 

Hi Piotr,


On Sep 15, 2016, at 7:06 AM, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

I brought this to the TSC yesterday, and the decision was to first ask Atmel if they can
change to a standard license already approved by the Zephyr governing board.
Another member of the TSC will follow up with Atmel.
Hi Maureen,

Do you have maybe any news about Atmel's header files license?
I have taken the action from Maureen to find out more information from Atmel. Unfortunately, I have not received any response from the folks I have reached out to. Please standby as I continue to follow up.

Regards,
Niheer


Cheers,
Piotr


Piotr Mienkowski <piotr.mienkowski@...>
 

I brought this to the TSC yesterday, and the decision was to first ask Atmel if they can
change to a standard license already approved by the Zephyr governing board.
Another member of the TSC will follow up with Atmel.
Hi Maureen,

Do you have maybe any news about Atmel's header files license?

Cheers,
Piotr


Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Maureen,

Another member of the TSC will follow up with Atmel.
Thanks, I will wait for the green light. My Atmel SAM E70 port works well in my local workarea, I have everything necessary for initial support apart from UART driver. There are still a few minor implementation details I'll have to discuss but I'll do it later in a separate thread when I know I am supposed to work on it.

I have one more question to the design flow I could not find a clear answer in the wiki to. As I have mentioned I would like to add support for Atmel SAM E70 chipset, I've already opened a Jira issue. I expect that now before doing the actual job and especially before trying to push anything to Gerrit I need to wait until the task is officially accepted and assigned to me, isn't it?

Cheers,
Piotr


Maureen Helm
 

Hi Piotr,

-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Wednesday, August 31, 2016 8:09 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Re: Porting to Cortex-M0+

Hi Maureen,

Thanks for all the explanations. I've created a Jira issue to add support for
Atmel SAM E70 family. If it's approved I can work on it.
https://jira.zephyrproject.org/browse/ZEP-759

by the NXP ksdk and Nordic mdk. As far as folder structure goes, I
think anything under ext/hal/asf (or whatever we end up calling it) has some
freedom to do what makes sense.
I am actually more in favor of giving subfolders company names (currently the
style is mixed). The main reason being the fact that the various names of SDKs
tend to be cryptic so user may have trouble finding what he is looking for. Also
companies, once every few years, tend to change these names so acronyms
such as ksdk, qmsi, asf may one day get outdated.

For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure
from the original
I am too very much for preserving the structure of the original SDK

IANAL either, but will check with someone at LF on this.
You've mentioned in the post below that Zephyr TSC has to ask the governing
board to approve the ASF license. What should we do to trigger this?
I brought this to the TSC yesterday, and the decision was to first ask Atmel if they can change to a standard license already approved by the Zephyr governing board. Another member of the TSC will follow up with Atmel.


Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi Maureen,

Thanks for all the explanations. I've created a Jira issue to add support for Atmel SAM E70 family. If it's approved I can work on it.
https://jira.zephyrproject.org/browse/ZEP-759

by the NXP ksdk and Nordic mdk. As far as folder structure goes, I think anything under
ext/hal/asf (or whatever we end up calling it) has some freedom to do what makes sense.
I am actually more in favor of giving subfolders company names (currently the style is mixed). The main reason being the fact that the various names of SDKs tend to be cryptic so user may have trouble finding what he is looking for. Also companies, once every few years, tend to change these names so acronyms such as ksdk, qmsi, asf may one day get outdated.

For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure from the original
I am too very much for preserving the structure of the original SDK

IANAL either, but will check with someone at LF on this.
You've mentioned in the post below that Zephyr TSC has to ask the governing board to approve the ASF license. What should we do to trigger this?


Euan Mutch <euan.mutch@...>
 

Thanks Vinayak its working now

On Wed, Aug 31, 2016 at 10:46 AM, Vinayak Kariappa <
vinayak.kariappa(a)gmail.com> wrote:

Hi Euan,

This how I build on the branch Ricardo gave me, if its of any help.

make -C samples/bluetooth/peripheral CROSS_COMPILE=arm-none-eabi-
LIB_INCLUDE_DIR="-L /usr/lib/gcc/arm-none-eabi/4.8.2/armv6-m -lgcc"
ZEPHYR_BASE=~/workspace/zephyr/ BOARD=nrf51_blenano

Regards,
Vinayak


On Tue, Aug 30, 2016 at 6:27 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi,

I am now having some problems getting the micro kernel to link. It
currently fails with undefined references to __gnu_thumb1_case_uqi and
__ffssi2 which should be in libgcc.a, so I added -lgcc to LDFLAGS but that
didn't help.

Any ideas?

Thanks again,
Euan

On Mon, Aug 29, 2016 at 10:11 PM, Euan Mutch <euan.mutch(a)gmail.com>
wrote:

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Vinayak Kariappa <vinayak.kariappa@...>
 

Hi Euan,

This how I build on the branch Ricardo gave me, if its of any help.

make -C samples/bluetooth/peripheral CROSS_COMPILE=arm-none-eabi-
LIB_INCLUDE_DIR="-L /usr/lib/gcc/arm-none-eabi/4.8.2/armv6-m -lgcc"
ZEPHYR_BASE=~/workspace/zephyr/ BOARD=nrf51_blenano

Regards,
Vinayak

On Tue, Aug 30, 2016 at 6:27 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi,

I am now having some problems getting the micro kernel to link. It
currently fails with undefined references to __gnu_thumb1_case_uqi and
__ffssi2 which should be in libgcc.a, so I added -lgcc to LDFLAGS but that
didn't help.

Any ideas?

Thanks again,
Euan

On Mon, Aug 29, 2016 at 10:11 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Euan Mutch <euan.mutch@...>
 

Hi,

I am now having some problems getting the micro kernel to link. It
currently fails with undefined references to __gnu_thumb1_case_uqi and
__ffssi2 which should be in libgcc.a, so I added -lgcc to LDFLAGS but that
didn't help.

Any ideas?

Thanks again,
Euan

On Mon, Aug 29, 2016 at 10:11 PM, Euan Mutch <euan.mutch(a)gmail.com> wrote:

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Euan Mutch <euan.mutch@...>
 

Hi Maureen/Iván,

I managed to get it working now and my led is flashing :)

Thanks!


Maureen Helm
 

Hi Euan,

-----Original Message-----
From: Euan Mutch [mailto:euan.mutch(a)gmail.com]
Sent: Monday, August 29, 2016 5:56 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Re: Porting to Cortex-M0+

So the best way forward is to add the device headers to /hal/asf and change
sam3 to the family/series hierarchy?
Yes. I checked with the LF, and they recommended that the Zephyr TSC asks the governing board to approve the ASF license.

There are some really weird things going on with the Atmel drivers, especially
some of the really horrible macros they use. Took me a full day just to decipher
the clock init code.

Quick (newbie) question:
I have currently added just the M0+ specific bits of asf, but I can't get it to link
properly and so get "undefined reference to 'system_init'" when I try to use it.
It is really hard to figure out how to do certain things in zephyr such as adding
external stuff... Although that could just be because I have never worked on
something like this before.
I don't understand how the other HALs work since they also have drivers in
them, I have exactly the same setup as those. Which seems to just be including
the files and never building anything?
Don't forget to look at the Kbuild files, such as ext/hal/qmsi/Kbuild. I've also go this patch in the works for Kinetis SDK:
https://gerrit.zephyrproject.org/r/#/c/4192/3


Iván Briano <ivan.briano at intel.com...>
 

On Mon, 29 Aug 2016 10:56:06 +0000, Euan Mutch wrote:
So the best way forward is to add the device headers to /hal/asf and change sam3 to the family/series hierarchy?

There are some really weird things going on with the Atmel drivers, especially some of the really horrible macros they use. Took me a full day just to decipher the clock init code.

Quick (newbie) question:
I have currently added just the M0+ specific bits of asf, but I can't get it to link properly and so get "undefined reference to 'system_init'" when I try to use it. It is really hard to figure out how to do certain things in zephyr such as adding external stuff... Although that could just be because I have never worked on something like this before.
I don't understand how the other HALs work since they also have drivers in them, I have exactly the same setup as those. Which seems to just be including the files and never building anything?
If the HAL is only a bunch of headers, then you don't need to build
anything. But if you look at the QMSI one, you'll see it's building a
lot of stuff, so it may serve as an example.


Euan Mutch <euan.mutch@...>
 

So the best way forward is to add the device headers to /hal/asf and change sam3 to the family/series hierarchy?

There are some really weird things going on with the Atmel drivers, especially some of the really horrible macros they use. Took me a full day just to decipher the clock init code.

Quick (newbie) question:
I have currently added just the M0+ specific bits of asf, but I can't get it to link properly and so get "undefined reference to 'system_init'" when I try to use it. It is really hard to figure out how to do certain things in zephyr such as adding external stuff... Although that could just be because I have never worked on something like this before.
I don't understand how the other HALs work since they also have drivers in them, I have exactly the same setup as those. Which seems to just be including the files and never building anything?


Maureen Helm
 

-----Original Message-----
From: Piotr Mienkowski [mailto:Piotr.Mienkowski(a)schmid-telecom.ch]
Sent: Thursday, August 25, 2016 4:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Porting to Cortex-M0+

Hi,

I have the same problem. I would like to add support for Atmel SAM E70 chip
(Cortex-M7) and was thinking that using the header files provided by Atmel as
part of their ASF would make the job much, much easier.

Euan, did you already add files to ext/hal/ folder? Have you talked to Maureen
Helm, the ARM architecture maintainer? Should we agree on folder structure
so support for future Atmel chips can be easily added?
I agree it would make sense to add the device header files from Atmel to ext/hal. We already have the CMSIS Core header files from ARM in ext/hal/cmsis, which are being used by the NXP ksdk and Nordic mdk. As far as folder structure goes, I think anything under ext/hal/asf (or whatever we end up calling it) has some freedom to do what makes sense. For ext/hal/cmsis and ext/hal/ksdk, I tried to preserve the structure from the original source as much as possible. The folder structure under arch/arm/soc is intended to be more standardized, though you may have noticed that some SoCs have a family/series hierarchy (nxp_kinetis) and some don't (atmel_sam3). To add SAM E70, we'll need to first convert the existing atmel_sam3 to the family/series hierarchy. Something like this:

arch/arm/soc/atmel_smart/sam3
arch/arm/soc/atmel_smart/same7x


My thoughts:
I think we should only add header files that define register access and do not
add any device drivers. While header files are valuable the Atmel
implementation of device drivers looks low quality, at least the SAM E70
package. The way API is written is not directly useful for any serious
development, neither it follows CMSIS standard. While some drivers look good,
some are incomplete and some are buggy. We would need to fix them and
cooperate with Atmel to push changes upstream. I reckon using third party
source code which is not maintained in open source model is not a viable long
term solution. Not mentioning the fact that device drivers will have to be tightly
integrated with Zephyr kernel. I believe it's easier to write our own drivers
from scratch. Anyway, that's only my opinion.
I can't comment on the state of the Atmel drivers, but at least for NXP we do a lot of testing on the ksdk drivers and they are actively maintained. Intel is doing a similar thing with their qmsi drivers.


The text of SAM Software Package License included in the source code (and
header files) looks actually very permissive but IANAL, also the ext/hal/ folder
has already a selection of proprietary code with similar licenses. In any case we
should probably get an official green light from someone.
IANAL either, but will check with someone at LF on this.


Cheers,
Piotr


Piotr Mienkowski <Piotr.Mienkowski@...>
 

Hi,

I have the same problem. I would like to add support for Atmel SAM E70 chip (Cortex-M7) and was thinking that using the header files provided by Atmel as part of their ASF would make the job much, much easier.

Euan, did you already add files to ext/hal/ folder? Have you talked to Maureen Helm, the ARM architecture maintainer? Should we agree on folder structure so support for future Atmel chips can be easily added?

My thoughts:
I think we should only add header files that define register access and do not add any device drivers. While header files are valuable the Atmel implementation of device drivers looks low quality, at least the SAM E70 package. The way API is written is not directly useful for any serious development, neither it follows CMSIS standard. While some drivers look good, some are incomplete and some are buggy. We would need to fix them and cooperate with Atmel to push changes upstream. I reckon using third party source code which is not maintained in open source model is not a viable long term solution. Not mentioning the fact that device drivers will have to be tightly integrated with Zephyr kernel. I believe it's easier to write our own drivers from scratch. Anyway, that's only my opinion.

The text of SAM Software Package License included in the source code (and header files) looks actually very permissive but IANAL, also the ext/hal/ folder has already a selection of proprietary code with similar licenses. In any case we should probably get an official green light from someone.

Cheers,
Piotr


Nashif, Anas
 

On 23 Aug 2016, at 10:39, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> wrote:

Hi,

Euan Mutch <euan.mutch(a)gmail.com> writes:

I have started writing the drivers for peripherals on the M0+ now, but
I am getting the feeling that I should probably just add Atmel ASF to
the \ext\hal\ folder rather than basically rewriting them. I am just
wondering why this was not done already for the Arduino Due which also
has an Atmel SOC?
Licensing issues perhaps[1]?
Actually more because nobody did it until now, so you are welcome to do this.



"Disclaimer and Credits

...

4. This software may only be redistributed and used in connection with
an Atmel microcontroller product."

I do not think this will conflict with the intent of how to use it in Zephyr. After all the code will be used with Atmel MCUs only…

Anas


[1] http://www.atmel.com/Images/asf-releasenotes-3.32.0.pdf page 34


Cheers,


Vinicius Costa Gomes
 

Hi,

Euan Mutch <euan.mutch(a)gmail.com> writes:

I have started writing the drivers for peripherals on the M0+ now, but
I am getting the feeling that I should probably just add Atmel ASF to
the \ext\hal\ folder rather than basically rewriting them. I am just
wondering why this was not done already for the Arduino Due which also
has an Atmel SOC?
Licensing issues perhaps[1]?

"Disclaimer and Credits

...

4. This software may only be redistributed and used in connection with
an Atmel microcontroller product."


[1] http://www.atmel.com/Images/asf-releasenotes-3.32.0.pdf page 34


Cheers,
--
Vinicius


Euan Mutch <euan.mutch@...>
 

I have started writing the drivers for peripherals on the M0+ now, but I am getting the feeling that I should probably just add Atmel ASF to the \ext\hal\ folder rather than basically rewriting them. I am just wondering why this was not done already for the Arduino Due which also has an Atmel SOC?