Re: [PATCH v1] Explanations.cc: Convert to c++ file handling

[Chris Johns]

Ok

On 5/6/21 4:17 am, Ryan Long wrote:
> ---
>  tester/covoar/Explanations.cc | 45 
> ---
>  1 file changed, 17 insertions(+), 28 deletions(-)
> 
> diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc
> index d94cd2e..1449fb2 100644
> --- a/tester/covoar/Explanations.cc
> +++ b/tester/covoar/Explanations.cc
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include 
>  
>  #include "Explanations.h"
> @@ -30,15 +32,14 @@ namespace Coverage {
>)
>{
>  #define MAX_LINE_LENGTH 512
> -FILE   *explain;
> -char*cStatus;
> -Explanation  e;
> -int  line = 1;
> +std::ifstream  explain;
> +Explanatione;
> +intline = 1;
>  
>  if (!explanations)
>return;
>  
> -explain = ::fopen( explanations, "r" );
> +explain.open( explanations );
>  if (!explain) {
>std::ostringstream what;
>what << "Unable to open " << explanations;
> @@ -50,9 +51,9 @@ namespace Coverage {
>// skip blank lines between
>do {
>  inputBuffer[0] = '\0';
> -cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
> -if (cStatus == NULL) {
> -  goto done;
> +explain.getline( inputBuffer, MAX_LINE_LENGTH );
> +if (explain.fail()) {
> +  return;
>  }
>  inputBuffer[ strlen(inputBuffer) - 1] = '\0';
>  line++;
> @@ -64,7 +65,6 @@ namespace Coverage {
>  what << "line " << line
>   << "contains a duplicate explanation ("
>   << inputBuffer << ")";
> -fclose( explain );
>  throw rld::error( what, "Explanations::load" );
>}
>  
> @@ -73,12 +73,11 @@ namespace Coverage {
>e.found = false;
>  
>// Get the classification
> -  cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
> -  if (cStatus == NULL) {
> +  explain.getline( inputBuffer, MAX_LINE_LENGTH );
> +  if (explain.fail()) {
>  std::ostringstream what;
>  what << "line " << line
>   << "out of sync at the classification";
> -fclose( explain );
>  throw rld::error( what, "Explanations::load" );
>}
>inputBuffer[ strlen(inputBuffer) - 1] = '\0';
> @@ -87,13 +86,12 @@ namespace Coverage {
>  
>// Get the explanation
>while (1) {
> -cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
> +explain.getline( inputBuffer, MAX_LINE_LENGTH );
>  // fprintf( stderr, "%d - %s\n", line, inputBuffer );
> -if (cStatus == NULL) {
> +if (explain.fail()) {
>std::ostringstream what;
>what << "line " << line
> << "out of sync at the explanation";
> -  fclose( explain );
>throw rld::error( what, "Explanations::load" );
>  }
>  inputBuffer[ strlen(inputBuffer) - 1] = '\0';
> @@ -110,10 +108,6 @@ namespace Coverage {
>// Add this to the set of Explanations
>set[ e.startingPoint ] = e;
>  }
> -done:
> -;
> -
> -fclose( explain );
>  
>  #undef MAX_LINE_LENGTH
>}
> @@ -137,14 +131,14 @@ done:
>  const char* const fileName
>)
>{
> -FILE* notFoundFile;
> +std::ofstream notFoundFile;
>  bool  notFoundOccurred = false;
>  
>  if (!fileName)
>return;
>  
> -notFoundFile = fopen( fileName, "w" );
> -if (notFoundFile == nullptr) {
> +notFoundFile.open( fileName );
> +if (!notFoundFile) {
>std::ostringstream what;
>what << "Unable to open " << fileName
> << " out of sync at the explanation";
> @@ -159,14 +153,9 @@ done:
>  
>if (!e.found) {
>  notFoundOccurred = true;
> -fprintf(
> -  notFoundFile,
> -  "%s\n",
> -  e.startingPoint.c_str()
> -);
> +notFoundFile << e.startingPoint << std::endl;
>}
>  }
> -fclose( notFoundFile );
>  
>  if (!notFoundOccurred) {
>if (!unlink( fileName )) {
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 1/6] Explanations.cc: Fix resource leaks

[Chris Johns]

On 5/6/21 2:47 am, Ryan Long wrote:
> We'll submit the C++ conversions as separate patches since they are larger. 
> That patch will be submitted shortly.

Excellent and thanks.

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

Re: [PATCH] cpukit/libblock/src: Add better memory handling in flashdisk.c

[Chris Johns]

On 5/6/21 8:11 am, Gedare Bloom wrote:
> On Fri, Jun 4, 2021 at 1:17 PM Joel Sherrill  wrote:
>>
>> On the surface, this looks OK to me. But I remember looking at this one
>> and wondering if there was any cleanup required because of the various
>> subroutine calls as you work down through this method.
>>
>> Did you look into each of the subroutines called and make sure they
>> didn't do further allocations?
>>
> We hadn't. Now, we took a closer look at this also, and see some more
> problems that need to be addressed. The fd variable is a loop
> iterator, so we can't just free() it. Should this function cleanup
> everything that was attempted and not to return with a partial
> initialization in case of a failure? Or, should it allow the partial
> initialization of some of the fd's, and just cleanup the last one that
> fails (due to out of memory)?

I think there is one that pops up on a regular basis where you cannot delete
things because they are registered with something that has not unregister.

I am not sure this is the case. It might pay to check before pushing.

> 
> 
>> --joel
>>
>> On Fri, Jun 4, 2021 at 1:27 PM Harrison Edward Gerber  
>> wrote:
>>>
>>> See also CID 1439298
>>>
>>> Closes #3570
>>> ---
>>>  cpukit/libblock/src/flashdisk.c | 16 
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/cpukit/libblock/src/flashdisk.c 
>>> b/cpukit/libblock/src/flashdisk.c
>>> index 91f99e0d52..4de6ecd807 100644
>>> --- a/cpukit/libblock/src/flashdisk.c
>>> +++ b/cpukit/libblock/src/flashdisk.c
>>> @@ -2486,17 +2486,29 @@ rtems_fdisk_initialize (rtems_device_major_number 
>>> major,
>>>   */
>>>  fd->copy_buffer = malloc (c->block_size);
>>>  if (!fd->copy_buffer)
>>> +{
>>> +  free(fd);

Missing space to be consistent? More of these below.

Chris

>>>return RTEMS_NO_MEMORY;
>>> +}
>>>
>>>  fd->blocks = calloc (blocks, sizeof (rtems_fdisk_block_ctl));
>>>  if (!fd->blocks)
>>> +{
>>> +  free(fd->copy_buffer);
>>> +  free(fd);
>>>return RTEMS_NO_MEMORY;
>>> +}
>>>
>>>  fd->block_count = blocks;
>>>
>>>  fd->devices = calloc (c->device_count, sizeof 
>>> (rtems_fdisk_device_ctl));
>>>  if (!fd->devices)
>>> +{
>>> +  free(fd->blocks);
>>> +  free(fd->copy_buffer);
>>> +  free(fd);
>>>return RTEMS_NO_MEMORY;
>>> +}
>>>
>>>  rtems_mutex_init (>lock, "Flash Disk");
>>>
>>> @@ -2508,6 +2520,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>>> major,
>>>free (fd->copy_buffer);
>>>free (fd->blocks);
>>>free (fd->devices);
>>> +  free(fd);
>>>rtems_fdisk_error ("disk create phy failed");
>>>return sc;
>>>  }
>>> @@ -2529,6 +2542,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>>> major,
>>>  free (fd->copy_buffer);
>>>  free (fd->blocks);
>>>  free (fd->devices);
>>> +free(fd);
>>>  return RTEMS_NO_MEMORY;
>>>}
>>>
>>> @@ -2564,6 +2578,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>>> major,
>>>free (fd->copy_buffer);
>>>free (fd->blocks);
>>>free (fd->devices);
>>> +  free(fd);
>>>rtems_fdisk_error ("recovery of disk failed: %s (%d)",
>>>   strerror (ret), ret);
>>>return ret;
>>> @@ -2577,6 +2592,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>>> major,
>>>free (fd->copy_buffer);
>>>free (fd->blocks);
>>>free (fd->devices);
>>> +  free(fd);
>>>rtems_fdisk_error ("compacting of disk failed: %s (%d)",
>>>   strerror (ret), ret);
>>>return ret;
>>> --
>>> 2.25.1
>>>
>>> ___
>>> 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
> ___
> 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] cpukit/libblock/src: Add better memory handling in flashdisk.c

[Gedare Bloom]

On Fri, Jun 4, 2021 at 1:17 PM Joel Sherrill  wrote:
>
> On the surface, this looks OK to me. But I remember looking at this one
> and wondering if there was any cleanup required because of the various
> subroutine calls as you work down through this method.
>
> Did you look into each of the subroutines called and make sure they
> didn't do further allocations?
>
We hadn't. Now, we took a closer look at this also, and see some more
problems that need to be addressed. The fd variable is a loop
iterator, so we can't just free() it. Should this function cleanup
everything that was attempted and not to return with a partial
initialization in case of a failure? Or, should it allow the partial
initialization of some of the fd's, and just cleanup the last one that
fails (due to out of memory)?


> --joel
>
> On Fri, Jun 4, 2021 at 1:27 PM Harrison Edward Gerber  
> wrote:
>>
>> See also CID 1439298
>>
>> Closes #3570
>> ---
>>  cpukit/libblock/src/flashdisk.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/cpukit/libblock/src/flashdisk.c 
>> b/cpukit/libblock/src/flashdisk.c
>> index 91f99e0d52..4de6ecd807 100644
>> --- a/cpukit/libblock/src/flashdisk.c
>> +++ b/cpukit/libblock/src/flashdisk.c
>> @@ -2486,17 +2486,29 @@ rtems_fdisk_initialize (rtems_device_major_number 
>> major,
>>   */
>>  fd->copy_buffer = malloc (c->block_size);
>>  if (!fd->copy_buffer)
>> +{
>> +  free(fd);
>>return RTEMS_NO_MEMORY;
>> +}
>>
>>  fd->blocks = calloc (blocks, sizeof (rtems_fdisk_block_ctl));
>>  if (!fd->blocks)
>> +{
>> +  free(fd->copy_buffer);
>> +  free(fd);
>>return RTEMS_NO_MEMORY;
>> +}
>>
>>  fd->block_count = blocks;
>>
>>  fd->devices = calloc (c->device_count, sizeof (rtems_fdisk_device_ctl));
>>  if (!fd->devices)
>> +{
>> +  free(fd->blocks);
>> +  free(fd->copy_buffer);
>> +  free(fd);
>>return RTEMS_NO_MEMORY;
>> +}
>>
>>  rtems_mutex_init (>lock, "Flash Disk");
>>
>> @@ -2508,6 +2520,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>> major,
>>free (fd->copy_buffer);
>>free (fd->blocks);
>>free (fd->devices);
>> +  free(fd);
>>rtems_fdisk_error ("disk create phy failed");
>>return sc;
>>  }
>> @@ -2529,6 +2542,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>> major,
>>  free (fd->copy_buffer);
>>  free (fd->blocks);
>>  free (fd->devices);
>> +free(fd);
>>  return RTEMS_NO_MEMORY;
>>}
>>
>> @@ -2564,6 +2578,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>> major,
>>free (fd->copy_buffer);
>>free (fd->blocks);
>>free (fd->devices);
>> +  free(fd);
>>rtems_fdisk_error ("recovery of disk failed: %s (%d)",
>>   strerror (ret), ret);
>>return ret;
>> @@ -2577,6 +2592,7 @@ rtems_fdisk_initialize (rtems_device_major_number 
>> major,
>>free (fd->copy_buffer);
>>free (fd->blocks);
>>free (fd->devices);
>> +  free(fd);
>>rtems_fdisk_error ("compacting of disk failed: %s (%d)",
>>   strerror (ret), ret);
>>return ret;
>> --
>> 2.25.1
>>
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Okay. I will do that.

On Fri, 4 Jun 2021, 10:48 pm Gedare Bloom,  wrote:

> On Fri, Jun 4, 2021 at 2:57 PM Ida Delphine  wrote:
> >
> > Okay, I will take a look.
> >
> > Regarding me asking a question in the appropriate clang-format mailing
> list should it be just regarding the parentheses and braces being aligned?
> >
> That would be the right question to ask, if you can't find a way to
> align the closing parenthesis.
>
> You might also follow-up that old thread related to alignment of the
> pointers.
>
> > On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
> >>>
> >>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine 
> wrote:
> >>> >>
> >>> >> Hello everyone,
> >>> >>
> >>> >> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> >>> >> Below are some example areas in the code you can spot the
> differences:
> >>> >>
> >>> >> In line 68, the ")" at the end of the parameter list needs to be in
> a new row, but this doesn't seem to be supported in clang-format.
> >>> >
> >>> > If I understand correctly, clang-format does not like:
> >>> >
> >>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
> >>> >
> >>> > which has the first parameter on its one line but wants the first
> parameter
> >>> > after the open parenthesis?
> >>> >
> >>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket
> being
> >>> > set to AlwaysBreak
> >>> >
> >>> >>
> >>> >> In line 142, if the function call is split into multiple rows, the
> ");" should always be in a new row.
> >>> >
> >>> > Having the closing parenthesis on its own line may end up being
> something
> >>> > we have to change the RTEMS style on. I do not see an option in their
> >>> > documentation to do this. Unfortunate, since I like the symmetry
> between
> >>> > braces and parentheses.
> >>> >
> >>> >  Could you file an issue with them and/or ask a question the
> appropriate
> >>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
> >>> > we are missing something.
> >>> >>
> >>> >> In line 201-202, we can see that the "*" of the pointers are not
> aligned to the right.
> >>> >
> >>> >
> >>> > This seems to be the issue Gedare mentioned which might have a patch.
> >>> > Follow up on that.
> >>> >
> >>> > But I think we had previously discussed this as a point we may have
> to
> >>> > concede and change RTEMS style on.
> >>> >>
> >>> >> You can check out the formatted file here -
> https://pastebin.com/nDBrSSCP
> >>> >
> >>> >
> >>> > Is it just the website or are blank line differences? It may just be
> an
> >>> > illusion. I think the spacing between the numbered lines is greater
> >>> > than in the git view. Just odd.
> >>> >
> >>> That's just the pastebin having more vertical padding between
> consecutive lines.
> >>
> >>
> >> That's what I thought but it did make the code look funny.
> >>
> >> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or
> only
> >> three in this file?
> >>
> >> Probably should try a few more files and see if there are other
> discrepancies.
> >>
> >> And obviously work on the integration/automation of using the tools. :)
> >>
> >> --joel
> >>
> >>>
> >>>
> >>> > --joel
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom 
> wrote:
> >>> >>>
> >>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
> wrote:
> >>> >>> >
> >>> >>> > Hi Gedare,
> >>> >>> >
> >>> >>> > With regards to your comment on discord on me looking for a tool
> that works on both patches and source files, it turns out clang-format has
> that functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
> >>> >>> >
> >>> >>> > Does it match what you have in mind?
> >>> >>> >
> >>> >>> Yes. I think we would want to not use the `-i` option but instead
> pass
> >>> >>> through and check the changes. I don't think we should rewrite the
> >>> >>> patches themselves, but instead we want to use a tool that can be
> used
> >>> >>> to check and approve the style of submitted patches. You might
> need to
> >>> >>> write a modified version of the clang-format-diff.py to use as a
> >>> >>> "checker" with ability to provide exceptions to the rules.
> >>> >>>
> >>> >>> Gedare
> >>> >>>
> >>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
> wrote:
> >>> >>> >>
> >>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
> wrote:
> >>> >>> >> >
> >>> >>> >> > Hello everyone,
> >>> >>> >> > Still waiting for some feedback :)
> >>> >>> >> >
> >>> >>> >> > Cheers,
> >>> >>> >> > Ida.
> >>> >>> >> >
> >>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
> wrote:
> >>> >>> >> >>
> >>> >>> >> >> Hello everyone,
> >>> >>> >> >> Went through some previous emails and it 

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Fri, Jun 4, 2021 at 2:57 PM Ida Delphine  wrote:
>
> Okay, I will take a look.
>
> Regarding me asking a question in the appropriate clang-format mailing list 
> should it be just regarding the parentheses and braces being aligned?
>
That would be the right question to ask, if you can't find a way to
align the closing parenthesis.

You might also follow-up that old thread related to alignment of the pointers.

> On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
>>>
>>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>>> >>
>>> >> Hello everyone,
>>> >>
>>> >> I applied the configuration Sebastian used and ran clang-format on 
>>> >> cpukit/score/src/threadqenque.c and so far these are the differences I 
>>> >> could notice...
>>> >> Below are some example areas in the code you can spot the differences:
>>> >>
>>> >> In line 68, the ")" at the end of the parameter list needs to be in a 
>>> >> new row, but this doesn't seem to be supported in clang-format.
>>> >
>>> > If I understand correctly, clang-format does not like:
>>> >
>>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>>> >
>>> > which has the first parameter on its one line but wants the first 
>>> > parameter
>>> > after the open parenthesis?
>>> >
>>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
>>> > set to AlwaysBreak
>>> >
>>> >>
>>> >> In line 142, if the function call is split into multiple rows, the ");" 
>>> >> should always be in a new row.
>>> >
>>> > Having the closing parenthesis on its own line may end up being something
>>> > we have to change the RTEMS style on. I do not see an option in their
>>> > documentation to do this. Unfortunate, since I like the symmetry between
>>> > braces and parentheses.
>>> >
>>> >  Could you file an issue with them and/or ask a question the appropriate
>>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
>>> > we are missing something.
>>> >>
>>> >> In line 201-202, we can see that the "*" of the pointers are not aligned 
>>> >> to the right.
>>> >
>>> >
>>> > This seems to be the issue Gedare mentioned which might have a patch.
>>> > Follow up on that.
>>> >
>>> > But I think we had previously discussed this as a point we may have to
>>> > concede and change RTEMS style on.
>>> >>
>>> >> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>>> >
>>> >
>>> > Is it just the website or are blank line differences? It may just be an
>>> > illusion. I think the spacing between the numbered lines is greater
>>> > than in the git view. Just odd.
>>> >
>>> That's just the pastebin having more vertical padding between consecutive 
>>> lines.
>>
>>
>> That's what I thought but it did make the code look funny.
>>
>> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or only
>> three in this file?
>>
>> Probably should try a few more files and see if there are other 
>> discrepancies.
>>
>> And obviously work on the integration/automation of using the tools. :)
>>
>> --joel
>>
>>>
>>>
>>> > --joel
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>>> >>>
>>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>>> >>> >
>>> >>> > Hi Gedare,
>>> >>> >
>>> >>> > With regards to your comment on discord on me looking for a tool that 
>>> >>> > works on both patches and source files, it turns out clang-format has 
>>> >>> > that functionality already. Here's what I found - 
>>> >>> > https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>>> >>> >
>>> >>> > Does it match what you have in mind?
>>> >>> >
>>> >>> Yes. I think we would want to not use the `-i` option but instead pass
>>> >>> through and check the changes. I don't think we should rewrite the
>>> >>> patches themselves, but instead we want to use a tool that can be used
>>> >>> to check and approve the style of submitted patches. You might need to
>>> >>> write a modified version of the clang-format-diff.py to use as a
>>> >>> "checker" with ability to provide exceptions to the rules.
>>> >>>
>>> >>> Gedare
>>> >>>
>>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>>> >>> >>
>>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  
>>> >>> >> wrote:
>>> >>> >> >
>>> >>> >> > Hello everyone,
>>> >>> >> > Still waiting for some feedback :)
>>> >>> >> >
>>> >>> >> > Cheers,
>>> >>> >> > Ida.
>>> >>> >> >
>>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  
>>> >>> >> > wrote:
>>> >>> >> >>
>>> >>> >> >> Hello everyone,
>>> >>> >> >> Went through some previous emails and it turns out Sebastian 
>>> >>> >> >> already came up with a configuration for clang format which works 
>>> >>> >> >> well for RTEMS except for the fact that some configurations 
>>> >>> >> >> haven't been implemented into clang-format yet. Using
>>> >>> >> >>

Re: [PATCH rtems 1/2] cpu/armv7m: Avoid regions with negative size

[Peter Dufault]

Looks good to me.

> On Jun 4, 2021, at 03:47 , Christian Mauderer 
>  wrote:
> 
> Don't initialze regions that have a negative size (for example due to a
> wrong calculation).
> 
> Update #4450
> ---
> cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
> b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> index 8f926e826a..a5eaaef418 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> @@ -656,7 +656,7 @@ static inline void _ARMV7M_MPU_Set_region(
>   RTEMS_OBFUSCATE_VARIABLE(end);
>   size = (uintptr_t) end - (uintptr_t) begin;
> 
> -  if ( size > 0 ) {
> +  if ( (uintptr_t) end > (uintptr_t) begin ) {
> rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
> rasr |= _ARMV7M_MPU_Get_region_size(size);
>   } else {
> --
> 2.26.2
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Ida Delphine]

Okay, I will take a look.

Regarding me asking a question in the appropriate clang-format mailing list
should it be just regarding the parentheses and braces being aligned?

On Fri, Jun 4, 2021 at 8:41 PM Joel Sherrill  wrote:

>
>
> On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:
>
>> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> I applied the configuration Sebastian used and ran clang-format on
>> cpukit/score/src/threadqenque.c and so far these are the differences I
>> could notice...
>> >> Below are some example areas in the code you can spot the differences:
>> >>
>> >> In line 68, the ")" at the end of the parameter list needs to be in a
>> new row, but this doesn't seem to be supported in clang-format.
>> >
>> > If I understand correctly, clang-format does not like:
>> >
>> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>> >
>> > which has the first parameter on its one line but wants the first
>> parameter
>> > after the open parenthesis?
>> >
>> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
>> > set to AlwaysBreak
>> >
>> >>
>> >> In line 142, if the function call is split into multiple rows, the
>> ");" should always be in a new row.
>> >
>> > Having the closing parenthesis on its own line may end up being
>> something
>> > we have to change the RTEMS style on. I do not see an option in their
>> > documentation to do this. Unfortunate, since I like the symmetry between
>> > braces and parentheses.
>> >
>> >  Could you file an issue with them and/or ask a question the appropriate
>> > mailing list? Please cc Gedara and me. Give them an example. Maybe
>> > we are missing something.
>> >>
>> >> In line 201-202, we can see that the "*" of the pointers are not
>> aligned to the right.
>> >
>> >
>> > This seems to be the issue Gedare mentioned which might have a patch.
>> > Follow up on that.
>> >
>> > But I think we had previously discussed this as a point we may have to
>> > concede and change RTEMS style on.
>> >>
>> >> You can check out the formatted file here -
>> https://pastebin.com/nDBrSSCP
>> >
>> >
>> > Is it just the website or are blank line differences? It may just be an
>> > illusion. I think the spacing between the numbered lines is greater
>> > than in the git view. Just odd.
>> >
>> That's just the pastebin having more vertical padding between consecutive
>> lines.
>>
>
> That's what I thought but it did make the code look funny.
>
> Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or
> only
> three in this file?
>
> Probably should try a few more files and see if there are other
> discrepancies.
>
> And obviously work on the integration/automation of using the tools. :)
>
> --joel
>
>
>>
>> > --joel
>> >>
>> >>
>> >>
>> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>> >>>
>> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
>> wrote:
>> >>> >
>> >>> > Hi Gedare,
>> >>> >
>> >>> > With regards to your comment on discord on me looking for a tool
>> that works on both patches and source files, it turns out clang-format has
>> that functionality already. Here's what I found -
>> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>> >>> >
>> >>> > Does it match what you have in mind?
>> >>> >
>> >>> Yes. I think we would want to not use the `-i` option but instead pass
>> >>> through and check the changes. I don't think we should rewrite the
>> >>> patches themselves, but instead we want to use a tool that can be used
>> >>> to check and approve the style of submitted patches. You might need to
>> >>> write a modified version of the clang-format-diff.py to use as a
>> >>> "checker" with ability to provide exceptions to the rules.
>> >>>
>> >>> Gedare
>> >>>
>> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
>> wrote:
>> >>> >>
>> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
>> wrote:
>> >>> >> >
>> >>> >> > Hello everyone,
>> >>> >> > Still waiting for some feedback :)
>> >>> >> >
>> >>> >> > Cheers,
>> >>> >> > Ida.
>> >>> >> >
>> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
>> wrote:
>> >>> >> >>
>> >>> >> >> Hello everyone,
>> >>> >> >> Went through some previous emails and it turns out Sebastian
>> already came up with a configuration for clang format which works well for
>> RTEMS except for the fact that some configurations haven't been implemented
>> into clang-format yet. Using
>> >>> >> >>
>> >>> >> >> AlignConsecutiveDeclarations: false
>> >>> >> >> PointerAlignment: Right
>> >>> >> >>
>> >>> >> >> Doesn't seem to work.
>> >>> >> >> For example in the cpukit/score/src/threadq.c file, something
>> like
>> >>> >> >>
>> >>> >> >> RTEMS_STATIC_ASSERT(
>> >>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >>> >> >> );
>> 

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Joel Sherrill]

On Fri, Jun 4, 2021 at 12:39 PM Gedare Bloom  wrote:

> On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
> >>
> >> Hello everyone,
> >>
> >> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> >> Below are some example areas in the code you can spot the differences:
> >>
> >> In line 68, the ")" at the end of the parameter list needs to be in a
> new row, but this doesn't seem to be supported in clang-format.
> >
> > If I understand correctly, clang-format does not like:
> >
> > https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
> >
> > which has the first parameter on its one line but wants the first
> parameter
> > after the open parenthesis?
> >
> > The RTEMS style would seem to correspond to AlignAfterOpenBracket being
> > set to AlwaysBreak
> >
> >>
> >> In line 142, if the function call is split into multiple rows, the ");"
> should always be in a new row.
> >
> > Having the closing parenthesis on its own line may end up being something
> > we have to change the RTEMS style on. I do not see an option in their
> > documentation to do this. Unfortunate, since I like the symmetry between
> > braces and parentheses.
> >
> >  Could you file an issue with them and/or ask a question the appropriate
> > mailing list? Please cc Gedara and me. Give them an example. Maybe
> > we are missing something.
> >>
> >> In line 201-202, we can see that the "*" of the pointers are not
> aligned to the right.
> >
> >
> > This seems to be the issue Gedare mentioned which might have a patch.
> > Follow up on that.
> >
> > But I think we had previously discussed this as a point we may have to
> > concede and change RTEMS style on.
> >>
> >> You can check out the formatted file here -
> https://pastebin.com/nDBrSSCP
> >
> >
> > Is it just the website or are blank line differences? It may just be an
> > illusion. I think the spacing between the numbered lines is greater
> > than in the git view. Just odd.
> >
> That's just the pastebin having more vertical padding between consecutive
> lines.
>

That's what I thought but it did make the code look funny.

Ida/Gedare.. does this mean there are only 3 style mismatch issues? Or only
three in this file?

Probably should try a few more files and see if there are other
discrepancies.

And obviously work on the integration/automation of using the tools. :)

--joel


>
> > --joel
> >>
> >>
> >>
> >> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
> >>>
> >>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine 
> wrote:
> >>> >
> >>> > Hi Gedare,
> >>> >
> >>> > With regards to your comment on discord on me looking for a tool
> that works on both patches and source files, it turns out clang-format has
> that functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
> >>> >
> >>> > Does it match what you have in mind?
> >>> >
> >>> Yes. I think we would want to not use the `-i` option but instead pass
> >>> through and check the changes. I don't think we should rewrite the
> >>> patches themselves, but instead we want to use a tool that can be used
> >>> to check and approve the style of submitted patches. You might need to
> >>> write a modified version of the clang-format-diff.py to use as a
> >>> "checker" with ability to provide exceptions to the rules.
> >>>
> >>> Gedare
> >>>
> >>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom 
> wrote:
> >>> >>
> >>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
> wrote:
> >>> >> >
> >>> >> > Hello everyone,
> >>> >> > Still waiting for some feedback :)
> >>> >> >
> >>> >> > Cheers,
> >>> >> > Ida.
> >>> >> >
> >>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
> wrote:
> >>> >> >>
> >>> >> >> Hello everyone,
> >>> >> >> Went through some previous emails and it turns out Sebastian
> already came up with a configuration for clang format which works well for
> RTEMS except for the fact that some configurations haven't been implemented
> into clang-format yet. Using
> >>> >> >>
> >>> >> >> AlignConsecutiveDeclarations: false
> >>> >> >> PointerAlignment: Right
> >>> >> >>
> >>> >> >> Doesn't seem to work.
> >>> >> >> For example in the cpukit/score/src/threadq.c file, something
> like
> >>> >> >>
> >>> >> >> RTEMS_STATIC_ASSERT(
> >>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
> >>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
> >>> >> >> );
> >>> >> >>
> >>> >> >> RTEMS_STATIC_ASSERT(
> >>> >> >> sizeof( Thread_queue_Syslock_queue )
> >>> >> >> == sizeof( struct _Thread_queue_Queue ),
> >>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
> >>> >> >> );
> >>> >> >>
> >>> >> >> #if defined(RTEMS_SMP)
> >>> >> >> void _Thread_queue_Do_acquire_critical(
> >>> >> >> Thread_queue_Control *the_thread_queue,
> >>> >> >> ISR_lock_Context 

Re: [PATCH] cpukit/libblock/src: Add better memory handling in flashdisk.c

[Joel Sherrill]

On the surface, this looks OK to me. But I remember looking at this one
and wondering if there was any cleanup required because of the various
subroutine calls as you work down through this method.

Did you look into each of the subroutines called and make sure they
didn't do further allocations?

--joel

On Fri, Jun 4, 2021 at 1:27 PM Harrison Edward Gerber 
wrote:

> See also CID 1439298
>
> Closes #3570
> ---
>  cpukit/libblock/src/flashdisk.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/cpukit/libblock/src/flashdisk.c
> b/cpukit/libblock/src/flashdisk.c
> index 91f99e0d52..4de6ecd807 100644
> --- a/cpukit/libblock/src/flashdisk.c
> +++ b/cpukit/libblock/src/flashdisk.c
> @@ -2486,17 +2486,29 @@ rtems_fdisk_initialize (rtems_device_major_number
> major,
>   */
>  fd->copy_buffer = malloc (c->block_size);
>  if (!fd->copy_buffer)
> +{
> +  free(fd);
>return RTEMS_NO_MEMORY;
> +}
>
>  fd->blocks = calloc (blocks, sizeof (rtems_fdisk_block_ctl));
>  if (!fd->blocks)
> +{
> +  free(fd->copy_buffer);
> +  free(fd);
>return RTEMS_NO_MEMORY;
> +}
>
>  fd->block_count = blocks;
>
>  fd->devices = calloc (c->device_count, sizeof
> (rtems_fdisk_device_ctl));
>  if (!fd->devices)
> +{
> +  free(fd->blocks);
> +  free(fd->copy_buffer);
> +  free(fd);
>return RTEMS_NO_MEMORY;
> +}
>
>  rtems_mutex_init (>lock, "Flash Disk");
>
> @@ -2508,6 +2520,7 @@ rtems_fdisk_initialize (rtems_device_major_number
> major,
>free (fd->copy_buffer);
>free (fd->blocks);
>free (fd->devices);
> +  free(fd);
>rtems_fdisk_error ("disk create phy failed");
>return sc;
>  }
> @@ -2529,6 +2542,7 @@ rtems_fdisk_initialize (rtems_device_major_number
> major,
>  free (fd->copy_buffer);
>  free (fd->blocks);
>  free (fd->devices);
> +free(fd);
>  return RTEMS_NO_MEMORY;
>}
>
> @@ -2564,6 +2578,7 @@ rtems_fdisk_initialize (rtems_device_major_number
> major,
>free (fd->copy_buffer);
>free (fd->blocks);
>free (fd->devices);
> +  free(fd);
>rtems_fdisk_error ("recovery of disk failed: %s (%d)",
>   strerror (ret), ret);
>return ret;
> @@ -2577,6 +2592,7 @@ rtems_fdisk_initialize (rtems_device_major_number
> major,
>free (fd->copy_buffer);
>free (fd->blocks);
>free (fd->devices);
> +  free(fd);
>rtems_fdisk_error ("compacting of disk failed: %s (%d)",
>   strerror (ret), ret);
>return ret;
> --
> 2.25.1
>
> ___
> 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

[PATCH] cpukit/libblock/src: Add better memory handling in flashdisk.c

[Harrison Edward Gerber]

See also CID 1439298

Closes #3570
---
 cpukit/libblock/src/flashdisk.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/cpukit/libblock/src/flashdisk.c b/cpukit/libblock/src/flashdisk.c
index 91f99e0d52..4de6ecd807 100644
--- a/cpukit/libblock/src/flashdisk.c
+++ b/cpukit/libblock/src/flashdisk.c
@@ -2486,17 +2486,29 @@ rtems_fdisk_initialize (rtems_device_major_number major,
  */
 fd->copy_buffer = malloc (c->block_size);
 if (!fd->copy_buffer)
+{
+  free(fd);
   return RTEMS_NO_MEMORY;
+}
 
 fd->blocks = calloc (blocks, sizeof (rtems_fdisk_block_ctl));
 if (!fd->blocks)
+{
+  free(fd->copy_buffer);
+  free(fd);
   return RTEMS_NO_MEMORY;
+}
 
 fd->block_count = blocks;
 
 fd->devices = calloc (c->device_count, sizeof (rtems_fdisk_device_ctl));
 if (!fd->devices)
+{
+  free(fd->blocks);
+  free(fd->copy_buffer);
+  free(fd);
   return RTEMS_NO_MEMORY;
+}
 
 rtems_mutex_init (>lock, "Flash Disk");
 
@@ -2508,6 +2520,7 @@ rtems_fdisk_initialize (rtems_device_major_number major,
   free (fd->copy_buffer);
   free (fd->blocks);
   free (fd->devices);
+  free(fd);
   rtems_fdisk_error ("disk create phy failed");
   return sc;
 }
@@ -2529,6 +2542,7 @@ rtems_fdisk_initialize (rtems_device_major_number major,
 free (fd->copy_buffer);
 free (fd->blocks);
 free (fd->devices);
+free(fd);
 return RTEMS_NO_MEMORY;
   }
 
@@ -2564,6 +2578,7 @@ rtems_fdisk_initialize (rtems_device_major_number major,
   free (fd->copy_buffer);
   free (fd->blocks);
   free (fd->devices);
+  free(fd);
   rtems_fdisk_error ("recovery of disk failed: %s (%d)",
  strerror (ret), ret);
   return ret;
@@ -2577,6 +2592,7 @@ rtems_fdisk_initialize (rtems_device_major_number major,
   free (fd->copy_buffer);
   free (fd->blocks);
   free (fd->devices);
+  free(fd);
   rtems_fdisk_error ("compacting of disk failed: %s (%d)",
  strerror (ret), ret);
   return ret;
-- 
2.25.1

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

[PATCH v1] Explanations.cc: Convert to c++ file handling

[Ryan Long]

---
 tester/covoar/Explanations.cc | 45 ---
 1 file changed, 17 insertions(+), 28 deletions(-)

diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc
index d94cd2e..1449fb2 100644
--- a/tester/covoar/Explanations.cc
+++ b/tester/covoar/Explanations.cc
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 
 #include "Explanations.h"
@@ -30,15 +32,14 @@ namespace Coverage {
   )
   {
 #define MAX_LINE_LENGTH 512
-FILE   *explain;
-char*cStatus;
-Explanation  e;
-int  line = 1;
+std::ifstream  explain;
+Explanatione;
+intline = 1;
 
 if (!explanations)
   return;
 
-explain = ::fopen( explanations, "r" );
+explain.open( explanations );
 if (!explain) {
   std::ostringstream what;
   what << "Unable to open " << explanations;
@@ -50,9 +51,9 @@ namespace Coverage {
   // skip blank lines between
   do {
 inputBuffer[0] = '\0';
-cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
-if (cStatus == NULL) {
-  goto done;
+explain.getline( inputBuffer, MAX_LINE_LENGTH );
+if (explain.fail()) {
+  return;
 }
 inputBuffer[ strlen(inputBuffer) - 1] = '\0';
 line++;
@@ -64,7 +65,6 @@ namespace Coverage {
 what << "line " << line
  << "contains a duplicate explanation ("
  << inputBuffer << ")";
-fclose( explain );
 throw rld::error( what, "Explanations::load" );
   }
 
@@ -73,12 +73,11 @@ namespace Coverage {
   e.found = false;
 
   // Get the classification
-  cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
-  if (cStatus == NULL) {
+  explain.getline( inputBuffer, MAX_LINE_LENGTH );
+  if (explain.fail()) {
 std::ostringstream what;
 what << "line " << line
  << "out of sync at the classification";
-fclose( explain );
 throw rld::error( what, "Explanations::load" );
   }
   inputBuffer[ strlen(inputBuffer) - 1] = '\0';
@@ -87,13 +86,12 @@ namespace Coverage {
 
   // Get the explanation
   while (1) {
-cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain );
+explain.getline( inputBuffer, MAX_LINE_LENGTH );
 // fprintf( stderr, "%d - %s\n", line, inputBuffer );
-if (cStatus == NULL) {
+if (explain.fail()) {
   std::ostringstream what;
   what << "line " << line
<< "out of sync at the explanation";
-  fclose( explain );
   throw rld::error( what, "Explanations::load" );
 }
 inputBuffer[ strlen(inputBuffer) - 1] = '\0';
@@ -110,10 +108,6 @@ namespace Coverage {
   // Add this to the set of Explanations
   set[ e.startingPoint ] = e;
 }
-done:
-;
-
-fclose( explain );
 
 #undef MAX_LINE_LENGTH
   }
@@ -137,14 +131,14 @@ done:
 const char* const fileName
   )
   {
-FILE* notFoundFile;
+std::ofstream notFoundFile;
 bool  notFoundOccurred = false;
 
 if (!fileName)
   return;
 
-notFoundFile = fopen( fileName, "w" );
-if (notFoundFile == nullptr) {
+notFoundFile.open( fileName );
+if (!notFoundFile) {
   std::ostringstream what;
   what << "Unable to open " << fileName
<< " out of sync at the explanation";
@@ -159,14 +153,9 @@ done:
 
   if (!e.found) {
 notFoundOccurred = true;
-fprintf(
-  notFoundFile,
-  "%s\n",
-  e.startingPoint.c_str()
-);
+notFoundFile << e.startingPoint << std::endl;
   }
 }
-fclose( notFoundFile );
 
 if (!notFoundOccurred) {
   if (!unlink( fileName )) {
-- 
1.8.3.1

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

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

[Gedare Bloom]

does this one need doco update for the option changes?

On Fri, Jun 4, 2021 at 1:48 AM Christian Mauderer
 wrote:
>
> Calling the memory FLASH and EXTRAM instead of FLEXSPI and SDRAM makes
> it simpler to support other types of external RAM. This patch also
> removes some of the calculations and improves names and documentation to
> avoid pitfalls. It removes a unnecessary memory definition.
>
> Update #4180
> ---
>  bsps/arm/imxrt/include/imxrt/memory.h | 34 ++
>  bsps/arm/imxrt/start/flash-boot-data.c|  4 +-
>  ...{flash-config.c => flash-flexspi-config.c} |  2 +-
>  bsps/arm/imxrt/start/linkcmds.flexspi | 38 +++
>  bsps/arm/imxrt/start/linkcmds.sdram   | 34 +++---
>  bsps/arm/imxrt/start/mpu-config.c | 12 ++---
>  spec/build/bsps/arm/imxrt/bspimxrt.yml| 20 
>  spec/build/bsps/arm/imxrt/linkcmdsmemory.yml  | 47 +--
>  ...ocachesz.yml => optmemextramnocachesz.yml} |  5 +-
>  ...emsdrambase.yml => optmemextramorigin.yml} |  5 +-
>  spec/build/bsps/arm/imxrt/optmemextramsz.yml  | 19 
>  ...ptmemsdramsz.yml => optmemflashorigin.yml} |  9 ++--
>  spec/build/bsps/arm/imxrt/optmemflashsz.yml   | 20 
>  spec/build/bsps/arm/imxrt/optmemflexspisz.yml | 17 ---
>  spec/build/bsps/arm/imxrt/optmemitcmsz.yml|  7 +--
>  spec/build/bsps/arm/imxrt/optmemnullsz.yml|  5 +-
>  .../bsps/arm/imxrt/optmemocramnocachesz.yml   |  3 +-
>  spec/build/bsps/arm/imxrt/optmemocramsz.yml   |  6 ++-
>  18 files changed, 156 insertions(+), 131 deletions(-)
>  rename bsps/arm/imxrt/start/{flash-config.c => flash-flexspi-config.c} (98%)
>  rename spec/build/bsps/arm/imxrt/{optmemsdramnocachesz.yml => 
> optmemextramnocachesz.yml} (66%)
>  rename spec/build/bsps/arm/imxrt/{optmemsdrambase.yml => 
> optmemextramorigin.yml} (65%)
>  create mode 100644 spec/build/bsps/arm/imxrt/optmemextramsz.yml
>  rename spec/build/bsps/arm/imxrt/{optmemsdramsz.yml => 
> optmemflashorigin.yml} (53%)
>  create mode 100644 spec/build/bsps/arm/imxrt/optmemflashsz.yml
>  delete mode 100644 spec/build/bsps/arm/imxrt/optmemflexspisz.yml
>
> diff --git a/bsps/arm/imxrt/include/imxrt/memory.h 
> b/bsps/arm/imxrt/include/imxrt/memory.h
> index 8185f713cc..47bb10f41e 100644
> --- a/bsps/arm/imxrt/include/imxrt/memory.h
> +++ b/bsps/arm/imxrt/include/imxrt/memory.h
> @@ -56,29 +56,25 @@ extern char imxrt_memory_peripheral_begin[];
>  extern char imxrt_memory_peripheral_end[];
>  extern char imxrt_memory_peripheral_size[];
>
> -extern char imxrt_memory_flexspi_config_begin[];
> -extern char imxrt_memory_flexspi_config_end[];
> -extern char imxrt_memory_flexspi_config_size[];
> +extern char imxrt_memory_flash_config_begin[];
> +extern char imxrt_memory_flash_config_end[];
> +extern char imxrt_memory_flash_config_size[];
>
> -extern char imxrt_memory_flexspi_ivt_begin[];
> -extern char imxrt_memory_flexspi_ivt_end[];
> -extern char imxrt_memory_flexspi_ivt_size[];
> +extern char imxrt_memory_flash_ivt_begin[];
> +extern char imxrt_memory_flash_ivt_end[];
> +extern char imxrt_memory_flash_ivt_size[];
>
> -extern char imxrt_memory_flexspi_begin[];
> -extern char imxrt_memory_flexspi_end[];
> -extern char imxrt_memory_flexspi_size[];
> +extern char imxrt_memory_flash_begin[];
> +extern char imxrt_memory_flash_end[];
> +extern char imxrt_memory_flash_size[];
>
> -extern char imxrt_memory_flexspi_fifo_begin[];
> -extern char imxrt_memory_flexspi_fifo_end[];
> -extern char imxrt_memory_flexspi_fifo_size[];
> +extern char imxrt_memory_extram_begin[];
> +extern char imxrt_memory_extram_end[];
> +extern char imxrt_memory_extram_size[];
>
> -extern char imxrt_memory_sdram_begin[];
> -extern char imxrt_memory_sdram_end[];
> -extern char imxrt_memory_sdram_size[];
> -
> -extern char imxrt_memory_sdram_nocache_begin[];
> -extern char imxrt_memory_sdram_nocache_end[];
> -extern char imxrt_memory_sdram_nocache_size[];
> +extern char imxrt_memory_extram_nocache_begin[];
> +extern char imxrt_memory_extram_nocache_end[];
> +extern char imxrt_memory_extram_nocache_size[];
>
>  #ifdef __cplusplus
>  }
> diff --git a/bsps/arm/imxrt/start/flash-boot-data.c 
> b/bsps/arm/imxrt/start/flash-boot-data.c
> index cf0430af72..a1877f4d26 100644
> --- a/bsps/arm/imxrt/start/flash-boot-data.c
> +++ b/bsps/arm/imxrt/start/flash-boot-data.c
> @@ -30,8 +30,8 @@
>  #include 
>
>  const BOOT_DATA_T imxrt_boot_data = {
> -  .start = (uint32_t) imxrt_memory_flexspi_config_begin,
> -  .size = IMXRT_MEMORY_FLEXSPI_FLASH_SIZE,
> +  .start = (uint32_t) imxrt_memory_flash_config_begin,
> +  .size = IMXRT_MEMORY_FLASH_SIZE,
>.plugin = PLUGIN_FLAG,
>.placeholder = 0x,
>  };
> diff --git a/bsps/arm/imxrt/start/flash-config.c 
> b/bsps/arm/imxrt/start/flash-flexspi-config.c
> similarity index 98%
> rename from bsps/arm/imxrt/start/flash-config.c
> rename to bsps/arm/imxrt/start/flash-flexspi-config.c
> index 07324f1330..50eca19b20 100644
> --- 

Re: [PATCH rtems 1/2] bsps/imxrt: Allow different ARM PLL setting

[Gedare Bloom]

On Fri, Jun 4, 2021 at 1:48 AM Christian Mauderer
 wrote:
>
> Update #4180
> ---
>  .../nxp/boards/evkbimxrt1050/clock_config.c   |  5 +++
>  bsps/arm/imxrt/start/clock-arm-pll-config.c   | 33 +++
>  spec/build/bsps/arm/imxrt/bspimxrt.yml|  1 +
>  3 files changed, 39 insertions(+)
>  create mode 100644 bsps/arm/imxrt/start/clock-arm-pll-config.c
>
> diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c 
> b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
> index c23d5da356..ea28d06dd8 100644
> --- a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
> +++ b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
> @@ -33,6 +33,7 @@ board: IMXRT1050-EVKB
>  #ifndef __rtems__
>  #include "clock_config.h"
>  #else /* __rtems__ */
> +#include 
>  #include "fsl_clock_config.h"
>  #endif /* __rtems__ */
>  #include "fsl_iomuxc.h"
> @@ -146,10 +147,14 @@ sources:
>  
> /***
>   * Variables for BOARD_BootClockRUN configuration
>   
> **/
> +#ifndef __rtems__
>  const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
>  .loopDivider = 100, /* PLL loop divider, Fout = Fin * 50 */
>  .src = 0,   /* Bypass clock source, 0 - OSC 24M, 1 - CLK1_P and 
> CLK1_N */
>  };
> +#else /* __rtems__ */
> +/* Moved to a separate file so an application can overwrite it. */
although it may be trivial, perhaps add the filename/path
(bsps/arm/imxrt/start/clock-arm-pll-config.c) in the comment?

BSP doco provided how to override it?

> +#endif /* __rtems__ */
>  const clock_sys_pll_config_t sysPllConfig_BOARD_BootClockRUN = {
>  .loopDivider = 1, /* PLL loop divider, Fout = Fin * ( 20 + loopDivider*2 
> + numerator / denominator ) */
>  .numerator   = 0, /* 30 bit numerator of fractional loop divider */
> diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c 
> b/bsps/arm/imxrt/start/clock-arm-pll-config.c
> new file mode 100644
> index 00..12ad1867eb
> --- /dev/null
> +++ b/bsps/arm/imxrt/start/clock-arm-pll-config.c
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (C) 2021 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
> + * 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.
> + */
> +
> +#include "fsl_clock_config.h"
> +
> +const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
> +.loopDivider = 100,
> +.src = 0,
> +};
> diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
> b/spec/build/bsps/arm/imxrt/bspimxrt.yml
> index f543a14394..c6ea904754 100644
> --- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
> +++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
> @@ -238,6 +238,7 @@ source:
>  - bsps/arm/imxrt/spi/imxrt-lpspi.c
>  - bsps/arm/imxrt/start/bspstart.c
>  - bsps/arm/imxrt/start/bspstarthooks.c
> +- bsps/arm/imxrt/start/clock-arm-pll-config.c
>  - bsps/arm/imxrt/start/flash-boot-data.c
>  - bsps/arm/imxrt/start/flash-config.c
>  - bsps/arm/imxrt/start/flash-dcd.c
> --
> 2.26.2
>
> ___
> 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 2/2] cpu/armv7m: Fix initialization of MPU regions

[Gedare Bloom]

ok

On Fri, Jun 4, 2021 at 1:47 AM Christian Mauderer
 wrote:
>
> The write to RBAR didn't have the valid flag set. Therefore the write to
> RASR had an influence on the previously set region. That means for
> example that if Region 0 had been enabled but 1 should be disabled due
> to a size of 0, the previous code would have disabled region 0 instead.
>
> This patch fixes that behaviour.
>
> Close #4450
> ---
>  cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
> b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> index a5eaaef418..1803c8d8ca 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
> @@ -660,7 +660,7 @@ static inline void _ARMV7M_MPU_Set_region(
>  rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
>  rasr |= _ARMV7M_MPU_Get_region_size(size);
>} else {
> -rbar = region;
> +rbar = ARMV7M_MPU_RBAR_VALID | region;
>  rasr = 0;
>}
>
> --
> 2.26.2
>
> ___
> 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: GSoC - Code Formatting and Style Checking for RTEMS score

[Gedare Bloom]

On Fri, Jun 4, 2021 at 8:47 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:
>>
>> Hello everyone,
>>
>> I applied the configuration Sebastian used and ran clang-format on 
>> cpukit/score/src/threadqenque.c and so far these are the differences I could 
>> notice...
>> Below are some example areas in the code you can spot the differences:
>>
>> In line 68, the ")" at the end of the parameter list needs to be in a new 
>> row, but this doesn't seem to be supported in clang-format.
>
> If I understand correctly, clang-format does not like:
>
> https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c
>
> which has the first parameter on its one line but wants the first parameter
> after the open parenthesis?
>
> The RTEMS style would seem to correspond to AlignAfterOpenBracket being
> set to AlwaysBreak
>
>>
>> In line 142, if the function call is split into multiple rows, the ");" 
>> should always be in a new row.
>
> Having the closing parenthesis on its own line may end up being something
> we have to change the RTEMS style on. I do not see an option in their
> documentation to do this. Unfortunate, since I like the symmetry between
> braces and parentheses.
>
>  Could you file an issue with them and/or ask a question the appropriate
> mailing list? Please cc Gedara and me. Give them an example. Maybe
> we are missing something.
>>
>> In line 201-202, we can see that the "*" of the pointers are not aligned to 
>> the right.
>
>
> This seems to be the issue Gedare mentioned which might have a patch.
> Follow up on that.
>
> But I think we had previously discussed this as a point we may have to
> concede and change RTEMS style on.
>>
>> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>
>
> Is it just the website or are blank line differences? It may just be an
> illusion. I think the spacing between the numbered lines is greater
> than in the git view. Just odd.
>
That's just the pastebin having more vertical padding between consecutive lines.

> --joel
>>
>>
>>
>> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>>>
>>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>>> >
>>> > Hi Gedare,
>>> >
>>> > With regards to your comment on discord on me looking for a tool that 
>>> > works on both patches and source files, it turns out clang-format has 
>>> > that functionality already. Here's what I found - 
>>> > https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>>> >
>>> > Does it match what you have in mind?
>>> >
>>> Yes. I think we would want to not use the `-i` option but instead pass
>>> through and check the changes. I don't think we should rewrite the
>>> patches themselves, but instead we want to use a tool that can be used
>>> to check and approve the style of submitted patches. You might need to
>>> write a modified version of the clang-format-diff.py to use as a
>>> "checker" with ability to provide exceptions to the rules.
>>>
>>> Gedare
>>>
>>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine  wrote:
>>> >> >
>>> >> > Hello everyone,
>>> >> > Still waiting for some feedback :)
>>> >> >
>>> >> > Cheers,
>>> >> > Ida.
>>> >> >
>>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine,  wrote:
>>> >> >>
>>> >> >> Hello everyone,
>>> >> >> Went through some previous emails and it turns out Sebastian already 
>>> >> >> came up with a configuration for clang format which works well for 
>>> >> >> RTEMS except for the fact that some configurations haven't been 
>>> >> >> implemented into clang-format yet. Using
>>> >> >>
>>> >> >> AlignConsecutiveDeclarations: false
>>> >> >> PointerAlignment: Right
>>> >> >>
>>> >> >> Doesn't seem to work.
>>> >> >> For example in the cpukit/score/src/threadq.c file, something like
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(
>>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>>> >> >> );
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(
>>> >> >> sizeof( Thread_queue_Syslock_queue )
>>> >> >> == sizeof( struct _Thread_queue_Queue ),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>>> >> >> );
>>> >> >>
>>> >> >> #if defined(RTEMS_SMP)
>>> >> >> void _Thread_queue_Do_acquire_critical(
>>> >> >> Thread_queue_Control *the_thread_queue,
>>> >> >> ISR_lock_Context *lock_context
>>> >> >> )
>>> >> >> {
>>> >> >> _Thread_queue_Queue_acquire_critical(
>>> >> >> _thread_queue->Queue,
>>> >> >> _thread_queue->Lock_stats,
>>> >> >> lock_context
>>> >> >> );
>>> >> >>
>>> >> >> becomes this after using the given configuration
>>> >> >>
>>> >> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>>> >> >> sizeof(struct _Thread_queue_Queue),
>>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>>> >> >>
>>> >> >> #if defined(RTEMS_SMP)
>>> >> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control 
>>> >> >> 

RE: [PATCH v1 1/6] Explanations.cc: Fix resource leaks

[Ryan Long]

We'll submit the C++ conversions as separate patches since they are larger. 
That patch will be submitted shortly.

-Original Message-
From: Chris Johns  
Sent: Friday, May 28, 2021 8:05 PM
To: Ryan Long ; devel@rtems.org
Subject: Re: [PATCH v1 1/6] Explanations.cc: Fix resource leaks

On 29/5/21 8:08 am, Ryan Long wrote:
> CID 1399608: Resource leak in load().
> CID 1399611: Resource leak in load().
> 
> Closes #4417
> ---
>  tester/covoar/Explanations.cc | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/tester/covoar/Explanations.cc 
> b/tester/covoar/Explanations.cc index 12bd809..d94cd2e 100644
> --- a/tester/covoar/Explanations.cc
> +++ b/tester/covoar/Explanations.cc
> @@ -32,7 +32,7 @@ namespace Coverage {
>  #define MAX_LINE_LENGTH 512
>  FILE   *explain;
>  char*cStatus;
> -Explanation *e;
> +Explanation  e;
>  int  line = 1;
>  
>  if (!explanations)
> @@ -46,7 +46,6 @@ namespace Coverage {
>  }
>  
>  while ( 1 ) {
> -  e = new Explanation;
>// Read the starting line of this explanation and
>// skip blank lines between
>do {
> @@ -65,12 +64,13 @@ namespace Coverage {
>  what << "line " << line
>   << "contains a duplicate explanation ("
>   << inputBuffer << ")";
> +fclose( explain );
>  throw rld::error( what, "Explanations::load" );

If you used a std::ostream type object it would be automatically closed when 
that object destructs via any exit path.

While this patch fixes the bug(s) the mixing of C here is generating these 
issues and effort cleaning that up will reward you.

Chris

>}
>  
>// Add the starting line and file
> -  e->startingPoint = std::string(inputBuffer);
> -  e->found = false;
> +  e.startingPoint = std::string(inputBuffer);
> +  e.found = false;
>  
>// Get the classification
>cStatus = fgets( inputBuffer, MAX_LINE_LENGTH, explain ); @@ 
> -78,10 +78,11 @@ namespace Coverage {
>  std::ostringstream what;
>  what << "line " << line
>   << "out of sync at the classification";
> +fclose( explain );
>  throw rld::error( what, "Explanations::load" );
>}
>inputBuffer[ strlen(inputBuffer) - 1] = '\0';
> -  e->classification = inputBuffer;
> +  e.classification = inputBuffer;
>line++;
>  
>// Get the explanation
> @@ -92,6 +93,7 @@ namespace Coverage {
>std::ostringstream what;
>what << "line " << line
> << "out of sync at the explanation";
> +  fclose( explain );
>throw rld::error( what, "Explanations::load" );
>  }
>  inputBuffer[ strlen(inputBuffer) - 1] = '\0'; @@ -102,15 
> +104,17 @@ namespace Coverage {
>break;
>  }
>  // XXX only taking last line.  Needs to be a vector
> -e->explanation.push_back( inputBuffer );
> +e.explanation.push_back( inputBuffer );
>}
>  
>// Add this to the set of Explanations
> -  set[ e->startingPoint ] = *e;
> +  set[ e.startingPoint ] = e;
>  }
>  done:
>  ;
>  
> +fclose( explain );
> +
>  #undef MAX_LINE_LENGTH
>}
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

[Joel Sherrill]

On Fri, Jun 4, 2021 at 12:24 AM Ida Delphine  wrote:

> Hello everyone,
>
> I applied the configuration Sebastian used and ran clang-format on
> cpukit/score/src/threadqenque.c and so far these are the differences I
> could notice...
> Below are some example areas in the code you can spot the differences:
>
>- In line 68, the ")" at the end of the parameter list needs to be in
>a new row, but this doesn't seem to be supported in clang-format.
>
> If I understand correctly, clang-format does not like:

https://git.rtems.org/rtems/tree/cpukit/score/src/threadqenqueue.c

which has the first parameter on its one line but wants the first parameter
after the open parenthesis?

The RTEMS style would seem to correspond to AlignAfterOpenBracket being
set to AlwaysBreak


>
>- In line 142, if the function call is split into multiple rows, the
>");" should always be in a new row.
>
> Having the closing parenthesis on its own line may end up being something
we have to change the RTEMS style on. I do not see an option in their
documentation to do this. Unfortunate, since I like the symmetry between
braces and parentheses.

 Could you file an issue with them and/or ask a question the appropriate
mailing list? Please cc Gedara and me. Give them an example. Maybe
we are missing something.

>
>- In line 201-202, we can see that the "*" of the pointers are not
>aligned to the right.
>
>
This seems to be the issue Gedare mentioned which might have a patch.
Follow up on that.

But I think we had previously discussed this as a point we may have to
concede and change RTEMS style on.

> You can check out the formatted file here - https://pastebin.com/nDBrSSCP
>

Is it just the website or are blank line differences? It may just be an
illusion. I think the spacing between the numbered lines is greater
than in the git view. Just odd.

--joel

>
>
> On Tue, Jun 1, 2021 at 5:36 PM Gedare Bloom  wrote:
>
>> On Mon, May 31, 2021 at 2:59 PM Ida Delphine  wrote:
>> >
>> > Hi Gedare,
>> >
>> > With regards to your comment on discord on me looking for a tool that
>> works on both patches and source files, it turns out clang-format has that
>> functionality already. Here's what I found -
>> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>> >
>> > Does it match what you have in mind?
>> >
>> Yes. I think we would want to not use the `-i` option but instead pass
>> through and check the changes. I don't think we should rewrite the
>> patches themselves, but instead we want to use a tool that can be used
>> to check and approve the style of submitted patches. You might need to
>> write a modified version of the clang-format-diff.py to use as a
>> "checker" with ability to provide exceptions to the rules.
>>
>> Gedare
>>
>> > On Thu, May 13, 2021 at 3:49 PM Gedare Bloom  wrote:
>> >>
>> >> On Wed, May 12, 2021 at 2:18 PM Ida Delphine 
>> wrote:
>> >> >
>> >> > Hello everyone,
>> >> > Still waiting for some feedback :)
>> >> >
>> >> > Cheers,
>> >> > Ida.
>> >> >
>> >> > On Mon, 10 May 2021, 5:59 am Ida Delphine, 
>> wrote:
>> >> >>
>> >> >> Hello everyone,
>> >> >> Went through some previous emails and it turns out Sebastian
>> already came up with a configuration for clang format which works well for
>> RTEMS except for the fact that some configurations haven't been implemented
>> into clang-format yet. Using
>> >> >>
>> >> >> AlignConsecutiveDeclarations: false
>> >> >> PointerAlignment: Right
>> >> >>
>> >> >> Doesn't seem to work.
>> >> >> For example in the cpukit/score/src/threadq.c file, something like
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(
>> >> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >> >> );
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(
>> >> >> sizeof( Thread_queue_Syslock_queue )
>> >> >> == sizeof( struct _Thread_queue_Queue ),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> >> >> );
>> >> >>
>> >> >> #if defined(RTEMS_SMP)
>> >> >> void _Thread_queue_Do_acquire_critical(
>> >> >> Thread_queue_Control *the_thread_queue,
>> >> >> ISR_lock_Context *lock_context
>> >> >> )
>> >> >> {
>> >> >> _Thread_queue_Queue_acquire_critical(
>> >> >> _thread_queue->Queue,
>> >> >> _thread_queue->Lock_stats,
>> >> >> lock_context
>> >> >> );
>> >> >>
>> >> >> becomes this after using the given configuration
>> >> >>
>> >> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> >> >> sizeof(struct _Thread_queue_Queue),
>> >> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>> >> >>
>> >> >> #if defined(RTEMS_SMP)
>> >> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
>> *the_thread_queue,
>> >> >> ISR_lock_Context *lock_context) {
>> >> >> _Thread_queue_Queue_acquire_critical(
>> >> >> _thread_queue->Queue, _thread_queue->Lock_stats,
>> lock_context);
>> >> >>
>> >> >> Everything seems manageable except for this alignment issue...
>> >> >> This also throws more light on the changes 

Re: Selection of ethernet peripheral by application

[Joel Sherrill]

On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore 
wrote:

> On 6/4/2021 02:32, Christian MAUDERER wrote:
> > Am 02.06.21 um 20:37 schrieb Kinsey Moore:
> >> Hello,
> >>
> >>  From what I’ve seen of the various BSPs supported by LibBSD that
> >> have multiple ethernet peripherals,
> >>
> >> only one tends to be chosen and supported. I’ve encountered a
> >> situation where the majority of platform
> >>
> >> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the
> >> only/primary ethernet interface and I
> >>
> >> need to have the option of selecting a different peripheral as the
> >> primary interface.
> >>
> >> Unfortunately, the current configuration of LibBSD/RTEMS does not
> >> allow for easy switching among the
> >>
> >> available interfaces. The easy one-off option is to just create a BSP
> >> variant with a little bit of extra logic
> >>
> >> to select the correct interface in LibBSD, but this problem seems
> >> more generally applicable than just
> >>
> >> ethernet and just this one BSP. Is the best alternative to configure
> >> all available devices in
> >>
> >> nexus-devices.h and let LibBSD figure it out?
> >>
> >> Thanks,
> >> Kinsey
> >>
> >
> > If the problem is with "nexus-devices.h": You can always just add
> > further devices or a completely own set of devices in your
> > application. For example it should be no problem to use
> >
> > 
> > SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
> > SYSINIT_MODULE_REFERENCE(wlan_sta);
> > SYSINIT_MODULE_REFERENCE(wlan_amrr);
> > SYSINIT_MODULE_REFERENCE(wlan_wep);
> > SYSINIT_MODULE_REFERENCE(wlan_tkip);
> > SYSINIT_MODULE_REFERENCE(wlan_ccmp);
> > SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
> > SYSINIT_REFERENCE(rtwn_rtl8188eufw);
> >
> > #define RTEMS_BSD_CONFIG_BSP_CONFIG
> > #define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
> > #define RTEMS_BSD_CONFIG_INIT
> >
> > #include 
> > 
> >
> > in your application to add WLAN support. You could also remove the
> > RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h
> > is not included in the rtems-bsd-config.h) and define a different set
> > of modules for your application.
> >
> > Best regards
> >
> > Christian
>
> I guess this is a misunderstanding on my part. It might still be nice to
> have something switchable for testing purposes, but I see that it can be
> altered relatively easily on the application side of things.
>

I think what you want is like what some of the BSPs do which have a
second ifdef inside the LIBBSP conditional. This is an example from
the QORIQ. Perhaps an option in the BSP?

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212

Would this qualify as a BSP variant?

If you can probe for each, you could configure both but I suspect that's
likely undesirable for many applications. A configure option might be
the cleanest thing. Probably not worth a BSP variant.

--joel

>
>
> Thanks,
>
> 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: Selection of ethernet peripheral by application

[Kinsey Moore]

On 6/4/2021 02:32, Christian MAUDERER wrote:

Am 02.06.21 um 20:37 schrieb Kinsey Moore:

Hello,

 From what I’ve seen of the various BSPs supported by LibBSD that 
have multiple ethernet peripherals,


only one tends to be chosen and supported. I’ve encountered a 
situation where the majority of platform


examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the 
only/primary ethernet interface and I


need to have the option of selecting a different peripheral as the 
primary interface.


Unfortunately, the current configuration of LibBSD/RTEMS does not 
allow for easy switching among the


available interfaces. The easy one-off option is to just create a BSP 
variant with a little bit of extra logic


to select the correct interface in LibBSD, but this problem seems 
more generally applicable than just


ethernet and just this one BSP. Is the best alternative to configure 
all available devices in


nexus-devices.h and let LibBSD figure it out?

Thanks,
Kinsey



If the problem is with "nexus-devices.h": You can always just add 
further devices or a completely own set of devices in your 
application. For example it should be no problem to use



SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
SYSINIT_MODULE_REFERENCE(wlan_sta);
SYSINIT_MODULE_REFERENCE(wlan_amrr);
SYSINIT_MODULE_REFERENCE(wlan_wep);
SYSINIT_MODULE_REFERENCE(wlan_tkip);
SYSINIT_MODULE_REFERENCE(wlan_ccmp);
SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
SYSINIT_REFERENCE(rtwn_rtl8188eufw);

#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
#define RTEMS_BSD_CONFIG_INIT

#include 


in your application to add WLAN support. You could also remove the 
RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h 
is not included in the rtems-bsd-config.h) and define a different set 
of modules for your application.


Best regards

Christian


I guess this is a misunderstanding on my part. It might still be nice to 
have something switchable for testing purposes, but I see that it can be 
altered relatively easily on the application side of things.



Thanks,

Kinsey

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

[PATCH rtems 1/2] bsps/imxrt: Allow different ARM PLL setting

[Christian Mauderer]

Update #4180
---
 .../nxp/boards/evkbimxrt1050/clock_config.c   |  5 +++
 bsps/arm/imxrt/start/clock-arm-pll-config.c   | 33 +++
 spec/build/bsps/arm/imxrt/bspimxrt.yml|  1 +
 3 files changed, 39 insertions(+)
 create mode 100644 bsps/arm/imxrt/start/clock-arm-pll-config.c

diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c 
b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
index c23d5da356..ea28d06dd8 100644
--- a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
+++ b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
@@ -33,6 +33,7 @@ board: IMXRT1050-EVKB
 #ifndef __rtems__
 #include "clock_config.h"
 #else /* __rtems__ */
+#include 
 #include "fsl_clock_config.h"
 #endif /* __rtems__ */
 #include "fsl_iomuxc.h"
@@ -146,10 +147,14 @@ sources:
 
/***
  * Variables for BOARD_BootClockRUN configuration
  
**/
+#ifndef __rtems__
 const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
 .loopDivider = 100, /* PLL loop divider, Fout = Fin * 50 */
 .src = 0,   /* Bypass clock source, 0 - OSC 24M, 1 - CLK1_P and 
CLK1_N */
 };
+#else /* __rtems__ */
+/* Moved to a separate file so an application can overwrite it. */
+#endif /* __rtems__ */
 const clock_sys_pll_config_t sysPllConfig_BOARD_BootClockRUN = {
 .loopDivider = 1, /* PLL loop divider, Fout = Fin * ( 20 + loopDivider*2 + 
numerator / denominator ) */
 .numerator   = 0, /* 30 bit numerator of fractional loop divider */
diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c 
b/bsps/arm/imxrt/start/clock-arm-pll-config.c
new file mode 100644
index 00..12ad1867eb
--- /dev/null
+++ b/bsps/arm/imxrt/start/clock-arm-pll-config.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2021 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
+ * 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.
+ */
+
+#include "fsl_clock_config.h"
+
+const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
+.loopDivider = 100,
+.src = 0,
+};
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index f543a14394..c6ea904754 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -238,6 +238,7 @@ source:
 - bsps/arm/imxrt/spi/imxrt-lpspi.c
 - bsps/arm/imxrt/start/bspstart.c
 - bsps/arm/imxrt/start/bspstarthooks.c
+- bsps/arm/imxrt/start/clock-arm-pll-config.c
 - bsps/arm/imxrt/start/flash-boot-data.c
 - bsps/arm/imxrt/start/flash-config.c
 - bsps/arm/imxrt/start/flash-dcd.c
-- 
2.26.2

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

[PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

[Christian Mauderer]

Calling the memory FLASH and EXTRAM instead of FLEXSPI and SDRAM makes
it simpler to support other types of external RAM. This patch also
removes some of the calculations and improves names and documentation to
avoid pitfalls. It removes a unnecessary memory definition.

Update #4180
---
 bsps/arm/imxrt/include/imxrt/memory.h | 34 ++
 bsps/arm/imxrt/start/flash-boot-data.c|  4 +-
 ...{flash-config.c => flash-flexspi-config.c} |  2 +-
 bsps/arm/imxrt/start/linkcmds.flexspi | 38 +++
 bsps/arm/imxrt/start/linkcmds.sdram   | 34 +++---
 bsps/arm/imxrt/start/mpu-config.c | 12 ++---
 spec/build/bsps/arm/imxrt/bspimxrt.yml| 20 
 spec/build/bsps/arm/imxrt/linkcmdsmemory.yml  | 47 +--
 ...ocachesz.yml => optmemextramnocachesz.yml} |  5 +-
 ...emsdrambase.yml => optmemextramorigin.yml} |  5 +-
 spec/build/bsps/arm/imxrt/optmemextramsz.yml  | 19 
 ...ptmemsdramsz.yml => optmemflashorigin.yml} |  9 ++--
 spec/build/bsps/arm/imxrt/optmemflashsz.yml   | 20 
 spec/build/bsps/arm/imxrt/optmemflexspisz.yml | 17 ---
 spec/build/bsps/arm/imxrt/optmemitcmsz.yml|  7 +--
 spec/build/bsps/arm/imxrt/optmemnullsz.yml|  5 +-
 .../bsps/arm/imxrt/optmemocramnocachesz.yml   |  3 +-
 spec/build/bsps/arm/imxrt/optmemocramsz.yml   |  6 ++-
 18 files changed, 156 insertions(+), 131 deletions(-)
 rename bsps/arm/imxrt/start/{flash-config.c => flash-flexspi-config.c} (98%)
 rename spec/build/bsps/arm/imxrt/{optmemsdramnocachesz.yml => 
optmemextramnocachesz.yml} (66%)
 rename spec/build/bsps/arm/imxrt/{optmemsdrambase.yml => 
optmemextramorigin.yml} (65%)
 create mode 100644 spec/build/bsps/arm/imxrt/optmemextramsz.yml
 rename spec/build/bsps/arm/imxrt/{optmemsdramsz.yml => optmemflashorigin.yml} 
(53%)
 create mode 100644 spec/build/bsps/arm/imxrt/optmemflashsz.yml
 delete mode 100644 spec/build/bsps/arm/imxrt/optmemflexspisz.yml

diff --git a/bsps/arm/imxrt/include/imxrt/memory.h 
b/bsps/arm/imxrt/include/imxrt/memory.h
index 8185f713cc..47bb10f41e 100644
--- a/bsps/arm/imxrt/include/imxrt/memory.h
+++ b/bsps/arm/imxrt/include/imxrt/memory.h
@@ -56,29 +56,25 @@ extern char imxrt_memory_peripheral_begin[];
 extern char imxrt_memory_peripheral_end[];
 extern char imxrt_memory_peripheral_size[];
 
-extern char imxrt_memory_flexspi_config_begin[];
-extern char imxrt_memory_flexspi_config_end[];
-extern char imxrt_memory_flexspi_config_size[];
+extern char imxrt_memory_flash_config_begin[];
+extern char imxrt_memory_flash_config_end[];
+extern char imxrt_memory_flash_config_size[];
 
-extern char imxrt_memory_flexspi_ivt_begin[];
-extern char imxrt_memory_flexspi_ivt_end[];
-extern char imxrt_memory_flexspi_ivt_size[];
+extern char imxrt_memory_flash_ivt_begin[];
+extern char imxrt_memory_flash_ivt_end[];
+extern char imxrt_memory_flash_ivt_size[];
 
-extern char imxrt_memory_flexspi_begin[];
-extern char imxrt_memory_flexspi_end[];
-extern char imxrt_memory_flexspi_size[];
+extern char imxrt_memory_flash_begin[];
+extern char imxrt_memory_flash_end[];
+extern char imxrt_memory_flash_size[];
 
-extern char imxrt_memory_flexspi_fifo_begin[];
-extern char imxrt_memory_flexspi_fifo_end[];
-extern char imxrt_memory_flexspi_fifo_size[];
+extern char imxrt_memory_extram_begin[];
+extern char imxrt_memory_extram_end[];
+extern char imxrt_memory_extram_size[];
 
-extern char imxrt_memory_sdram_begin[];
-extern char imxrt_memory_sdram_end[];
-extern char imxrt_memory_sdram_size[];
-
-extern char imxrt_memory_sdram_nocache_begin[];
-extern char imxrt_memory_sdram_nocache_end[];
-extern char imxrt_memory_sdram_nocache_size[];
+extern char imxrt_memory_extram_nocache_begin[];
+extern char imxrt_memory_extram_nocache_end[];
+extern char imxrt_memory_extram_nocache_size[];
 
 #ifdef __cplusplus
 }
diff --git a/bsps/arm/imxrt/start/flash-boot-data.c 
b/bsps/arm/imxrt/start/flash-boot-data.c
index cf0430af72..a1877f4d26 100644
--- a/bsps/arm/imxrt/start/flash-boot-data.c
+++ b/bsps/arm/imxrt/start/flash-boot-data.c
@@ -30,8 +30,8 @@
 #include 
 
 const BOOT_DATA_T imxrt_boot_data = {
-  .start = (uint32_t) imxrt_memory_flexspi_config_begin,
-  .size = IMXRT_MEMORY_FLEXSPI_FLASH_SIZE,
+  .start = (uint32_t) imxrt_memory_flash_config_begin,
+  .size = IMXRT_MEMORY_FLASH_SIZE,
   .plugin = PLUGIN_FLAG,
   .placeholder = 0x,
 };
diff --git a/bsps/arm/imxrt/start/flash-config.c 
b/bsps/arm/imxrt/start/flash-flexspi-config.c
similarity index 98%
rename from bsps/arm/imxrt/start/flash-config.c
rename to bsps/arm/imxrt/start/flash-flexspi-config.c
index 07324f1330..50eca19b20 100644
--- a/bsps/arm/imxrt/start/flash-config.c
+++ b/bsps/arm/imxrt/start/flash-flexspi-config.c
@@ -43,7 +43,7 @@ const flexspi_nor_config_t imxrt_flexspi_config = {
 .deviceType = kFlexSpiDeviceType_SerialRAM,
 .sflashPadType = kSerialFlash_8Pads,
 .serialClkFreq = kFlexSpiSerialClk_133MHz,
-.sflashA1Size = 

[PATCH rtems 2/2] cpu/armv7m: Fix initialization of MPU regions

[Christian Mauderer]

The write to RBAR didn't have the valid flag set. Therefore the write to
RASR had an influence on the previously set region. That means for
example that if Region 0 had been enabled but 1 should be disabled due
to a size of 0, the previous code would have disabled region 0 instead.

This patch fixes that behaviour.

Close #4450
---
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index a5eaaef418..1803c8d8ca 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -660,7 +660,7 @@ static inline void _ARMV7M_MPU_Set_region(
 rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
 rasr |= _ARMV7M_MPU_Get_region_size(size);
   } else {
-rbar = region;
+rbar = ARMV7M_MPU_RBAR_VALID | region;
 rasr = 0;
   }
 
-- 
2.26.2

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

[PATCH rtems 1/2] cpu/armv7m: Avoid regions with negative size

[Christian Mauderer]

Don't initialze regions that have a negative size (for example due to a
wrong calculation).

Update #4450
---
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index 8f926e826a..a5eaaef418 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -656,7 +656,7 @@ static inline void _ARMV7M_MPU_Set_region(
   RTEMS_OBFUSCATE_VARIABLE(end);
   size = (uintptr_t) end - (uintptr_t) begin;
 
-  if ( size > 0 ) {
+  if ( (uintptr_t) end > (uintptr_t) begin ) {
 rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
 rasr |= _ARMV7M_MPU_Get_region_size(size);
   } else {
-- 
2.26.2

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

Re: Selection of ethernet peripheral by application

[Christian MAUDERER]

Am 02.06.21 um 20:37 schrieb Kinsey Moore:

Hello,

 From what I’ve seen of the various BSPs supported by LibBSD that have 
multiple ethernet peripherals,


only one tends to be chosen and supported. I’ve encountered a situation 
where the majority of platform


examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the 
only/primary ethernet interface and I


need to have the option of selecting a different peripheral as the 
primary interface.


Unfortunately, the current configuration of LibBSD/RTEMS does not allow 
for easy switching among the


available interfaces. The easy one-off option is to just create a BSP 
variant with a little bit of extra logic


to select the correct interface in LibBSD, but this problem seems more 
generally applicable than just


ethernet and just this one BSP. Is the best alternative to configure all 
available devices in


nexus-devices.h and let LibBSD figure it out?

Thanks,
Kinsey



If the problem is with "nexus-devices.h": You can always just add 
further devices or a completely own set of devices in your application. 
For example it should be no problem to use



SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
SYSINIT_MODULE_REFERENCE(wlan_sta);
SYSINIT_MODULE_REFERENCE(wlan_amrr);
SYSINIT_MODULE_REFERENCE(wlan_wep);
SYSINIT_MODULE_REFERENCE(wlan_tkip);
SYSINIT_MODULE_REFERENCE(wlan_ccmp);
SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
SYSINIT_REFERENCE(rtwn_rtl8188eufw);

#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
#define RTEMS_BSD_CONFIG_INIT

#include 


in your application to add WLAN support. You could also remove the 
RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h 
is not included in the rtems-bsd-config.h) and define a different set of 
modules for your application.


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