[PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

[oss at c-mauderer.de]

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).

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