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

[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?

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