Hello Christian, On Sat, 2022-07-30 at 22:19 +0200, o...@c-mauderer.de wrote: > > > > Am 30.07.22 um 21:41 schrieb Karel Gardas: > > On 7/30/22 16:32, o...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
