Re: STM32H7 HAL update, merge ready.

[Karel Gardas]

On 3/10/22 16:10, Sebastian Huber wrote:


If you would like to review changes in HAL files, then you may diff 
original merged projects files. They both are on github.com so you can 
investigate either there or on local copy. But this is HAL code, 
something STMicro provided and I don't see any point in dealing with 
that -- unless there is some bug to report...


It is quite likely that this update breaks something and a reviewable 
history could help here. Another option would be to do the updates in 
smaller steps so that a git bisect is more effective.


Have a look into

https://github.com/STMicroelectronics/stm32h7xx_hal_driver/commits/master

and

https://github.com/STMicroelectronics/STM32CubeH7/commits/master

do you see? Even STMicro provides basically one big commit per whole 
package version number increase.


Conclusion: there is no point in doing what you suggest since you will 
not be able to bisect between smaller changes due to upstream choice of 
providing *BIG* code drops per commit.


Agree or not?

Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Apache License 2.0 all right for BSP code?

[Karel Gardas]

On 3/10/22 16:24, Sebastian Huber wrote:
"(b) You must cause any modified files to carry prominent notices 
stating that You changed the files;"


This means everyone changing the files need to pay attention to this.


If the Apache 2.0 files don't have an SPDX license identifier, then I 
think this should be added and a standard text which states that the 
file was modified to add the SPDX license identifier. Having to look at 
a random LICENSE file in the tree to figure this out is not contributor 
friendly. There should be a text in the RTEMS Software Engineering 
manual about how to work with Apache 2.0 files in RTEMS.


First of all, the Apache 2.0 files comes from STM32CubeH7 project and in 
majority of cases (if not all!) they should not be edited in RTEMS. 
That's also the reason why I have not modified them and added any SPDX 
license identifier into them. They should be left intact and in future 
just replaced with another version of the files as provided by STMicro.


So they definitely do not need to be contributor friendly. Any 
contributor to those files should contribute to upstream project(s) 
which are well listed in provided LICENSE file.


The LICENSE file itself is provided since the comment on any of HAL 
files points to it by:


  * This software is licensed under terms that can be found in the 
LICENSE file

  * in the root directory of this software component.

so there was a need to provide such file.

Hope that clears the intention behind this.

Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Apache License 2.0 all right for BSP code?

[Sebastian Huber]

On 10/03/2022 16:20, Sebastian Huber wrote:

On 10/03/2022 15:13, Joel Sherrill wrote:



On Thu, Mar 10, 2022 at 7:44 AM Karel Gardas  
wrote:


    On 3/10/22 13:36, Sebastian Huber wrote:
 > Hello,
 >
 > I am about to integrate the BSP update contained in this branch:
 >
 > https://github.com/kgardas/rtems/tree/stm32h7-hal-update

 >
 > It contains code from STMicroelectronics licensed under Apache
    License
 > 2.0. Is this license acceptable for RTEMS integration?
 >

    Ah, I see, this was already discussed (to OK) but only on discord and
    I've not udpated #4580 accordingly. So let's wait for clear
    confirmation
    then.


I think it's ok.

https://www.apache.org/licenses/LICENSE-2.0 



There was some discussion (or confusion) long ago that it required you to
keep a track of which changes to that source were by who. I don't see 
that

in the license at all. IMO it's just another variant on MIT/BSD with more
detail.


It gives you a patent grant for the work.

For source code redistribution it contains this condition:

"(b) You must cause any modified files to carry prominent notices 
stating that You changed the files;"


This means everyone changing the files need to pay attention to this.


If the Apache 2.0 files don't have an SPDX license identifier, then I 
think this should be added and a standard text which states that the 
file was modified to add the SPDX license identifier. Having to look at 
a random LICENSE file in the tree to figure this out is not contributor 
friendly. There should be a text in the RTEMS Software Engineering 
manual about how to work with Apache 2.0 files in RTEMS.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Apache License 2.0 all right for BSP code?

[Sebastian Huber]

On 10/03/2022 15:13, Joel Sherrill wrote:



On Thu, Mar 10, 2022 at 7:44 AM Karel Gardas  
wrote:


On 3/10/22 13:36, Sebastian Huber wrote:
 > Hello,
 >
 > I am about to integrate the BSP update contained in this branch:
 >
 > https://github.com/kgardas/rtems/tree/stm32h7-hal-update

 >
 > It contains code from STMicroelectronics licensed under Apache
License
 > 2.0. Is this license acceptable for RTEMS integration?
 >

Ah, I see, this was already discussed (to OK) but only on discord and
I've not udpated #4580 accordingly. So let's wait for clear
confirmation
then.


I think it's ok.

https://www.apache.org/licenses/LICENSE-2.0 



There was some discussion (or confusion) long ago that it required you to
keep a track of which changes to that source were by who. I don't see that
in the license at all. IMO it's just another variant on MIT/BSD with more
detail.


It gives you a patent grant for the work.

For source code redistribution it contains this condition:

"(b) You must cause any modified files to carry prominent notices 
stating that You changed the files;"


This means everyone changing the files need to pay attention to this.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Sebastian Huber]

On 10/03/2022 15:24, Karel Gardas wrote:

On 3/10/22 15:06, Sebastian Huber wrote:

So, the only way out of the chaos was to:

1) replace all HAL files with new files


Yes, this is fine, but if all the new files have now UNIX line endings 
why didn't you change the existing files to UNIX line endings before 
the update? I guess you copied the files from a Git repository. Can't 
you first change the existing files to UNIX line endings and make a 
commit. Then copy the files from your upstream Git repository.


Honestly, I've tried that IIRC, but result was that the diff was still 
not right. I investigated at that time and found out that there were 
file(s) (few) which were using mixed line encoding at that time. E.g. 
someone edited LF file with CRLF editor and then file was using LF + 
CRLF on edited lines. Something like that.


I converted the files to UNIX line endings using:

dos2unix `find -type f `

https://github.com/sebhub/rtems/tree/stm32h7-unix-line-endings

I can't rebase your branch on top if it, however, from the looking at 
the merge conflicts it is clear that the individual files are related.




So the pain of dealing with this mess was so high and unnecessary since 
those were HAL files anyway that I changed the approach to just simply 
replace the files.


Replacing the files is fine, but please copy them on top of the original 
files converted to UNIX line endings. Do you still have a checkout of 
the STM Git repository available to copy the files again?




If you would like to review changes in HAL files, then you may diff 
original merged projects files. They both are on github.com so you can 
investigate either there or on local copy. But this is HAL code, 
something STMicro provided and I don't see any point in dealing with 
that -- unless there is some bug to report...


It is quite likely that this update breaks something and a reviewable 
history could help here. Another option would be to do the updates in 
smaller steps so that a git bisect is more effective.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Karel Gardas]

On 3/10/22 15:06, Sebastian Huber wrote:

So, the only way out of the chaos was to:

1) replace all HAL files with new files


Yes, this is fine, but if all the new files have now UNIX line endings 
why didn't you change the existing files to UNIX line endings before the 
update? I guess you copied the files from a Git repository. Can't you 
first change the existing files to UNIX line endings and make a commit. 
Then copy the files from your upstream Git repository.


Honestly, I've tried that IIRC, but result was that the diff was still 
not right. I investigated at that time and found out that there were 
file(s) (few) which were using mixed line encoding at that time. E.g. 
someone edited LF file with CRLF editor and then file was using LF + 
CRLF on edited lines. Something like that.


So the pain of dealing with this mess was so high and unnecessary since 
those were HAL files anyway that I changed the approach to just simply 
replace the files.


If you would like to review changes in HAL files, then you may diff 
original merged projects files. They both are on github.com so you can 
investigate either there or on local copy. But this is HAL code, 
something STMicro provided and I don't see any point in dealing with 
that -- unless there is some bug to report...


See bsps/arm/stm32h7/LICENSE -- for original source projects locations.

BTW: some information about the mess in merge is also described in 
https://devel.rtems.org/ticket/4580


Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Apache License 2.0 all right for BSP code?

[Joel Sherrill]

On Thu, Mar 10, 2022 at 7:44 AM Karel Gardas 
wrote:

> On 3/10/22 13:36, Sebastian Huber wrote:
> > Hello,
> >
> > I am about to integrate the BSP update contained in this branch:
> >
> > https://github.com/kgardas/rtems/tree/stm32h7-hal-update
> >
> > It contains code from STMicroelectronics licensed under Apache License
> > 2.0. Is this license acceptable for RTEMS integration?
> >
>
> Ah, I see, this was already discussed (to OK) but only on discord and
> I've not udpated #4580 accordingly. So let's wait for clear confirmation
> then.
>

I think it's ok.

https://www.apache.org/licenses/LICENSE-2.0

There was some discussion (or confusion) long ago that it required you to
keep a track of which changes to that source were by who. I don't see that
in the license at all. IMO it's just another variant on MIT/BSD with more
detail.

--joel

>
> 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: STM32H7 HAL update, merge ready.

[Sebastian Huber]

On 10/03/2022 14:58, Karel Gardas wrote:

On 3/10/22 14:52, Sebastian Huber wrote:

On 10/03/2022 14:49, Karel Gardas wrote:

On 3/10/22 14:45, Sebastian Huber wrote:

On 10/03/2022 14:41, Karel Gardas wrote:

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- 
contains all required/recommended by you. Please recheck and 
merge if possible.


Is there a line ending change in the STM code update patches? 
Which line ending have the new files?


New files preserve line endings of original projects which were 
source for HAL code. That is LF. 


The original files were from an archive and not a Git repository. 
Should they be converted first to UNIX line endings before they are 
updated?


Hold on! You don't need to do anything besides the git merge. All 
files needed are there. I already did the HAL code update! All files 
are as provided in original projects besides few changes and besides 
reapplied patches from the past. At least that was whole point of the 
work...


The problem is that for example

https://github.com/kgardas/rtems/commit/d45f034fc379bcb8fecdecc1cb44bd851d6c4949 



changes the line endings from DOS to UNIX AND performs the update. 
This should be two commits. First the change to UNIX line endings and 
then the update.


Yes, but the problem was that original files were too chaotic to do 
anything about it -- in fact HAL files were using mixed line endings.


So, the only way out of the chaos was to:

1) replace all HAL files with new files


Yes, this is fine, but if all the new files have now UNIX line endings 
why didn't you change the existing files to UNIX line endings before the 
update? I guess you copied the files from a Git repository. Can't you 
first change the existing files to UNIX line endings and make a commit. 
Then copy the files from your upstream Git repository.




2) reapply patches done by RTEMS community over HAL files

I did exactly this. So now, you have new HAL + patches on top of that.


This is fine except that the update commits do two steps in one.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] added malloc usable size and test

[zack leung]

Ping

Il ven 4 mar 2022, 21:58 zack leung  ha scritto:

> closes #4503
> ---
>  cpukit/include/rtems/libcsupport.h|  5 +++
>  cpukit/libcsupport/src/mallocusablesize.c | 48 +++
>  spec/build/cpukit/librtemscpu.yml |  1 +
>  testsuites/libtests/malloctest/init.c | 15 ++-
>  4 files changed, 68 insertions(+), 1 deletion(-)
>  create mode 100644 cpukit/libcsupport/src/mallocusablesize.c
>
> diff --git a/cpukit/include/rtems/libcsupport.h
> b/cpukit/include/rtems/libcsupport.h
> index f4be4cfc9a..5110ab0fbe 100644
> --- a/cpukit/include/rtems/libcsupport.h
> +++ b/cpukit/include/rtems/libcsupport.h
> @@ -74,6 +74,11 @@ extern size_t malloc_free_space(void);
>   */
>  extern int malloc_info(Heap_Information_block *the_info);
>
> +/**
> + * @brief Find the usable size of the block of memory .
> + */
> +extern size_t malloc_usable_size(void *ptr);
> +
>  /*
>   *  Prototypes required to install newlib reentrancy user extension
>   */
> diff --git a/cpukit/libcsupport/src/mallocusablesize.c
> b/cpukit/libcsupport/src/mallocusablesize.c
> new file mode 100644
> index 00..b7e573023a
> --- /dev/null
> +++ b/cpukit/libcsupport/src/mallocusablesize.c
> @@ -0,0 +1,48 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + *  Copyright (C) 2022 zacchaeus leung
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +size_t malloc_usable_size( void *ptr ) {
> +
> +  Heap_Control *heap_ptr ;
> +  size_t size;
> +  if ( ptr == NULL ) {
> +return 0;
> +  }
> +
> +  heap_ptr = malloc_get_heap_pointer();
> +  _Heap_Size_of_alloc_area( heap_ptr, ptr,  );
> +
> +  return size;
> +}
> diff --git a/spec/build/cpukit/librtemscpu.yml
> b/spec/build/cpukit/librtemscpu.yml
> index c224937348..2ef11e7e2d 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -670,6 +670,7 @@ source:
>  - cpukit/libcsupport/src/lseek.c
>  - cpukit/libcsupport/src/lstat.c
>  - cpukit/libcsupport/src/malloc.c
> +- cpukit/libcsupport/src/mallocusablesize.c
>  - cpukit/libcsupport/src/malloc_deferred.c
>  - cpukit/libcsupport/src/malloc_dirtier.c
>  - cpukit/libcsupport/src/malloc_walk.c
> diff --git a/testsuites/libtests/malloctest/init.c
> b/testsuites/libtests/malloctest/init.c
> index a33764177d..871edb540e 100644
> --- a/testsuites/libtests/malloctest/init.c
> +++ b/testsuites/libtests/malloctest/init.c
> @@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
>rtems_test_assert( p == NULL );
>rtems_test_assert( errno == -1 );
>  }
> +static void test_usablesize(void)
> +{
> +  int * a = malloc(sizeof( int )*100);
> +  int alloc_size=sizeof( int ) *100 ;
> +  rtems_test_assert( malloc_usable_size( a ) <= alloc_size +
> CPU_HEAP_ALIGNMENT );
> +  free(a);
> +
> +  char * b = malloc(sizeof ( char ) 100);
> +  int alloc_size 2= sizeof ( char ) *100 ;
> +  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 +
> CPU_HEAP_ALIGNMENT);
> +  free( b );
> +}
>
>  rtems_task Init(
>rtems_task_argument argument
> @@ -1405,6 +1417,7 @@ rtems_task Init(
>test_protected_heap_info();
>test_rtems_heap_allocate_aligned_with_boundary();
>test_rtems_malloc();
> +  test_usablesize();
>test_rtems_calloc();
>test_greedy_allocate();
>test_alloc_zero_size();
> @@ -1524,4 +1537,4 @@ RTEMS_SYSINIT_ITEM(
>test_early_malloc,
>RTEMS_SYSINIT_INITIAL_EXTENSIONS,
>RTEMS_SYSINIT_ORDER_FIRST
> -);
> +);
> \ No newline at end of file
> --
> 2.35.1
>
___
devel mailing 

Re: STM32H7 HAL update, merge ready.

[Karel Gardas]

On 3/10/22 14:52, Sebastian Huber wrote:

On 10/03/2022 14:49, Karel Gardas wrote:

On 3/10/22 14:45, Sebastian Huber wrote:

On 10/03/2022 14:41, Karel Gardas wrote:

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- 
contains all required/recommended by you. Please recheck and merge 
if possible.


Is there a line ending change in the STM code update patches? Which 
line ending have the new files?


New files preserve line endings of original projects which were 
source for HAL code. That is LF. 


The original files were from an archive and not a Git repository. 
Should they be converted first to UNIX line endings before they are 
updated?


Hold on! You don't need to do anything besides the git merge. All 
files needed are there. I already did the HAL code update! All files 
are as provided in original projects besides few changes and besides 
reapplied patches from the past. At least that was whole point of the 
work...


The problem is that for example

https://github.com/kgardas/rtems/commit/d45f034fc379bcb8fecdecc1cb44bd851d6c4949 



changes the line endings from DOS to UNIX AND performs the update. This 
should be two commits. First the change to UNIX line endings and then 
the update.


Yes, but the problem was that original files were too chaotic to do 
anything about it -- in fact HAL files were using mixed line endings.


So, the only way out of the chaos was to:

1) replace all HAL files with new files

2) reapply patches done by RTEMS community over HAL files

I did exactly this. So now, you have new HAL + patches on top of that.

The only missing patch which were not merged in is doxygen tag patch 
(IIRC you were the author). But due to HAL changes I've found out it 
would still be incomplete anyway, so I removed it from the process.


Is it a bit more clear now?

Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up

[Christian MAUDERER]

Hello Heinz,

thanks for reporting and analyzing it. And sorry for pushing a patch 
that broke it in the first place.


I was just looking through the error messages whether there is a second 
error. I'll push a patch for the closing comment in the next few minutes.


Best regards

Christian

Am 10.03.22 um 14:50 schrieb Heinz Junkes:

Only the comment end ( */ ) is missing
in bsps/include/libchip/disp_hcms29xx.h
at line 14.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.




On 10. Mar 2022, at 14:39, Heinz Junkes  wrote:

I get this at the moment when compiling the kernel:

...
[  48/4243] Compiling bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
[  49/4243] Compiling bsps/shared/irq/irq-shell.c
[  50/4243] Compiling bsps/shared/irq/irq-info.c
In file included from ../../../bsps/shared/dev/display/disp_hcms29xx.c:24:
../../../bsps/include/libchip/disp_hcms29xx.h:26:40: warning: "/*" within 
comment [-Wcomment]
   26 | rtems_device_minor_number minor;   /* minor device number   
 */
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Sebastian Huber]

On 10/03/2022 14:49, Karel Gardas wrote:

On 3/10/22 14:45, Sebastian Huber wrote:

On 10/03/2022 14:41, Karel Gardas wrote:

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- 
contains all required/recommended by you. Please recheck and merge 
if possible.


Is there a line ending change in the STM code update patches? Which 
line ending have the new files?


New files preserve line endings of original projects which were 
source for HAL code. That is LF. 


The original files were from an archive and not a Git repository. 
Should they be converted first to UNIX line endings before they are 
updated?


Hold on! You don't need to do anything besides the git merge. All files 
needed are there. I already did the HAL code update! All files are as 
provided in original projects besides few changes and besides reapplied 
patches from the past. At least that was whole point of the work...


The problem is that for example

https://github.com/kgardas/rtems/commit/d45f034fc379bcb8fecdecc1cb44bd851d6c4949

changes the line endings from DOS to UNIX AND performs the update. This 
should be two commits. First the change to UNIX line endings and then 
the update.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up

[Heinz Junkes]

Only the comment end ( */ ) is missing
in bsps/include/libchip/disp_hcms29xx.h
at line 14.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 10. Mar 2022, at 14:39, Heinz Junkes  wrote:
> 
> I get this at the moment when compiling the kernel:
> 
> ...
> [  48/4243] Compiling 
> bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
> [  49/4243] Compiling bsps/shared/irq/irq-shell.c
> [  50/4243] Compiling bsps/shared/irq/irq-info.c
> In file included from ../../../bsps/shared/dev/display/disp_hcms29xx.c:24:
> ../../../bsps/include/libchip/disp_hcms29xx.h:26:40: warning: "/*" within 
> comment [-Wcomment]
>   26 | rtems_device_minor_number minor;   /* minor device number  
>   */
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Karel Gardas]

On 3/10/22 14:45, Sebastian Huber wrote:

On 10/03/2022 14:41, Karel Gardas wrote:

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains 
all required/recommended by you. Please recheck and merge if possible.


Is there a line ending change in the STM code update patches? Which 
line ending have the new files?


New files preserve line endings of original projects which were source 
for HAL code. That is LF. 


The original files were from an archive and not a Git repository. Should 
they be converted first to UNIX line endings before they are updated?


Hold on! You don't need to do anything besides the git merge. All files 
needed are there. I already did the HAL code update! All files are as 
provided in original projects besides few changes and besides reapplied 
patches from the past. At least that was whole point of the work...


Thanks,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] smp: Add fatal error

[Sebastian Huber]

Add SMP-specifc SMP_FATAL_MULTITASKING_START_ON_NOT_ONLINE_PROCESSOR
fatal error.  This fatal error helps to diagnose a broken SMP startup
sequence.  Without this error a context switch using the NULL pointer
for the thread control block happens which may be difficult to debug.
---
 cpukit/include/rtems/score/smpimpl.h  |   3 +-
 cpukit/score/src/smp.c|   5 +
 .../fatal-start-on-not-online-processor.yml   |  21 +++
 spec/build/testsuites/validation/grp.yml  |   2 +
 .../tr-fatal-start-on-not-online-processor.c  | 167 ++
 .../tr-fatal-start-on-not-online-processor.h  |  84 +
 .../ts-fatal-start-on-not-online-processor.c  |  82 +
 7 files changed, 363 insertions(+), 1 deletion(-)
 create mode 100644 
spec/build/testsuites/validation/fatal-start-on-not-online-processor.yml
 create mode 100644 
testsuites/validation/tr-fatal-start-on-not-online-processor.c
 create mode 100644 
testsuites/validation/tr-fatal-start-on-not-online-processor.h
 create mode 100644 
testsuites/validation/ts-fatal-start-on-not-online-processor.c

diff --git a/cpukit/include/rtems/score/smpimpl.h 
b/cpukit/include/rtems/score/smpimpl.h
index e67c0953e6..8e965968a1 100644
--- a/cpukit/include/rtems/score/smpimpl.h
+++ b/cpukit/include/rtems/score/smpimpl.h
@@ -92,7 +92,8 @@ typedef enum {
   SMP_FATAL_START_OF_MANDATORY_PROCESSOR_FAILED,
   SMP_FATAL_SCHEDULER_PIN_OR_UNPIN_NOT_SUPPORTED,
   SMP_FATAL_WRONG_CPU_STATE_TO_PERFORM_JOBS,
-  SMP_FATAL_SCHEDULER_REQUIRES_EXACTLY_ONE_PROCESSOR
+  SMP_FATAL_SCHEDULER_REQUIRES_EXACTLY_ONE_PROCESSOR,
+  SMP_FATAL_MULTITASKING_START_ON_NOT_ONLINE_PROCESSOR
 } SMP_Fatal_code;
 
 /**
diff --git a/cpukit/score/src/smp.c b/cpukit/score/src/smp.c
index 0dc8830c46..7c068f3c51 100644
--- a/cpukit/score/src/smp.c
+++ b/cpukit/score/src/smp.c
@@ -269,6 +269,11 @@ void _SMP_Start_multitasking_on_secondary_processor(
 
   _Per_CPU_Set_state( cpu_self, PER_CPU_STATE_READY_TO_START_MULTITASKING );
   _SMP_Wait_for_start_multitasking( cpu_self );
+
+  if ( !_Per_CPU_Is_processor_online( cpu_self ) ) {
+_SMP_Fatal( SMP_FATAL_MULTITASKING_START_ON_NOT_ONLINE_PROCESSOR );
+  }
+
   _Thread_Start_multitasking();
 }
 
diff --git 
a/spec/build/testsuites/validation/fatal-start-on-not-online-processor.yml 
b/spec/build/testsuites/validation/fatal-start-on-not-online-processor.yml
new file mode 100644
index 00..7858041843
--- /dev/null
+++ b/spec/build/testsuites/validation/fatal-start-on-not-online-processor.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: RTEMS_SMP
+features: c cprogram
+includes: []
+ldflags:
+- -Wl,-wrap=_CPU_SMP_Start_processor
+links: []
+source:
+- testsuites/validation/tr-fatal-start-on-not-online-processor.c
+- testsuites/validation/ts-fatal-start-on-not-online-processor.c
+stlib: []
+target: testsuites/validation/ts-fatal-start-on-not-online-processor.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/validation/grp.yml 
b/spec/build/testsuites/validation/grp.yml
index c26d5ac9e7..c1ccd4c697 100644
--- a/spec/build/testsuites/validation/grp.yml
+++ b/spec/build/testsuites/validation/grp.yml
@@ -38,6 +38,8 @@ links:
   uid: fatal-smp
 - role: build-dependency
   uid: fatal-start-of-mandatory-processor-failed
+- role: build-dependency
+  uid: fatal-start-on-not-online-processor
 - role: build-dependency
   uid: fatal-too-large-tls-size
 - role: build-dependency
diff --git a/testsuites/validation/tr-fatal-start-on-not-online-processor.c 
b/testsuites/validation/tr-fatal-start-on-not-online-processor.c
new file mode 100644
index 00..55081bc25d
--- /dev/null
+++ b/testsuites/validation/tr-fatal-start-on-not-online-processor.c
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseScoreSmpValFatalStartOnNotOnlineProcessor
+ */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * 

Re: STM32H7 HAL update, merge ready.

[Sebastian Huber]

On 10/03/2022 14:41, Karel Gardas wrote:

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains 
all required/recommended by you. Please recheck and merge if possible.


Is there a line ending change in the STM code update patches? Which 
line ending have the new files?


New files preserve line endings of original projects which were source 
for HAL code. That is LF. 


The original files were from an archive and not a Git repository. Should 
they be converted first to UNIX line endings before they are updated?


There are only few files with crlf and those 
are onlyfiles produced by you/embedded brains. You can use ls-files 
--eol command to verify:


$ git ls-files --eol|grep crlf
i/crlf  w/crlf  attr/   include/stm32h7xx_hal_conf.h
i/crlf  w/crlf  attr/   start/ext-mem-ctl.c
i/crlf  w/crlf  attr/   start/system_stm32h7xx.c

So, we're nearly CRLF free now. Please keep it that way if possible.


Yes, it is good that they are now with UNIX line endings.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Apache License 2.0 all right for BSP code?

[Karel Gardas]

On 3/10/22 13:36, Sebastian Huber wrote:

Hello,

I am about to integrate the BSP update contained in this branch:

https://github.com/kgardas/rtems/tree/stm32h7-hal-update

It contains code from STMicroelectronics licensed under Apache License 
2.0. Is this license acceptable for RTEMS integration?




Ah, I see, this was already discussed (to OK) but only on discord and 
I've not udpated #4580 accordingly. So let's wait for clear confirmation 
then.


Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Karel Gardas]

On 3/10/22 13:42, Sebastian Huber wrote:

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains 
all required/recommended by you. Please recheck and merge if possible.


Is there a line ending change in the STM code update patches? Which line 
ending have the new files?


New files preserve line endings of original projects which were source 
for HAL code. That is LF. There are only few files with crlf and those 
are onlyfiles produced by you/embedded brains. You can use ls-files 
--eol command to verify:


$ git ls-files --eol|grep crlf
i/crlf  w/crlf  attr/   include/stm32h7xx_hal_conf.h
i/crlf  w/crlf  attr/   start/ext-mem-ctl.c
i/crlf  w/crlf  attr/   start/system_stm32h7xx.c

So, we're nearly CRLF free now. Please keep it that way if possible.

Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up

[Heinz Junkes]

I get this at the moment when compiling the kernel:

...
[  48/4243] Compiling bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c
[  49/4243] Compiling bsps/shared/irq/irq-shell.c
[  50/4243] Compiling bsps/shared/irq/irq-info.c
In file included from ../../../bsps/shared/dev/display/disp_hcms29xx.c:24:
../../../bsps/include/libchip/disp_hcms29xx.h:26:40: warning: "/*" within 
comment [-Wcomment]
   26 | rtems_device_minor_number minor;   /* minor device number   
 */
  |
../../../bsps/include/libchip/disp_hcms29xx.h:30:22: error: 
'DISP_HCMS29XX_TEXT_CNT' undeclared here (not in a function)
   30 | char disp_buffer[DISP_HCMS29XX_TEXT_CNT];
  |  ^~
../../../bsps/include/libchip/disp_hcms29xx.h:45:3: error: expected identifier 
or '(' before '}' token
   45 |   } spi_disp_hcms29xx_param_t;
  |   ^
../../../bsps/include/libchip/disp_hcms29xx.h:45:5: warning: data definition 
has no type or storage class
   45 |   } spi_disp_hcms29xx_param_t;
  | ^
../../../bsps/include/libchip/disp_hcms29xx.h:45:5: warning: type defaults to 
'int' in declaration of 'spi_disp_hcms29xx_param_t' [-Wimplicit-int]
../../../bsps/include/libchip/disp_hcms29xx.h:49:5: error: expected 
specifier-qualifier-list before 'spi_disp_hcms29xx_param_t'
   49 | spi_disp_hcms29xx_param_t disp_param;
  | ^
../../../bsps/include/libchip/disp_hcms29xx.h:150:2: error: #endif without #if
  150 | #endif /* _DISP_HCMS29XX_H */
  |  ^
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_send_to_display':
../../../bsps/shared/dev/display/disp_hcms29xx.c:332:43: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  332 | rc = rtems_libi2c_send_start(softc_ptr->disp_param.minor);
  |   ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:338:39: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  338 | rc = -rtems_libi2c_ioctl(softc_ptr->disp_param.minor,
  |   ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:347:42: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  347 | rc = rtems_libi2c_send_addr(softc_ptr->disp_param.minor,true);
  |  ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:355:16: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  355 |   softc_ptr->disp_param.rotate
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:385:46: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  385 |  ret_cnt = rtems_libi2c_write_bytes(softc_ptr->disp_param.minor,
  |  ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:397:42: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  397 | rc = rtems_libi2c_send_stop(softc_ptr->disp_param.minor);
  |  ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_send_to_control':
../../../bsps/shared/dev/display/disp_hcms29xx.c:453:40: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  453 |  rc = rtems_libi2c_send_start(softc_ptr->disp_param.minor);
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:459:36: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  459 |  rc = -rtems_libi2c_ioctl(softc_ptr->disp_param.minor,
  |^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:468:39: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  468 |  rc = rtems_libi2c_send_addr(softc_ptr->disp_param.minor,true);
  |   ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:475:46: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  475 |  ret_cnt = rtems_libi2c_write_bytes(softc_ptr->disp_param.minor,
  |  ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c:488:42: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  488 | rc = rtems_libi2c_send_stop(softc_ptr->disp_param.minor);
  |  ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_timer_sr':
../../../bsps/shared/dev/display/disp_hcms29xx.c:515:29: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  515 |   rtems_event_send(softc_ptr->disp_param.task_id, 
DISP_HCMS29XX_EVENT_TIMER);
  | ^~
../../../bsps/shared/dev/display/disp_hcms29xx.c: In function 
'disp_hcms29xx_update_task':
../../../bsps/shared/dev/display/disp_hcms29xx.c:584:39: error: 
'disp_hcms29xx_drv_t' has no member named 'disp_param'
  584 |  rc = rtems_semaphore_obtain(softc_ptr->disp_param.trns_sema_id,
  |   

Re: New validation test suites

[Sebastian Huber]

On 10/03/2022 09:42, Chris Johns wrote:

On 10/3/2022 7:19 pm, Sebastian Huber wrote:

Hello Chris,

On 23/02/2022 10:17, Sebastian Huber wrote:

I added a --diff option to the spec2modules.py script in rtems-central.git.
You can now unpack a release archive of rtems-central.git and then do the
following:

1. Unpack the RTEMS release archive to "modules/rtems".

2. Unpack the RTEMS documentation source release archive to 
"modules/rtems-docs".

3. Run "./spec2modules.py --diff".  This command will output the differences
between the specification point of view of the sources and the actual sources
(or nothing).

is there something left which prevents an integration of the new validation 
tests?


No, the tests are ok to be committed.

If anything shows up in further testing and when a release is created we can
address it then.

That you for this, your patience and understanding.


Thanks for the review. I will integrate it once the powerpc issues with 
GCC 10 are fixed. Currently, the virtex4 and virtex5 BSPs don't build.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: STM32H7 HAL update, merge ready.

[Sebastian Huber]

On 10/03/2022 13:18, Karel Gardas wrote:


Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains all 
required/recommended by you. Please recheck and merge if possible.


Is there a line ending change in the STM code update patches? Which line 
ending have the new files?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Apache License 2.0 all right for BSP code?

[Sebastian Huber]

Hello,

I am about to integrate the BSP update contained in this branch:

https://github.com/kgardas/rtems/tree/stm32h7-hal-update

It contains code from STMicroelectronics licensed under Apache License 
2.0. Is this license acceptable for RTEMS integration?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

STM32H7 HAL update, merge ready.

[Karel Gardas]

Hello Sebastian,

https://github.com/kgardas/rtems/tree/stm32h7-hal-update -- contains all 
required/recommended by you. Please recheck and merge if possible.


Thanks!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 10/3/2022 7:19 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 23/02/2022 10:17, Sebastian Huber wrote:
>>
>> I added a --diff option to the spec2modules.py script in rtems-central.git.
>> You can now unpack a release archive of rtems-central.git and then do the
>> following:
>>
>> 1. Unpack the RTEMS release archive to "modules/rtems".
>>
>> 2. Unpack the RTEMS documentation source release archive to 
>> "modules/rtems-docs".
>>
>> 3. Run "./spec2modules.py --diff".  This command will output the differences
>> between the specification point of view of the sources and the actual sources
>> (or nothing).
> 
> is there something left which prevents an integration of the new validation 
> tests?
> 

No, the tests are ok to be committed.

If anything shows up in further testing and when a release is created we can
address it then.

That you for this, your patience and understanding.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 01/40] License Header Clean Up

[Christian MAUDERER]

I pushed the patches.

Am 07.03.22 um 15:33 schrieb Joel Sherrill:


On Mon, Mar 7, 2022 at 7:25 AM Christian Mauderer 
> wrote:


Hello,

during the re-license efforts, Joel noted that there are a lot of really
odd old headers from people at embedded brains. We joined efforts to
clean them up. After this patch series, we should have removed most of
these odd headers.


To pile on that statement -- there should be NO changes to code -- only
file headers.


Please don't hesitate to point out any mistakes that I did during the
clean up. It was a repetitive task and therefore is definitively prone
to errors.


I manually cleaned up some files but most of my changes were driven
by scripts and also may be subject to mistakes.


In case some file doesn't reach the list: I also pushed the patches on a
branch on gitlab:

https://gitlab.com/c-mauderer/rtems/-/tree/cm/20220302_file_header_clean_up




I reviewed this and am ok with pushing it but it would be nice to hear
from others.  This touched a lot of files.

--joel



Best regards

Christian



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Sebastian Huber]

Hello Chris,

On 23/02/2022 10:17, Sebastian Huber wrote:


I added a --diff option to the spec2modules.py script in 
rtems-central.git. You can now unpack a release archive of 
rtems-central.git and then do the following:


1. Unpack the RTEMS release archive to "modules/rtems".

2. Unpack the RTEMS documentation source release archive to 
"modules/rtems-docs".


3. Run "./spec2modules.py --diff".  This command will output the 
differences between the specification point of view of the sources and 
the actual sources (or nothing).


is there something left which prevents an integration of the new 
validation tests?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel