Hello Duc,
Am 02.08.22 um 12:37 schrieb Duc Doan:
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?
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
