[PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
oss at c-mauderer.de
oss at c-mauderer.de
Tue Aug 2 17:02:33 UTC 2022
Hello Duc,
Am 02.08.22 um 12:37 schrieb Duc Doan:
> Hello Christian,
>
> On Sat, 2022-07-30 at 22:19 +0200, oss at c-mauderer.de wrote:
>>
>>
>>
>> Am 30.07.22 um 21:41 schrieb Karel Gardas:
>>> On 7/30/22 16:32, oss at c-mauderer.de wrote:
>>>>> 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/mpu_armv7.h | 270 +
>>>>
>>>> Are the cmsis files from the same source or directly from ARM?
>>>>
>>>> The cmsis_gcc.h has a lot of changes compared to the earlier
>>>> version
>>>> that has been present in RTEMS. A lot of the changes seem to be
>>>> whitespace changes. Can these be avoided somehow (for example by
>>>> using
>>>> dos2unix before overwriting the file)?
>>>>
>>>> In the discord chat there was one suggestion from Ho Kaido to
>>>> move the
>>>> files one level down and make them BSP specific. I'm not sure
>>>> whether
>>>> I'm for or against that idea. Advantage is that it makes BSPs
>>>> independant from each other. Disadvantage is that it duplicates
>>>> code.
>>>>
>>>> I think I would try to avoid moving them down due to the code
>>>> duplication but it raises the question: Which BSPs use the files
>>>> too
>>>> and did you try whether they still compile after the upgrade?
>>>
>>> We have had this dicussion with Duc on discord IIRC when he
>>> started. He
>>> needed new CMSIS (v5) version due to new HAL which Duc claims
>>> depends on
>>> them. I have not verified that claim personally.
>>>
>>> New CMSIS v5 brings obviously:
>>>
>>> - by ARM maintained code (v4 is unmaintained IIRC)
>>>
>>> but also:
>>>
>>> - license change from BSD to Apache-2
>>>
>>> At that time I've told Duc to continue with the code and not to
>>> worry
>>> about license changes -- as this would be longer discussion anyway.
>>> Not
>>> sure, but IIRC he also wrote to Sebastian asking for clarification
>>> --
>>> well, not sure about that. Certainly IIRC I suggested that.
>>>
>>> Anyway, I took Duc code and try H7 BSPs and to my surprise they
>>> compiles
>>> more or less all without any compilation related issue. Well, I've
>>> not
>>> tried M4 variants. So far I've not run full tester on this. I'll,
>>> but
>>> first I'd like to test his API if it's possible to also use with
>>> H7.
>>>
>>> BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then
>>> it's
>>> perhaps possible to go in F4 HAL history back and grab just the
>>> three
>>> with the v4 dependency. On the other hand, for ARM Apache-2 seems
>>> to be
>>> the way forward and for some ST.com depended code too -- so I guess
>>> RTEMS project will need to live with that fact somehow.
>>>
>>> Thanks,
>>> Karel
>>>
>>
>> Hello Karel,
>>
>> thanks for the clarification. I have to be honest: I missed the
>> license
>> change. That is a bit of a difficult one and will cause a discussion.
>> @Duc: We need a new LICENSE.... file in the top level that represents
>> that. Maybe split the CMSIS update into a separate patch so that it
>> is
>> clear why there is a new license file (if the license is only for the
>> CMSIS and not for the STM HAL too).
>>
>
> Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source
> root? I found this file being shipped with STM
> HAL: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt
> Should I copy this file and rename it to LICENSE.Apache-2.0?
Short answer: Yes.
A bit longer answer: Please make sure that it's really an unchanged
Apache license before you copy it. I assume it is but just to be sure, I
would use a diff with the one from opensource.org:
https://opensource.org/licenses/Apache-2.0
Best regards
Christian
>
> Best,
>
> Duc
>
>> But my main concern was another one: Which BSPs use the CMSIS files?
>> Beneath the stm32 variants, that's at least the atsam and imxrt.
>> Maybe I
>> missed some more. We should at least make sure that these BSPs are
>> compile-clean with the updated cmsis headers.
>>
>> Best regards
>>
>> Christian
>
More information about the devel
mailing list