subject:"\[PATCH v6 00\/10\] New GPIO, ADC API and STM32F4 BSP implementation"

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Chris Johns

On 22/9/2022 11:44 pm, Joel Sherrill wrote:
> 
> 
> On Thu, Sep 22, 2022 at 4:44 AM Karel Gardas  wrote:
> 
> On 9/22/22 10:41, Sebastian Huber wrote:
> > On 22/09/2022 10:30, Karel Gardas wrote:
> >> On 9/22/22 00:00, Gedare Bloom wrote:
> >>> On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill  > wrote:
> 
> 
> 
>  On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
>   wrote:
> >
> >
> > The problem is that we still need to discuss licensing here. 
> Randomly
> > checked files from the HAL patch contains this as a license:
> >
> >     * This software is licensed under terms that can be found in the
> > LICENSE file
> >     * in the root directory of this software component.
> >     * If no LICENSE file comes with this software, it is provided
> > AS-IS.
> >
> > and in the past Sebastian suggested to clear the message hence I 
> used
> > something used here:
> >
> >
> 
> https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
>  
> 
> >
> 
> 
>  I'm OK with an explanation like that but I hate to see that much
>  duplicated
>  over and over. Would it be possible to put the lengthy explanation
>  in one
>  place with the HAL addition and then have a short explanation in
>  each file:
> 
>  /*
>    * RTEMS committer clarification comment on license above:
>    *
>    * This file comes from STM32CubeH7 project from its Projects
>  subdirectory. See
>    * RTEMS_PATH_TBD for details on the license for this file.
>    */
> 
>  With RTEMS_PATH_TBD probably easy to identify because it would
>  be something like bsps/arm/shared/STMHM7 and then the single
>  file with a name that is like LICENSE_STM32CubeH7.txt so it isn't 
> just
>  LICENSE.txt which is easy to confuse.
> 
>  Just a practical matter of avoiding duplication. We have precedence
>  for this over the project history.
> 
>  This is just record keeping to maintain proper attribution, origin 
> URL,
>  licensing, etc. without burden of duplication. They obviously
>  thought it
>  was a duplication burden. We should use their trick and just point to
>  our location for that file. :)
> 
>  It's not like we are trying to nick the code and not give credit. We
>  are
>  likely in the small minority even doing this much. My expectations 
> are
>  pretty low for most people/projects.
> 
> >>>
> >>> We had a discussion about this topic over on Discord. The general
> >>> resolution there was that we should consider importing the HAL code
> >>> as-is, and then layer on another patch to inject SPDX tags for the
> >>> appropriate license into each imported file. Then the committer (In
> >>> this case, Duk) should write up an ORIGIN kind of file to put into the
> >>> directory above the HAL to explain the history of the code there,
> >>> where it came from (URLs), how the licenses were sorted, and any other
> >>> information that helps understand the source of that code. This
> >>> balances the effort needed to update the HAL code later, since if it
> >>> changes only minimally, we can just re-import it, re-inject the SPDX
> >>> tags, and update the ORIGIN file. In this case, I'd say add something
> >>> like ORIGIN.HAL in the stm32f4 directory to capture the documentation
> >>> about the import process for the HAL.
> >>
> >> Sounds good! Last remark and question. What about Apache 2.0 license
> >> which covers at least some of the files from STM and which we use in
> >> "hal" subdirectory. Is everything settled and the project may use such
> >> files? In the past at least Sebastian and Chris were reserved and
> >> raised some questions about Apache 2.0 license details...
> >>
> >> Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
> >> great to have that sorted out in the same way here.
> >
> > I don't like the Apache 2.0 license due to this clause:
> >
> > "You must cause any modified files to carry prominent notices stating
> > that You changed the files; and"
> >
> 
> 
> With a need to use SPDX identitifer on top of every file the project may
> probably also do:
> 
> (1) add an option of 'This file was changed by RTEMS project.' clausule
> to top of the file probably below SPDX id for Apache 2.0 licensed files.
> 
> 
> +1 
> 
> 
> and
> 
> (2)

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Joel Sherrill

On Thu, Sep 22, 2022 at 4:44 AM Karel Gardas 
wrote:

> On 9/22/22 10:41, Sebastian Huber wrote:
> > On 22/09/2022 10:30, Karel Gardas wrote:
> >> On 9/22/22 00:00, Gedare Bloom wrote:
> >>> On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill  wrote:
> 
> 
> 
>  On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
>   wrote:
> >
> >
> > The problem is that we still need to discuss licensing here. Randomly
> > checked files from the HAL patch contains this as a license:
> >
> > * This software is licensed under terms that can be found in the
> > LICENSE file
> > * in the root directory of this software component.
> > * If no LICENSE file comes with this software, it is provided
> > AS-IS.
> >
> > and in the past Sebastian suggested to clear the message hence I used
> > something used here:
> >
> >
> https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
> >
> 
> 
>  I'm OK with an explanation like that but I hate to see that much
>  duplicated
>  over and over. Would it be possible to put the lengthy explanation
>  in one
>  place with the HAL addition and then have a short explanation in
>  each file:
> 
>  /*
>    * RTEMS committer clarification comment on license above:
>    *
>    * This file comes from STM32CubeH7 project from its Projects
>  subdirectory. See
>    * RTEMS_PATH_TBD for details on the license for this file.
>    */
> 
>  With RTEMS_PATH_TBD probably easy to identify because it would
>  be something like bsps/arm/shared/STMHM7 and then the single
>  file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
>  LICENSE.txt which is easy to confuse.
> 
>  Just a practical matter of avoiding duplication. We have precedence
>  for this over the project history.
> 
>  This is just record keeping to maintain proper attribution, origin
> URL,
>  licensing, etc. without burden of duplication. They obviously
>  thought it
>  was a duplication burden. We should use their trick and just point to
>  our location for that file. :)
> 
>  It's not like we are trying to nick the code and not give credit. We
>  are
>  likely in the small minority even doing this much. My expectations are
>  pretty low for most people/projects.
> 
> >>>
> >>> We had a discussion about this topic over on Discord. The general
> >>> resolution there was that we should consider importing the HAL code
> >>> as-is, and then layer on another patch to inject SPDX tags for the
> >>> appropriate license into each imported file. Then the committer (In
> >>> this case, Duk) should write up an ORIGIN kind of file to put into the
> >>> directory above the HAL to explain the history of the code there,
> >>> where it came from (URLs), how the licenses were sorted, and any other
> >>> information that helps understand the source of that code. This
> >>> balances the effort needed to update the HAL code later, since if it
> >>> changes only minimally, we can just re-import it, re-inject the SPDX
> >>> tags, and update the ORIGIN file. In this case, I'd say add something
> >>> like ORIGIN.HAL in the stm32f4 directory to capture the documentation
> >>> about the import process for the HAL.
> >>
> >> Sounds good! Last remark and question. What about Apache 2.0 license
> >> which covers at least some of the files from STM and which we use in
> >> "hal" subdirectory. Is everything settled and the project may use such
> >> files? In the past at least Sebastian and Chris were reserved and
> >> raised some questions about Apache 2.0 license details...
> >>
> >> Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
> >> great to have that sorted out in the same way here.
> >
> > I don't like the Apache 2.0 license due to this clause:
> >
> > "You must cause any modified files to carry prominent notices stating
> > that You changed the files; and"
> >
>
>
> With a need to use SPDX identitifer on top of every file the project may
> probably also do:
>
> (1) add an option of 'This file was changed by RTEMS project.' clausule
> to top of the file probably below SPDX id for Apache 2.0 licensed files.
>

+1

>
> and
>
> (2) implement git commit hook to check that every single file with
> Apache 2.0 SPDX contains (1).
>
> Would that fulfill requirements of Apache 2.0 license?
>

I think it would. Even adding the SPDX tag would technically modify the file
so adding the "changed by the RTEMS Project" and importing the base code
gives us tracking on changes.

>
> > This means that the reviewer of RTEMS Project contributions has to check
> > this for each Apache 2.0 file.
> >
> > We also have to check if imported Work as a NOTICE file, since then this
> > applies also:
> >
> > "If the Work includes a "NOTICE" text file as part of its distribution,

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Karel Gardas

On 9/22/22 10:41, Sebastian Huber wrote:

On 22/09/2022 10:30, Karel Gardas wrote:

On 9/22/22 00:00, Gedare Bloom wrote:

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
wrote:

The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:

* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file comes with this software, it is provided
AS-IS.

and in the past Sebastian suggested to clear the message hence I used
something used here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much
duplicated
over and over. Would it be possible to put the lengthy explanation
in one
place with the HAL addition and then have a short explanation in
each file:

/*
* RTEMS committer clarification comment on license above:
*
* This file comes from STM32CubeH7 project from its Projects
subdirectory. See

* RTEMS_PATH_TBD for details on the license for this file.
*/

With RTEMS_PATH_TBD probably easy to identify because it would
be something like bsps/arm/shared/STMHM7 and then the single
file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
LICENSE.txt which is easy to confuse.

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

This is just record keeping to maintain proper attribution, origin URL,
licensing, etc. without burden of duplication. They obviously
thought it

was a duplication burden. We should use their trick and just point to
our location for that file. :)

It's not like we are trying to nick the code and not give credit. We
are

likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

We had a discussion about this topic over on Discord. The general
resolution there was that we should consider importing the HAL code
as-is, and then layer on another patch to inject SPDX tags for the
appropriate license into each imported file. Then the committer (In
this case, Duk) should write up an ORIGIN kind of file to put into the
directory above the HAL to explain the history of the code there,
where it came from (URLs), how the licenses were sorted, and any other
information that helps understand the source of that code. This
balances the effort needed to update the HAL code later, since if it
changes only minimally, we can just re-import it, re-inject the SPDX
tags, and update the ORIGIN file. In this case, I'd say add something
like ORIGIN.HAL in the stm32f4 directory to capture the documentation
about the import process for the HAL.

Sounds good! Last remark and question. What about Apache 2.0 license
which covers at least some of the files from STM and which we use in
"hal" subdirectory. Is everything settled and the project may use such
files? In the past at least Sebastian and Chris were reserved and
raised some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
great to have that sorted out in the same way here.

I don't like the Apache 2.0 license due to this clause:

"You must cause any modified files to carry prominent notices stating
that You changed the files; and"

With a need to use SPDX identitifer on top of every file the project may
probably also do:

(1) add an option of 'This file was changed by RTEMS project.' clausule
to top of the file probably below SPDX id for Apache 2.0 licensed files.

and

(2) implement git commit hook to check that every single file with
Apache 2.0 SPDX contains (1).

Would that fulfill requirements of Apache 2.0 license?

This means that the reviewer of RTEMS Project contributions has to check
this for each Apache 2.0 file.

We also have to check if imported Work as a NOTICE file, since then this
applies also:

"If the Work includes a "NOTICE" text file as part of its distribution,
then any Derivative Works that You distribute must include a readable
copy of the attribution notices contained within such NOTICE file,
excluding those notices that do not pertain to any part of the
Derivative Works, in at least one of the following places: within a
NOTICE text file distributed as part of the Derivative Works; within the
Source form or documentation, if provided along with the Derivative
Works; or, within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents of the
NOTICE file are for informational purposes only and do not modify the
License. You may add Your own attribution notices within Derivative
Works that You distribute, alongside or as an addendum to the NOTICE
text from the Work, provided that such

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Sebastian Huber

On 22/09/2022 10:30, Karel Gardas wrote:

On 9/22/22 00:00, Gedare Bloom wrote:

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
wrote:

The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:

* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file comes with this software, it is provided
AS-IS.

and in the past Sebastian suggested to clear the message hence I used
something used here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much
duplicated
over and over. Would it be possible to put the lengthy explanation in
one
place with the HAL addition and then have a short explanation in each
file:

/*
* RTEMS committer clarification comment on license above:
*
* This file comes from STM32CubeH7 project from its Projects
subdirectory. See

* RTEMS_PATH_TBD for details on the license for this file.
*/

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

This is just record keeping to maintain proper attribution, origin URL,
licensing, etc. without burden of duplication. They obviously thought it
was a duplication burden. We should use their trick and just point to
our location for that file. :)

It's not like we are trying to nick the code and not give credit. We are
likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

Sounds good! Last remark and question. What about Apache 2.0 license
which covers at least some of the files from STM and which we use in
"hal" subdirectory. Is everything settled and the project may use such
files? In the past at least Sebastian and Chris were reserved and raised
some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
great to have that sorted out in the same way here.

I don't like the Apache 2.0 license due to this clause:

"You must cause any modified files to carry prominent notices stating
that You changed the files; and"

This means that the reviewer of RTEMS Project contributions has to check
this for each Apache 2.0 file.

We also have to check if imported Work as a NOTICE file, since then this
applies also:

This would be an extra requirement for RTMES users.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Karel Gardas

On 9/22/22 00:00, Gedare Bloom wrote:

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas wrote:

The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:

* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file comes with this software, it is provided AS-IS.

and in the past Sebastian suggested to clear the message hence I used
something used here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much duplicated
over and over. Would it be possible to put the lengthy explanation in one
place with the HAL addition and then have a short explanation in each file:

/*
* RTEMS committer clarification comment on license above:
*
* This file comes from STM32CubeH7 project from its Projects subdirectory. See
* RTEMS_PATH_TBD for details on the license for this file.
*/

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

It's not like we are trying to nick the code and not give credit. We are
likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

Sounds good! Last remark and question. What about Apache 2.0 license
which covers at least some of the files from STM and which we use in
"hal" subdirectory. Is everything settled and the project may use such
files? In the past at least Sebastian and Chris were reserved and raised
some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
great to have that sorted out in the same way here.

Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Gedare Bloom

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill  wrote:
>
>
>
> On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas  wrote:
>>
>>
>> The problem is that we still need to discuss licensing here. Randomly
>> checked files from the HAL patch contains this as a license:
>>
>>* This software is licensed under terms that can be found in the
>> LICENSE file
>>* in the root directory of this software component.
>>* If no LICENSE file comes with this software, it is provided AS-IS.
>>
>> and in the past Sebastian suggested to clear the message hence I used
>> something used here:
>>
>> https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
>
>
> I'm OK with an explanation like that but I hate to see that much duplicated
> over and over. Would it be possible to put the lengthy explanation in one
> place with the HAL addition and then have a short explanation in each file:
>
> /*
>  * RTEMS committer clarification comment on license above:
>  *
>  * This file comes from STM32CubeH7 project from its Projects subdirectory. 
> See
>  * RTEMS_PATH_TBD for details on the license for this file.
>  */
>
> With RTEMS_PATH_TBD probably easy to identify because it would
> be something like bsps/arm/shared/STMHM7 and then the single
> file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
> LICENSE.txt which is easy to confuse.
>
> Just a practical matter of avoiding duplication. We have precedence
> for this over the project history.
>
> This is just record keeping to maintain proper attribution, origin URL,
> licensing, etc. without burden of duplication. They obviously thought it
> was a duplication burden. We should use their trick and just point to
> our location for that file. :)
>
> It's not like we are trying to nick the code and not give credit. We are
> likely in the small minority even doing this much. My expectations are
> pretty low for most people/projects.
>

We had a discussion about this topic over on Discord. The general
resolution there was that we should consider importing the HAL code
as-is, and then layer on another patch to inject SPDX tags for the
appropriate license into each imported file. Then the committer (In
this case, Duk) should write up an ORIGIN kind of file to put into the
directory above the HAL to explain the history of the code there,
where it came from (URLs), how the licenses were sorted, and any other
information that helps understand the source of that code. This
balances the effort needed to update the HAL code later, since if it
changes only minimally, we can just re-import it, re-inject the SPDX
tags, and update the ORIGIN file. In this case, I'd say add something
like ORIGIN.HAL in the stm32f4 directory to capture the documentation
about the import process for the HAL.


>>
>>
>>
>> unfortunately whole F4 HAL would probably need such modification.
>
>
> And even a better reason to make a short note in each file and put the
> details in a single file in the HAL top directory.
>>
>>
>>
>> On the bright side, it looks like STM still holds on BSD-3 for their HAL
>> code for F4?
>>
>> https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md
>
>
> +1
>>
>>
>>
>> Would be great indeed.
>>
>> BTW: sorry, I'm really out of the loop on this still trying to catch up
>> with all the development in RTEMS over summer...
>
>
> Understood. Work is busy. RTEMS is busy. And with things getting back
> to normal, I've even been busy going to concerts and other outings that
> I missed. :)
>
+1

> --joel
>>
>>
>> Karel
>>
>>
>>
>> On 9/21/22 15:25, Joel Sherrill wrote:
>> > This patch set has been sitting for almost 7 weeks. I was going to commit
>> > it today but was asked to give one last the patch merge equivalent  of
>> > ""if anyone can show just cause why this patch and RTEMS cannot  be
>> > joined together, let them speak now or forever hold their peace"
>> >
>> > Or at least be nice about not holding their peace. :)
>> >
>> > Two days and I merge this. I will aim for high noon on Friday.
>> >
>> > --joel
>> >
>> > On Sun, Aug 7, 2022 at 5:58 AM Duc Doan > > > wrote:
>> >
>> > Dear all,
>> >
>> > These patches are to address the issues in my previous versions. These
>> > include GPIO API, ADC API and STM32F4 BSP implementation for them.
>> >
>> > My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS
>> >  (master
>> > branch).
>> > The sample application code for these APIs can be found at:
>> > https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps
>> > .
>> >
>> > STM32F4 HAL source code is taken from ST's repo at:
>> > https://github.com/STMicroelectronics/STM32CubeF4.git
>> >  (Commit ID:
>> > 52757b5,
>> > Release v1.27.1).
>> >
>> > v2:
>> >

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Joel Sherrill

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas 
wrote:

>
> The problem is that we still need to discuss licensing here. Randomly
> checked files from the HAL patch contains this as a license:
>
>* This software is licensed under terms that can be found in the
> LICENSE file
>* in the root directory of this software component.
>* If no LICENSE file comes with this software, it is provided AS-IS.
>
> and in the past Sebastian suggested to clear the message hence I used
> something used here:
>
>
> https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much duplicated
over and over. Would it be possible to put the lengthy explanation in one
place with the HAL addition and then have a short explanation in each file:

/*
 * RTEMS committer clarification comment on license above:
 *
 * This file comes from STM32CubeH7 project from its Projects subdirectory.
See
 * RTEMS_PATH_TBD for details on the license for this file.
 */

With RTEMS_PATH_TBD probably easy to identify because it would
be something like bsps/arm/shared/STMHM7 and then the single
file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
LICENSE.txt which is easy to confuse.

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

This is just record keeping to maintain proper attribution, origin URL,
licensing, etc. without burden of duplication. They obviously thought it
was a duplication burden. We should use their trick and just point to
our location for that file. :)

It's not like we are trying to nick the code and not give credit. We are
likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

>
>
> unfortunately whole F4 HAL would probably need such modification.
>

And even a better reason to make a short note in each file and put the
details in a single file in the HAL top directory.

>
>
> On the bright side, it looks like STM still holds on BSD-3 for their HAL
> code for F4?
>
> https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md

+1

>
>
> Would be great indeed.
>
> BTW: sorry, I'm really out of the loop on this still trying to catch up
> with all the development in RTEMS over summer...
>

Understood. Work is busy. RTEMS is busy. And with things getting back
to normal, I've even been busy going to concerts and other outings that
I missed. :)

--joel

>
> Karel
>
>
>
> On 9/21/22 15:25, Joel Sherrill wrote:
> > This patch set has been sitting for almost 7 weeks. I was going to commit
> > it today but was asked to give one last the patch merge equivalent  of
> > ""if anyone can show just cause why this patch and RTEMS cannot  be
> > joined together, let them speak now or forever hold their peace"
> >
> > Or at least be nice about not holding their peace. :)
> >
> > Two days and I merge this. I will aim for high noon on Friday.
> >
> > --joel
> >
> > On Sun, Aug 7, 2022 at 5:58 AM Duc Doan  > > wrote:
> >
> > Dear all,
> >
> > These patches are to address the issues in my previous versions.
> These
> > include GPIO API, ADC API and STM32F4 BSP implementation for them.
> >
> > My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS
> >  (master
> > branch).
> > The sample application code for these APIs can be found at:
> > https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps
> > .
> >
> > STM32F4 HAL source code is taken from ST's repo at:
> > https://github.com/STMicroelectronics/STM32CubeF4.git
> >  (Commit ID:
> > 52757b5,
> > Release v1.27.1).
> >
> > v2:
> > - Made get_gpio_from_base() a macro instead of a function
> > - Added missing cppflags in spec/build/bsps/arm/grp.yml
> > - Optimized STM32F4_GET_HAL_GPIO_PIN() and STM32F4_GET_LL_EXTI_LINE()
> > - Optimized functions by switching from HAL to LL
> > - Made stm32f4_gpio_deinit() return RTEMS_NOT_IMPLEMENTED, because
> > disabling
> > clock might affect all pins in a port
> > - Add const to static helper arrays to make sure they are placed on
> ROM
> >
> > v3:
> > - Removed rtems_gpio_begin()
> > - bsp_gpio_register_controllers() now needs to be called from hook1
> > (can be configured by option STM32F4_ENABLE_GENERIC_GPIO)
> > - Updated license text for API files and STM32F4 GPIO files
> >
> > v4:
> > - Fixed GPIO port guards
> > - Fixed potential memory-leak bug of STM32F4 GPIO interrupt system
> > - Added comments to STM32F4 GPIO functions and made them extern
> >
> > v5:
> > - Replace old HAL source code with the one from official repository
> > to remove
> > CRLF
> > -

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Karel Gardas


On 9/21/22 15:48, Karel Gardas wrote:
On the bright side, it looks like STM still holds on BSD-3 for their HAL 
code for F4?


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md

Would be great indeed.


After very quick investigation, everything under CMSIS is under Apache 
2.0 including this file:


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c

which is probably copied here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32f4/hal/system_stm32f4xx.c

Duc, am I right?

Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Karel Gardas



The problem is that we still need to discuss licensing here. Randomly 
checked files from the HAL patch contains this as a license:


  * This software is licensed under terms that can be found in the 
LICENSE file

  * in the root directory of this software component.
  * If no LICENSE file comes with this software, it is provided AS-IS.

and in the past Sebastian suggested to clear the message hence I used 
something used here:


https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c


unfortunately whole F4 HAL would probably need such modification.


On the bright side, it looks like STM still holds on BSD-3 for their HAL 
code for F4?


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md

Would be great indeed.

BTW: sorry, I'm really out of the loop on this still trying to catch up 
with all the development in RTEMS over summer...


Karel



On 9/21/22 15:25, Joel Sherrill wrote:

This patch set has been sitting for almost 7 weeks. I was going to commit
it today but was asked to give one last the patch merge equivalent  of
""if anyone can show just cause why this patch and RTEMS cannot  be
joined together, let them speak now or forever hold their peace"

Or at least be nice about not holding their peace. :)

Two days and I merge this. I will aim for high noon on Friday.

--joel

On Sun, Aug 7, 2022 at 5:58 AM Duc Doan > wrote:


Dear all,

These patches are to address the issues in my previous versions. These
include GPIO API, ADC API and STM32F4 BSP implementation for them.

My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS
 (master
branch).
The sample application code for these APIs can be found at:
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps
.

STM32F4 HAL source code is taken from ST's repo at:
https://github.com/STMicroelectronics/STM32CubeF4.git
 (Commit ID:
52757b5,
Release v1.27.1).

v2:
- Made get_gpio_from_base() a macro instead of a function
- Added missing cppflags in spec/build/bsps/arm/grp.yml
- Optimized STM32F4_GET_HAL_GPIO_PIN() and STM32F4_GET_LL_EXTI_LINE()
- Optimized functions by switching from HAL to LL
- Made stm32f4_gpio_deinit() return RTEMS_NOT_IMPLEMENTED, because
disabling
clock might affect all pins in a port
- Add const to static helper arrays to make sure they are placed on ROM

v3:
- Removed rtems_gpio_begin()
- bsp_gpio_register_controllers() now needs to be called from hook1
(can be configured by option STM32F4_ENABLE_GENERIC_GPIO)
- Updated license text for API files and STM32F4 GPIO files

v4:
- Fixed GPIO port guards
- Fixed potential memory-leak bug of STM32F4 GPIO interrupt system
- Added comments to STM32F4 GPIO functions and made them extern

v5:
- Replace old HAL source code with the one from official repository
to remove
CRLF
- Added a peripherals API, which is a framework to add more APIs
that operates
on a GPIO pin
- Changed GPIO API to comply with the peripherals API
- Changed ADC API to comply with the peripherals API
- Changed STM32F4 implementation

v6:
- Split commits that add CMSIS and HAL
- Removed peripheral API
- Changed ADC API: this is now separate from GPIO API

Duc Doan (10):
   bsps/arm: Convert CMSIS files from CRLF to LF
   bsps/arm: Changed CMSIS files to v5
   build/bsps/arm: Add new CMSIS files v5 to build
   bsps/arm/stm32f4: Include STM32F4 HAL
   bsps/arm/stm32f4: Add HAL to build
   bsps/arm/stm32f4: Make bspstart use HAL
   bsps: Add GPIO API
   bsps/arm/stm32f4: GPIO Implementation
   bsps: Add ADC API
   bsps/arm/stm32f4: ADC API implementation

  bsps/arm/include/cmsis_compiler.h             |   266 +
  bsps/arm/include/cmsis_gcc.h                  |  3460 +--
  bsps/arm/include/cmsis_version.h              |    39 +
  bsps/arm/include/core_cm4.h                   |   524 +-
  bsps/arm/include/core_cm7.h                   |  5186 ++--
  bsps/arm/include/core_cmFunc.h                |   172 +-
  bsps/arm/include/core_cmInstr.h               |   174 +-
  bsps/arm/include/core_cmSimd.h                |   192 +-
  bsps/arm/include/mpu_armv7.h                  |   270 +
  bsps/arm/stm32f4/adc/adc.c                    |   495 +
  bsps/arm/stm32f4/gpio/gpio.c                  |   557 +
  .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c    |  1679 ++
  .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c    |  2307 ++
  bsps/arm/stm32f4/hal/stm32f4xx_hal.c          |   615 +
  bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c      |  2110 ++

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Joel Sherrill

This patch set has been sitting for almost 7 weeks. I was going to commit
it today but was asked to give one last the patch merge equivalent  of
""if anyone can show just cause why this patch and RTEMS cannot  be
joined together, let them speak now or forever hold their peace"

Or at least be nice about not holding their peace. :)

Two days and I merge this. I will aim for high noon on Friday.

--joel

On Sun, Aug 7, 2022 at 5:58 AM Duc Doan  wrote:

> Dear all,
>
> These patches are to address the issues in my previous versions. These
> include GPIO API, ADC API and STM32F4 BSP implementation for them.
>
> My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS (master
> branch).
> The sample application code for these APIs can be found at:
> https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps.
>
> STM32F4 HAL source code is taken from ST's repo at:
> https://github.com/STMicroelectronics/STM32CubeF4.git (Commit ID: 52757b5,
> Release v1.27.1).
>
> v2:
> - Made get_gpio_from_base() a macro instead of a function
> - Added missing cppflags in spec/build/bsps/arm/grp.yml
> - Optimized STM32F4_GET_HAL_GPIO_PIN() and STM32F4_GET_LL_EXTI_LINE()
> - Optimized functions by switching from HAL to LL
> - Made stm32f4_gpio_deinit() return RTEMS_NOT_IMPLEMENTED, because
> disabling
> clock might affect all pins in a port
> - Add const to static helper arrays to make sure they are placed on ROM
>
> v3:
> - Removed rtems_gpio_begin()
> - bsp_gpio_register_controllers() now needs to be called from hook1
> (can be configured by option STM32F4_ENABLE_GENERIC_GPIO)
> - Updated license text for API files and STM32F4 GPIO files
>
> v4:
> - Fixed GPIO port guards
> - Fixed potential memory-leak bug of STM32F4 GPIO interrupt system
> - Added comments to STM32F4 GPIO functions and made them extern
>
> v5:
> - Replace old HAL source code with the one from official repository to
> remove
> CRLF
> - Added a peripherals API, which is a framework to add more APIs that
> operates
> on a GPIO pin
> - Changed GPIO API to comply with the peripherals API
> - Changed ADC API to comply with the peripherals API
> - Changed STM32F4 implementation
>
> v6:
> - Split commits that add CMSIS and HAL
> - Removed peripheral API
> - Changed ADC API: this is now separate from GPIO API
>
> Duc Doan (10):
>   bsps/arm: Convert CMSIS files from CRLF to LF
>   bsps/arm: Changed CMSIS files to v5
>   build/bsps/arm: Add new CMSIS files v5 to build
>   bsps/arm/stm32f4: Include STM32F4 HAL
>   bsps/arm/stm32f4: Add HAL to build
>   bsps/arm/stm32f4: Make bspstart use HAL
>   bsps: Add GPIO API
>   bsps/arm/stm32f4: GPIO Implementation
>   bsps: Add ADC API
>   bsps/arm/stm32f4: ADC API implementation
>
>  bsps/arm/include/cmsis_compiler.h |   266 +
>  bsps/arm/include/cmsis_gcc.h  |  3460 +--
>  bsps/arm/include/cmsis_version.h  |39 +
>  bsps/arm/include/core_cm4.h   |   524 +-
>  bsps/arm/include/core_cm7.h   |  5186 ++--
>  bsps/arm/include/core_cmFunc.h|   172 +-
>  bsps/arm/include/core_cmInstr.h   |   174 +-
>  bsps/arm/include/core_cmSimd.h|   192 +-
>  bsps/arm/include/mpu_armv7.h  |   270 +
>  bsps/arm/stm32f4/adc/adc.c|   495 +
>  bsps/arm/stm32f4/gpio/gpio.c  |   557 +
>  .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c|  1679 ++
>  .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c|  2307 ++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |   615 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  |  2110 ++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   |  1112 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  |  2462 ++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |   996 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |   502 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |   328 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c |  7132 ++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |   680 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  |  1341 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |   495 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c |  1161 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |   182 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c|  4423 
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  |  1305 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c|  2126 ++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |   313 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  |  2760 +++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  |  3220 +++
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |   547 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c|   775 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c |  1347 +
>  .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |   172 +
>  bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c   |  6864 ++
>  .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c |   258 +
>

[PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-08-07 Thread Duc Doan

Dear all,

These patches are to address the issues in my previous versions. These 
include GPIO API, ADC API and STM32F4 BSP implementation for them.

My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS (master
branch).
The sample application code for these APIs can be found at:
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps.

STM32F4 HAL source code is taken from ST's repo at:
https://github.com/STMicroelectronics/STM32CubeF4.git (Commit ID: 52757b5,
Release v1.27.1).

v2:
- Made get_gpio_from_base() a macro instead of a function
- Added missing cppflags in spec/build/bsps/arm/grp.yml
- Optimized STM32F4_GET_HAL_GPIO_PIN() and STM32F4_GET_LL_EXTI_LINE()
- Optimized functions by switching from HAL to LL
- Made stm32f4_gpio_deinit() return RTEMS_NOT_IMPLEMENTED, because disabling
clock might affect all pins in a port
- Add const to static helper arrays to make sure they are placed on ROM

v3:
- Removed rtems_gpio_begin()
- bsp_gpio_register_controllers() now needs to be called from hook1
(can be configured by option STM32F4_ENABLE_GENERIC_GPIO)
- Updated license text for API files and STM32F4 GPIO files

v4:
- Fixed GPIO port guards
- Fixed potential memory-leak bug of STM32F4 GPIO interrupt system
- Added comments to STM32F4 GPIO functions and made them extern

v5:
- Replace old HAL source code with the one from official repository to remove
CRLF
- Added a peripherals API, which is a framework to add more APIs that operates
on a GPIO pin
- Changed GPIO API to comply with the peripherals API
- Changed ADC API to comply with the peripherals API
- Changed STM32F4 implementation

v6:
- Split commits that add CMSIS and HAL
- Removed peripheral API
- Changed ADC API: this is now separate from GPIO API

Duc Doan (10):
  bsps/arm: Convert CMSIS files from CRLF to LF
  bsps/arm: Changed CMSIS files to v5
  build/bsps/arm: Add new CMSIS files v5 to build
  bsps/arm/stm32f4: Include STM32F4 HAL
  bsps/arm/stm32f4: Add HAL to build
  bsps/arm/stm32f4: Make bspstart use HAL
  bsps: Add GPIO API
  bsps/arm/stm32f4: GPIO Implementation
  bsps: Add ADC API
  bsps/arm/stm32f4: ADC API implementation

 bsps/arm/include/cmsis_compiler.h |   266 +
 bsps/arm/include/cmsis_gcc.h  |  3460 +--
 bsps/arm/include/cmsis_version.h  |39 +
 bsps/arm/include/core_cm4.h   |   524 +-
 bsps/arm/include/core_cm7.h   |  5186 ++--
 bsps/arm/include/core_cmFunc.h|   172 +-
 bsps/arm/include/core_cmInstr.h   |   174 +-
 bsps/arm/include/core_cmSimd.h|   192 +-
 bsps/arm/include/mpu_armv7.h  |   270 +
 bsps/arm/stm32f4/adc/adc.c|   495 +
 bsps/arm/stm32f4/gpio/gpio.c  |   557 +
 .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c|  1679 ++
 .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c|  2307 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |   615 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  |  2110 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   |  1112 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  |  2462 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |   996 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |   502 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |   328 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c |  7132 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |   680 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  |  1341 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |   495 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c |  1161 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |   182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c|  4423 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  |  1305 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c|  2126 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |   313 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  |  2760 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  |  3220 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |   547 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c|   775 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c |  1347 +
 .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |   172 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c   |  6864 ++
 .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c |   258 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpsmbus.c |  2749 +++
 .../stm32f4/hal/stm32f4xx_hal_fmpsmbus_ex.c   |   145 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_gpio.c |   533 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash.c |  3514 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash_ex.c  |  1040 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hcd.c  |  1728 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c.c  |  7524 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c_ex.c   |   182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s.c  |  2094 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s_ex.c   |  1135 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_irda.c |  2687 ++

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

[PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

11 matches

Site Navigation

Mail list logo

Footer information