Re: Static Analysis Tools for RTEMS
On 10/6/2022 12:09 am, Joel Sherrill wrote: > With Matthew addressing new warnings from GCC 12, I have posted some warning fixes for the arm and aarch64. They let those archs build warning free without the testsuite. I hope it helps. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] cpukit: Change _COMPILING_NEWLIB to _LIBC for helper functions decls
From: Chris Johns Updates #4662 --- cpukit/libcsupport/src/__times.c | 4 ++-- cpukit/posix/src/_execve.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cpukit/libcsupport/src/__times.c b/cpukit/libcsupport/src/__times.c index 629a7bc633..14625b5aae 100644 --- a/cpukit/libcsupport/src/__times.c +++ b/cpukit/libcsupport/src/__times.c @@ -38,9 +38,9 @@ #endif /* - * Needed to get the prototype for this newlib helper method + * Needed to get the prototype for this libc helper method */ -#define _COMPILING_NEWLIB +#define _LIBC #include diff --git a/cpukit/posix/src/_execve.c b/cpukit/posix/src/_execve.c index 2858d13082..63afadec43 100644 --- a/cpukit/posix/src/_execve.c +++ b/cpukit/posix/src/_execve.c @@ -43,9 +43,9 @@ #endif /* - * Needed to get the prototype for this newlib helper method + * Needed to get the prototype for this libc helper method */ -#define _COMPILING_NEWLIB +#define _LIBC #include #include -- 2.19.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] score/cpu: Silence ARM and AARCH64 GCC 12 false trigger array warning
From: Chris Johns
The false trigger is covered in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104657
GCC 11 and 12 has been patched for constant pointer casts above
4K. This code casts a constant pointer within the first 4K
page. As a result the patch disables the warning.
Updates #4662
---
cpukit/score/cpu/aarch64/cpu.c | 3 +++
cpukit/score/cpu/arm/cpu.c | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/aarch64/cpu.c b/cpukit/score/cpu/aarch64/cpu.c
index 88e7ad8a8c..f0062adf30 100644
--- a/cpukit/score/cpu/aarch64/cpu.c
+++ b/cpukit/score/cpu/aarch64/cpu.c
@@ -180,6 +180,8 @@ void _CPU_ISR_install_vector(
CPU_ISR_handler *old_handler
)
{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
/* Redirection table starts at the end of the vector table */
CPU_ISR_handler *table = (CPU_ISR_handler *) (MAX_EXCEPTIONS * 4);
@@ -194,6 +196,7 @@ void _CPU_ISR_install_vector(
if (current_handler != new_handler) {
table [vector] = new_handler;
}
+#pragma GCC diagnostic pop
}
void _CPU_Initialize( void )
diff --git a/cpukit/score/cpu/arm/cpu.c b/cpukit/score/cpu/arm/cpu.c
index 5c5b253470..b2cc6039b0 100644
--- a/cpukit/score/cpu/arm/cpu.c
+++ b/cpukit/score/cpu/arm/cpu.c
@@ -167,8 +167,10 @@ void _CPU_ISR_install_vector(
CPU_ISR_handler *old_handler
)
{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
/* Redirection table starts at the end of the vector table */
- CPU_ISR_handler *table = (CPU_ISR_handler *) (MAX_EXCEPTIONS * 4);
+ CPU_ISR_handler volatile *table = (CPU_ISR_handler *) (MAX_EXCEPTIONS * 4);
CPU_ISR_handler current_handler = table [vector];
@@ -181,6 +183,7 @@ void _CPU_ISR_install_vector(
if (current_handler != new_handler) {
table [vector] = new_handler;
}
+#pragma GCC diagnostic pop
}
void _CPU_Initialize( void )
--
2.19.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] cpukit: Fixes for GCC 12 warnings
From: Chris Johns
Updates #6442
---
cpukit/libmd/md5.c | 2 +-
cpukit/libmisc/shell/hexdump-conv.c | 4
cpukit/libmisc/shell/main_edit.c| 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
index 4c909f37a0..5e3a100c7b 100644
--- a/cpukit/libmd/md5.c
+++ b/cpukit/libmd/md5.c
@@ -165,7 +165,7 @@ void MD5Update (
ends with the desired message digest in mdContext->digest[0...15].
*/
void MD5Final (
- unsigned char hash[],
+ unsigned char hash[16],
MD5_CTX *mdContext )
{
UINT4 in[16];
diff --git a/cpukit/libmisc/shell/hexdump-conv.c
b/cpukit/libmisc/shell/hexdump-conv.c
index aa16f9b169..24b28353f3 100644
--- a/cpukit/libmisc/shell/hexdump-conv.c
+++ b/cpukit/libmisc/shell/hexdump-conv.c
@@ -117,7 +117,11 @@ retry:
if (clen == 0)
clen = 1;
else if (clen == (size_t)-1 || (clen == (size_t)-2 &&
+#ifndef __rtems__
buf == peekbuf)) {
+#else /* __rtems__ */
+ [0] == [0])) {
+#endif /* __rtems__ */
memset(>mbstate, 0, sizeof(pr->mbstate));
wc = *p;
clen = 1;
diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index ed1371f7fa..4cc742719a 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -55,7 +55,9 @@
#if defined(__linux__) || defined(__rtems__)
#include
#include
+#ifndef O_BINARY
#define O_BINARY 0
+#endif
static int linux_console;
#endif
--
2.19.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] bsps/arm: MP core timer setting off by one
From: Chris Johns --- bsps/arm/shared/clock/clock-a9mpcore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/shared/clock/clock-a9mpcore.c b/bsps/arm/shared/clock/clock-a9mpcore.c index 6c7abb0591..b3dc30eab4 100644 --- a/bsps/arm/shared/clock/clock-a9mpcore.c +++ b/bsps/arm/shared/clock/clock-a9mpcore.c @@ -129,7 +129,7 @@ static void a9mpcore_clock_initialize(void) volatile a9mpcore_gt *gt = A9MPCORE_GT; uint64_t periphclk = a9mpcore_clock_periphclk(); uint64_t us_per_tick = rtems_configuration_get_microseconds_per_tick(); - uint32_t interval = (uint32_t) ((periphclk * us_per_tick) / 100); + uint32_t interval = (uint32_t) ((periphclk * us_per_tick) / 100) - 1; uint64_t cmpval; gt->ctrl &= A9MPCORE_GT_CTRL_TMR_EN; -- 2.19.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] score/cpu: Silence ARM and AARCH64 GCC 12 false trigger array warning
On 14/6/2022 11:24 am, chr...@rtems.org wrote: > From: Chris Johns > > The false trigger is covered in: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104657 This is the link I meant to include .. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 I will update commit and push with this link if approved. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] bsp/aarch64: Flush the cache before invalidating it
From: Chris Johns - Any page tables need to be flushed if the cache is enabled. Disabling the cache may only be available in secure mode. --- bsps/aarch64/include/bsp/aarch64-mmu.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h b/bsps/aarch64/include/bsp/aarch64-mmu.h index b1a471d534..6e589cd6cd 100644 --- a/bsps/aarch64/include/bsp/aarch64-mmu.h +++ b/bsps/aarch64/include/bsp/aarch64-mmu.h @@ -362,7 +362,8 @@ aarch64_mmu_enable( void ) /* CPUECTLR_EL1.SMPEN is already set on ZynqMP and is not writable */ - /* Invalidate cache */ + /* Flush and invalidate cache */ + rtems_cache_flush_entire_data(); rtems_cache_invalidate_entire_data(); /* Enable MMU and cache */ -- 2.19.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] bsp/versal: Support more than 4G of RAM
From: Chris Johns --- spec/build/bsps/aarch64/xilinx-versal/optramlen.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/build/bsps/aarch64/xilinx-versal/optramlen.yml b/spec/build/bsps/aarch64/xilinx-versal/optramlen.yml index ebc36d3139..95347fc7e3 100644 --- a/spec/build/bsps/aarch64/xilinx-versal/optramlen.yml +++ b/spec/build/bsps/aarch64/xilinx-versal/optramlen.yml @@ -1,7 +1,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: - get-integer: null -- assert-uint32: null +- assert-uint64: null - env-assign: null - format-and-define: null build-type: option -- 2.19.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] aarch64/gicv3: Remove accesses to secure registers
From: Chris Johns
---
bsps/include/dev/irq/arm-gicv3.h | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h
index 0d3ef9a1c1..a79368ebdf 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -300,12 +300,25 @@ static void gicv3_init_dist(volatile gic_dist *dist)
}
}
+/*
+ * A better way to access these registers than special opcodes
+ */
+#define isb() __asm __volatile("isb" : : : "memory")
+
+#define WRITE_SPECIALREG(reg, _val)\
+ __asm __volatile("msr " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
+
+#define gic_icc_write(reg, val)\
+do {\
+ WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
+ isb();\
+} while (0)
+
static void gicv3_init_cpu_interface(uint32_t cpu_index)
{
uint32_t sre_value = 0x7;
WRITE_SR(ICC_SRE, sre_value);
WRITE_SR(ICC_PMR, GIC_CPUIF_ICCPMR_PRIORITY(0xff));
- WRITE_SR(ICC_BPR0, GIC_CPUIF_ICCBPR_BINARY_POINT(0x0));
volatile gic_redist *redist = gicv3_get_redist(cpu_index);
uint32_t waker = redist->icrwaker;
@@ -322,8 +335,7 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
}
/* Enable interrupt groups 0 and 1 */
- WRITE_SR(ICC_IGRPEN0, 0x1);
- WRITE_SR(ICC_IGRPEN1, 0x1);
+ gic_icc_write(IGRPEN1, 1);
WRITE_SR(ICC_CTLR, 0x0);
}
--
2.19.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Porting PPS API support to RTEMS 5
Hello everyone, I ported the PPS API support from RTEMS 6 to RTEMS 5 and wanted to ask if somebody is interest to have the changes in the upstream. If yes, I can submit the patches. Best regards, Gabriel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] bsps/atsam: Fix type of options (part 2)
The patch "bsps/atsam: Fix type of options" missed to adapt some parts
of the yml. With that a custom value works well. But if no value is set,
configure doesn't fall back to the default value but instead just causes
an error. This patch fixes that.
---
spec/build/bsps/arm/atsam/optconidx.yml | 3 ++-
spec/build/bsps/arm/atsam/optcontype.yml | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/spec/build/bsps/arm/atsam/optconidx.yml
b/spec/build/bsps/arm/atsam/optconidx.yml
index 1c0723c594..d58d75e4aa 100644
--- a/spec/build/bsps/arm/atsam/optconidx.yml
+++ b/spec/build/bsps/arm/atsam/optconidx.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device index for /dev/console (default 1, e.g. USART1)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_INDEX
type: build
diff --git a/spec/build/bsps/arm/atsam/optcontype.yml
b/spec/build/bsps/arm/atsam/optcontype.yml
index fd0daa8999..6846fed5f2 100644
--- a/spec/build/bsps/arm/atsam/optcontype.yml
+++ b/spec/build/bsps/arm/atsam/optcontype.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device type for /dev/console, use 0 for USART and 1 for UART (default USART)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_TYPE
type: build
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Should README's have license statement?
Hello Joel, Am 10.06.22 um 17:42 schrieb Joel Sherrill: Hi I'm back to relicensing for a bit and noticed that it looks like none of the README's in testsuites have a license or copyright statement. Should they? Difficult question and I don't really have an answer for it. Some longer README files most likely should have a license (like the files in libbsd). Others are very short and contain more or less only a comment for a directory (like the testsuites/sptests/README). I'm not sure about these. I can do forensics on the copyright attribution. Should the README's be BSD-2, Creative Commons, or remain like they are with nothing? READMEs have the tendency that they are added to the documentation once they reach a certain size. So if they need a license I think the same license like in rtems-docs would be the best one. Best regards Christian Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Problem with STM32 HAL license
Dear all, I am working on my GSoC project about adding features to the STM32F4 BSP. I am planning to include STM32 HAL from STMicroelectronics (which can be found here: https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Drivers/STM32F4xx_HAL_Driver) into RTEMS. However, the license text in each code file might be unclear: "This software is licensed under terms that can be found in the LICENSE file in the root directory of this software component. If no LICENSE file comes with this software, it is provided AS-IS", especially the part about a LICENSE file "in the root directory". The root directory is likely the STM32F4xx_HAL_Driver folder that I have included the direct link above. I would like to ask if I need to modify (adding text clarification in the license text for each file) the files, or should I do something else to be safe? Best, Duc Doan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On Mon, Jun 13, 2022 at 11:19 AM Duc Doan wrote: > Dear all, > > I am working on my GSoC project about adding features to the STM32F4 BSP. > I am planning to include STM32 HAL from STMicroelectronics (which can be > found here: > https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Drivers/STM32F4xx_HAL_Driver) > into RTEMS. However, the license text in each code file might be unclear: > "This software is licensed under terms that can be found in the LICENSE > file in the root directory of this software component. If no LICENSE file > comes with this software, it is provided AS-IS", especially the part about > a LICENSE file "in the root directory". The root directory is likely the > STM32F4xx_HAL_Driver folder that I have included the direct link above. I > would like to ask if I need to modify (adding text clarification in the > license text for each file) the files, or should I do something else to be > safe? > Is this the text found in each source file? https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c#L9 I don't think this is a direct copy of the 3 paragraph BSD license which we have at the top of the RTEMS source tree ( https://git.rtems.org/rtems/tree/LICENSE.BSD-3-Clause). I'm prone to suggest putting a LICENSE.STM-3-Clause at the top of the RTEMS tree and adding a comment in ifdef __rtems__ at the top of each file saying the LICENSE file is there. This impacts other imports from STM so I am curious what Karel, Sebastian, and Andrei are seeing for the license in the code they are importing and what they plan to do. I don't think we can have a generically named file "LICENSE" way down in the tree. We have the pattern of having licenses at the top of the RTEMS source tree. --joel > > Best, > > Duc Doan > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On Mon, Jun 13, 2022 at 1:03 PM Gedare Bloom wrote: > On Mon, Jun 13, 2022 at 11:02 AM Joel Sherrill wrote: > > > > > > > > On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom wrote: > >> > >> On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas > wrote: > >> > > >> > On 6/13/22 18:27, Joel Sherrill wrote: > >> > > This impacts other imports from STM so I am curious what Karel, > >> > > Sebastian, and Andrei are seeing for the license in the code they > are > >> > > importing and what they plan to do. > >> > > >> > So far on H7, the HAL used is older code base which is clearly BSD-3 > >> > license: > >> > > >> > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22 > >> > > >> > however to support new boards or peripherals I've imported few files > >> > which use the same unclear license message. I've clarified it in any > >> > imported file like: > >> > > >> > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35 > >> > > >> > the problem is obviously scalability of this solution and future > merges. > >> > You can do that one one/two board files, but probably not on whole HAL > >> > with ~100 files. > >> > I also remember that Sebastian recommended to completely replace this > >> > license note with the specified license (to which note points). But > I've > >> > not done that due to reluctancy of touching STM license notes here and > >> > hence came with committer clarification message below every such note. > >> > > >> > >> My preference here would be to use injection of the committer comment, > >> along with the addition of the SPDX tag at the top line. You should be > >> able to automate this injection even for 100+ files, as long as they > >> are using the same license. Keeping these changes together at the top > >> of the file should also help handle merge problems if updates are > >> pulled later. > > > > > > What do you mean "injection of the committer comment"? Do you mean > > Karel's example? Or just something in the git commit? > > > Karel's example. Something to show the due diligence that was done. > +1 Ideally the entire thing doesn't have to go in every file but the SPDX tag and at least a reference to an explanation file would be good. > > > If we can name this for SPDX, that would be great. Ideally all files have > > an SPDX annotation and that points to a unique master copy of the license > > at the top of the RTEMS source tree. > > > If it doesn't match an SPDX tag, I think that is a problem for us to > accept. > Supposedly, SPDX allows custom tags and the tooling allows a way for us to define the tag to license text file association. I have no idea how any of the tooling works. We need someone to work with their tools to see how they work. > > > I've suggested an "origin" file before where details like Karel captured > > can be placed once in a directory. > > > That's ok, but harder to maintain. > > > --joel > >> > >> > >> > Hence I asked Duc on discord to ask here for advice. BTW, new HAL for > H7 > >> > will be probably in the same situation like Duc seing with current F4. > >> > > >> > > https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c > >> > > >> > > >> > So we definitely need to find a solution to this issue. > >> > > >> > Thanks, > >> > Karel > >> > ___ > >> > devel mailing list > >> > devel@rtems.org > >> > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsp/aarch64: Fix array warning
On 6/12/2022 01:30, Chris Johns wrote: On 12/6/22 12:59 am, Joel Sherrill wrote: Should this use that obscure pointer macro Sebastian suggests sometimes? I looked into that and could not get it to work. This works. If you would like to try please do? I've been testing for a little while with this exact patch as suggested by the warning with no issues. Looks good. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsp/aarch64: Fix array warning
On Mon, Jun 13, 2022 at 11:41 AM Kinsey Moore wrote: > On 6/12/2022 01:30, Chris Johns wrote: > > On 12/6/22 12:59 am, Joel Sherrill wrote: > >> Should this use that obscure pointer macro Sebastian suggests sometimes? > > I looked into that and could not get it to work. This works. If you > would like > > to try please do? > I've been testing for a little while with this exact patch as suggested > by the warning with no issues. Looks good. > OK. Push it. I thought there was a macro to use when comparing different pointer types. But I can't find it and I'm not having luck building gcc 12 tools so far. --joel > > Kinsey > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On 6/13/22 18:27, Joel Sherrill wrote: This impacts other imports from STM so I am curious what Karel, Sebastian, and Andrei are seeing for the license in the code they are importing and what they plan to do. So far on H7, the HAL used is older code base which is clearly BSD-3 license: https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22 however to support new boards or peripherals I've imported few files which use the same unclear license message. I've clarified it in any imported file like: https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35 the problem is obviously scalability of this solution and future merges. You can do that one one/two board files, but probably not on whole HAL with ~100 files. I also remember that Sebastian recommended to completely replace this license note with the specified license (to which note points). But I've not done that due to reluctancy of touching STM license notes here and hence came with committer clarification message below every such note. Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7 will be probably in the same situation like Duc seing with current F4. https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c So we definitely need to find a solution to this issue. Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas wrote: > > On 6/13/22 18:27, Joel Sherrill wrote: > > This impacts other imports from STM so I am curious what Karel, > > Sebastian, and Andrei are seeing for the license in the code they are > > importing and what they plan to do. > > So far on H7, the HAL used is older code base which is clearly BSD-3 > license: > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22 > > however to support new boards or peripherals I've imported few files > which use the same unclear license message. I've clarified it in any > imported file like: > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35 > > the problem is obviously scalability of this solution and future merges. > You can do that one one/two board files, but probably not on whole HAL > with ~100 files. > I also remember that Sebastian recommended to completely replace this > license note with the specified license (to which note points). But I've > not done that due to reluctancy of touching STM license notes here and > hence came with committer clarification message below every such note. > My preference here would be to use injection of the committer comment, along with the addition of the SPDX tag at the top line. You should be able to automate this injection even for 100+ files, as long as they are using the same license. Keeping these changes together at the top of the file should also help handle merge problems if updates are pulled later. > Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7 > will be probably in the same situation like Duc seing with current F4. > > https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c > > > So we definitely need to find a solution to this issue. > > Thanks, > Karel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom wrote: > On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas > wrote: > > > > On 6/13/22 18:27, Joel Sherrill wrote: > > > This impacts other imports from STM so I am curious what Karel, > > > Sebastian, and Andrei are seeing for the license in the code they are > > > importing and what they plan to do. > > > > So far on H7, the HAL used is older code base which is clearly BSD-3 > > license: > > > > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22 > > > > however to support new boards or peripherals I've imported few files > > which use the same unclear license message. I've clarified it in any > > imported file like: > > > > > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35 > > > > the problem is obviously scalability of this solution and future merges. > > You can do that one one/two board files, but probably not on whole HAL > > with ~100 files. > > I also remember that Sebastian recommended to completely replace this > > license note with the specified license (to which note points). But I've > > not done that due to reluctancy of touching STM license notes here and > > hence came with committer clarification message below every such note. > > > > My preference here would be to use injection of the committer comment, > along with the addition of the SPDX tag at the top line. You should be > able to automate this injection even for 100+ files, as long as they > are using the same license. Keeping these changes together at the top > of the file should also help handle merge problems if updates are > pulled later. > What do you mean "injection of the committer comment"? Do you mean Karel's example? Or just something in the git commit? If we can name this for SPDX, that would be great. Ideally all files have an SPDX annotation and that points to a unique master copy of the license at the top of the RTEMS source tree. I've suggested an "origin" file before where details like Karel captured can be placed once in a directory. --joel > > > Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7 > > will be probably in the same situation like Duc seing with current F4. > > > > > https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c > > > > > > So we definitely need to find a solution to this issue. > > > > Thanks, > > Karel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] bsps/atsam: Fix type of options (part 2)
Fixes build issues I reported. Please push.
--joel
On Mon, Jun 13, 2022 at 2:18 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:
> The patch "bsps/atsam: Fix type of options" missed to adapt some parts
> of the yml. With that a custom value works well. But if no value is set,
> configure doesn't fall back to the default value but instead just causes
> an error. This patch fixes that.
> ---
> spec/build/bsps/arm/atsam/optconidx.yml | 3 ++-
> spec/build/bsps/arm/atsam/optcontype.yml | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/spec/build/bsps/arm/atsam/optconidx.yml
> b/spec/build/bsps/arm/atsam/optconidx.yml
> index 1c0723c594..d58d75e4aa 100644
> --- a/spec/build/bsps/arm/atsam/optconidx.yml
> +++ b/spec/build/bsps/arm/atsam/optconidx.yml
> @@ -1,7 +1,7 @@
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-integer: null
> -- define-condition: null
> +- define: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> @@ -10,6 +10,7 @@ default-by-variant: []
> description: |
>device index for /dev/console (default 1, e.g. USART1)
> enabled-by: true
> +format: '{}'
> links: []
> name: ATSAM_CONSOLE_DEVICE_INDEX
> type: build
> diff --git a/spec/build/bsps/arm/atsam/optcontype.yml
> b/spec/build/bsps/arm/atsam/optcontype.yml
> index fd0daa8999..6846fed5f2 100644
> --- a/spec/build/bsps/arm/atsam/optcontype.yml
> +++ b/spec/build/bsps/arm/atsam/optcontype.yml
> @@ -1,7 +1,7 @@
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-integer: null
> -- define-condition: null
> +- define: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> @@ -10,6 +10,7 @@ default-by-variant: []
> description: |
>device type for /dev/console, use 0 for USART and 1 for UART (default
> USART)
> enabled-by: true
> +format: '{}'
> links: []
> name: ATSAM_CONSOLE_DEVICE_TYPE
> type: build
> --
> 2.35.3
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Problem with STM32 HAL license
On Mon, Jun 13, 2022 at 11:02 AM Joel Sherrill wrote: > > > > On Mon, Jun 13, 2022 at 11:57 AM Gedare Bloom wrote: >> >> On Mon, Jun 13, 2022 at 10:38 AM Karel Gardas >> wrote: >> > >> > On 6/13/22 18:27, Joel Sherrill wrote: >> > > This impacts other imports from STM so I am curious what Karel, >> > > Sebastian, and Andrei are seeing for the license in the code they are >> > > importing and what they plan to do. >> > >> > So far on H7, the HAL used is older code base which is clearly BSD-3 >> > license: >> > >> > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22 >> > >> > however to support new boards or peripherals I've imported few files >> > which use the same unclear license message. I've clarified it in any >> > imported file like: >> > >> > https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35 >> > >> > the problem is obviously scalability of this solution and future merges. >> > You can do that one one/two board files, but probably not on whole HAL >> > with ~100 files. >> > I also remember that Sebastian recommended to completely replace this >> > license note with the specified license (to which note points). But I've >> > not done that due to reluctancy of touching STM license notes here and >> > hence came with committer clarification message below every such note. >> > >> >> My preference here would be to use injection of the committer comment, >> along with the addition of the SPDX tag at the top line. You should be >> able to automate this injection even for 100+ files, as long as they >> are using the same license. Keeping these changes together at the top >> of the file should also help handle merge problems if updates are >> pulled later. > > > What do you mean "injection of the committer comment"? Do you mean > Karel's example? Or just something in the git commit? > Karel's example. Something to show the due diligence that was done. > If we can name this for SPDX, that would be great. Ideally all files have > an SPDX annotation and that points to a unique master copy of the license > at the top of the RTEMS source tree. > If it doesn't match an SPDX tag, I think that is a problem for us to accept. > I've suggested an "origin" file before where details like Karel captured > can be placed once in a directory. > That's ok, but harder to maintain. > --joel >> >> >> > Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7 >> > will be probably in the same situation like Duc seing with current F4. >> > >> > https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c >> > >> > >> > So we definitely need to find a solution to this issue. >> > >> > Thanks, >> > Karel >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
