Re: About locks and concurrency rules for SMP systems

[Richi Dubey]

Thanks for your quick response!

Each scheduler has its own lock. There are a couple of more locks involved.

I understand.

I backtracked a little and found that we have:
_Thread_State_acquire_critical( the_thread, lock_context );

to lock access to thread-specific variables.

_Scheduler_Acquire_critical( scheduler, _context );

to lock access to the current scheduler-specific data structures.

What other locks do we have related to schedulers?

On Wed, Mar 24, 2021 at 1:03 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 24/03/2021 08:07, Richi Dubey wrote:
>
> > How does RTEMS handle cases where two different cores access
> > scheduler-related functions at the same time?
> Each scheduler has its own lock. There are a couple of more locks involved.
> > For ex., Can they access (or modify) the Scheduler_strong_APA_Context
> > <
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/schedulerstrongapa.h#n61>
>
> > at the same time?
> No, unless we have a bug.
>
> --
> 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

About scheduler entry point add_processor

[Richi Dubey]

Hi,

I remember reading somewhere that the add_processor function is only used
when a processor is explicitly added during runtime of an application :p,
Is that correct?Please let me know which test tests/uses this function.

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

[PATCH] Update Strong APA definition

[Richi Dubey]

---
 c-user/scheduling-concepts/smp-schedulers.rst | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/c-user/scheduling-concepts/smp-schedulers.rst 
b/c-user/scheduling-concepts/smp-schedulers.rst
index cfab04f..d8ea725 100644
--- a/c-user/scheduling-concepts/smp-schedulers.rst
+++ b/c-user/scheduling-concepts/smp-schedulers.rst
@@ -58,12 +58,13 @@ actually :math:`2^{63} - 1`.
 
 .. _SchedulerSMPPriorityAffinity:
 
-Arbitrary Processor Affinity Priority SMP Scheduler
+Strong Arbitrary Processor Affinity Priority SMP Scheduler
 ---
 
-A fixed-priority scheduler which uses a table of chains with one chain per
-priority level for the ready tasks.  The maximum priority level is
-configurable.  By default, the maximum priority level is 255 (256 priority
-levels).  This scheduler supports arbitrary task processor affinities.  The
-worst-case run-time complexity of some scheduler operations exceeds
-:math:`O(n)` while :math:`n` is the count of ready tasks.
+A job-level fixed-priority scheduler that supports arbitrary task processor
+affinities and schedules all the tasks optimally, i.e. it schedules the tasks
+in a manner which ensures the lowest total sum of priorities of tasks scheduled
+(which means more higher priority tasks being scheduled), without violating any
+task's processor affinity. By default, the maximum priority level is 255 (256
+priority levels). The worst-case run-time complexity of the scheduler
+operations is upto :math:`O(n)` while :math:`n` is the count of ready tasks.
-- 
2.17.1

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

Re: [PATCH v6 1/2] covoar: Fix NOP execution marking

[Alexander White]

On Thu, Mar 25, 2021 at 9:25 PM Chris Johns  wrote:
>
> On 26/3/21 10:28 am, Alex White wrote:
> > On Thu, Mar 25, 2021 at 6:10 PM Chris Johns  wrote:
> >>
> >> On 26/3/21 8:49 am, Alex White wrote:
> >>> Some NOP instructions were not being marked as executed because they
> >>> are located at the end of uncovered ranges. This has been fixed.
> >>> ---
> >>>  tester/covoar/CoverageMapBase.cc  |  10 +++
> >>>  tester/covoar/CoverageMapBase.h   |   4 ++
> >>>  tester/covoar/DesiredSymbols.cc   |  38 +--
> >>>  tester/covoar/DesiredSymbols.h|  11 +++-
> >>>  tester/covoar/ExecutableInfo.cc   |   2 +-
> >>>  tester/covoar/ExecutableInfo.h|   4 ++
> >>>  tester/covoar/ObjdumpProcessor.cc | 105 ++
> >>>  7 files changed, 138 insertions(+), 36 deletions(-)
> >>>
> >>> diff --git a/tester/covoar/CoverageMapBase.cc 
> >>> b/tester/covoar/CoverageMapBase.cc
> >>> index ad0080d..6ca5cf7 100644
> >>> --- a/tester/covoar/CoverageMapBase.cc
> >>> +++ b/tester/covoar/CoverageMapBase.cc
> >>> @@ -142,6 +142,11 @@ namespace Coverage {
> >>>  return size;
> >>>}
> >>>
> >>> +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
> >>> +  {
> >>> +return Ranges.at(index).size();
> >>> +  }
> >>> +
> >>>bool CoverageMapBase::getBeginningOfInstruction(
> >>>  uint32_t  address,
> >>>  uint32_t* beginning
> >>> @@ -178,6 +183,11 @@ namespace Coverage {
> >>>  return Ranges.front().lowAddress;
> >>>}
> >>>
> >>> +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
> >>> +  {
> >>> +return Ranges.at(index).lowAddress;
> >>> +  }
> >>> +
> >>>bool CoverageMapBase::getRange( uint32_t address, AddressRange& range 
> >>> ) const
> >>>{
> >>>  for ( auto r : Ranges ) {
> >>> diff --git a/tester/covoar/CoverageMapBase.h 
> >>> b/tester/covoar/CoverageMapBase.h
> >>> index 6ad76d3..a58c696 100644
> >>> --- a/tester/covoar/CoverageMapBase.h
> >>> +++ b/tester/covoar/CoverageMapBase.h
> >>> @@ -156,6 +156,8 @@ namespace Coverage {
> >>>   */
> >>>  int32_t getFirstLowAddress() const;
> >>>
> >>> +uint32_t getLowAddressOfRange( size_t index ) const;
> >>> +
> >>>  /*!
> >>>   *  This method returns true and sets the address range if
> >>>   *  the address falls with the bounds of an address range
> >>> @@ -177,6 +179,8 @@ namespace Coverage {
> >>>   */
> >>>  uint32_t getSize() const;
> >>>
> >>> +uint32_t getSizeOfRange( size_t index ) const;
> >>> +
> >>>  /*!
> >>>   *  This method returns the address of the beginning of the
> >>>   *  instruction that contains the specified address.
> >>> diff --git a/tester/covoar/DesiredSymbols.cc 
> >>> b/tester/covoar/DesiredSymbols.cc
> >>> index b9a5bb7..c97b25c 100644
> >>> --- a/tester/covoar/DesiredSymbols.cc
> >>> +++ b/tester/covoar/DesiredSymbols.cc
> >>> @@ -142,7 +142,7 @@ namespace Coverage {
> >>>CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
> >>>if (theCoverageMap)
> >>>{
> >>> -// Increment the total sizeInBytes byt the bytes in the symbol
> >>> +// Increment the total sizeInBytes by the bytes in the symbol
> >>>  stats.sizeInBytes += s.second.stats.sizeInBytes;
> >>>
> >>>  // Now scan through the coverage map of this symbol.
> >>> @@ -202,6 +202,26 @@ namespace Coverage {
> >>>  uint32_t count;
> >>>
> >>>  // Mark NOPs as executed
> >>> +a = s.second.stats.sizeInBytes - 1;
> >>> +count = 0;
> >>> +while (a > 0) {
> >>> +  if (theCoverageMap->isStartOfInstruction( a )) {
> >>> +break;
> >>> +  }
> >>> +
> >>> +  count++;
> >>> +
> >>> +  if (theCoverageMap->isNop( a )) {
> >>> +for (la = a; la < (a + count); la++) {
> >>> +  theCoverageMap->setWasExecuted( la );
> >>> +}
> >>> +
> >>> +count = 0;
> >>> +  }
> >>> +
> >>> +  a--;
> >>> +}
> >>> +
> >>>  endAddress = s.second.stats.sizeInBytes - 1;
> >>>  a = 0;
> >>>  while (a < endAddress) {
> >>> @@ -223,12 +243,13 @@ namespace Coverage {
> >>>ha++;
> >>>if ( ha >= endAddress )
> >>>  break;
> >>> -} while ( !theCoverageMap->isStartOfInstruction( ha ) );
> >>> +} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> >>> +  theCoverageMap->isNop( ha ) );
> >>>a = ha;
> >>>  }
> >>>
> >>>  // Now scan through the coverage map of this symbol.
> >>> -endAddress = s.second.stats.sizeInBytes - 1;
> >>> +endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
> >>>  a = 0;
> >>>  while (a <= endAddress) {
> >>>// If an address was NOT executed, find consecutive unexecuted
> >>> @@ -316,7 +337,8 @@ namespace Coverage {
> >>>void 

Re: [PATCH v6 1/2] covoar: Fix NOP execution marking

[Chris Johns]

On 26/3/21 10:28 am, Alex White wrote:
> On Thu, Mar 25, 2021 at 6:10 PM Chris Johns  wrote:
>>
>> On 26/3/21 8:49 am, Alex White wrote:
>>> Some NOP instructions were not being marked as executed because they
>>> are located at the end of uncovered ranges. This has been fixed.
>>> ---
>>>  tester/covoar/CoverageMapBase.cc  |  10 +++
>>>  tester/covoar/CoverageMapBase.h   |   4 ++
>>>  tester/covoar/DesiredSymbols.cc   |  38 +--
>>>  tester/covoar/DesiredSymbols.h    |  11 +++-
>>>  tester/covoar/ExecutableInfo.cc   |   2 +-
>>>  tester/covoar/ExecutableInfo.h    |   4 ++
>>>  tester/covoar/ObjdumpProcessor.cc | 105 ++
>>>  7 files changed, 138 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/tester/covoar/CoverageMapBase.cc 
>>> b/tester/covoar/CoverageMapBase.cc
>>> index ad0080d..6ca5cf7 100644
>>> --- a/tester/covoar/CoverageMapBase.cc
>>> +++ b/tester/covoar/CoverageMapBase.cc
>>> @@ -142,6 +142,11 @@ namespace Coverage {
>>>      return size;
>>>    }
>>>
>>> +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
>>> +  {
>>> +    return Ranges.at(index).size();
>>> +  }
>>> +
>>>    bool CoverageMapBase::getBeginningOfInstruction(
>>>      uint32_t  address,
>>>      uint32_t* beginning
>>> @@ -178,6 +183,11 @@ namespace Coverage {
>>>      return Ranges.front().lowAddress;
>>>    }
>>>
>>> +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
>>> +  {
>>> +    return Ranges.at(index).lowAddress;
>>> +  }
>>> +
>>>    bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) 
>>> const
>>>    {
>>>      for ( auto r : Ranges ) {
>>> diff --git a/tester/covoar/CoverageMapBase.h 
>>> b/tester/covoar/CoverageMapBase.h
>>> index 6ad76d3..a58c696 100644
>>> --- a/tester/covoar/CoverageMapBase.h
>>> +++ b/tester/covoar/CoverageMapBase.h
>>> @@ -156,6 +156,8 @@ namespace Coverage {
>>>       */
>>>      int32_t getFirstLowAddress() const;
>>>
>>> +    uint32_t getLowAddressOfRange( size_t index ) const;
>>> +
>>>      /*!
>>>       *  This method returns true and sets the address range if
>>>       *  the address falls with the bounds of an address range
>>> @@ -177,6 +179,8 @@ namespace Coverage {
>>>       */
>>>      uint32_t getSize() const;
>>>
>>> +    uint32_t getSizeOfRange( size_t index ) const;
>>> +
>>>      /*!
>>>       *  This method returns the address of the beginning of the
>>>       *  instruction that contains the specified address.
>>> diff --git a/tester/covoar/DesiredSymbols.cc 
>>> b/tester/covoar/DesiredSymbols.cc
>>> index b9a5bb7..c97b25c 100644
>>> --- a/tester/covoar/DesiredSymbols.cc
>>> +++ b/tester/covoar/DesiredSymbols.cc
>>> @@ -142,7 +142,7 @@ namespace Coverage {
>>>        CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
>>>        if (theCoverageMap)
>>>        {
>>> -        // Increment the total sizeInBytes byt the bytes in the symbol
>>> +        // Increment the total sizeInBytes by the bytes in the symbol
>>>          stats.sizeInBytes += s.second.stats.sizeInBytes;
>>>
>>>          // Now scan through the coverage map of this symbol.
>>> @@ -202,6 +202,26 @@ namespace Coverage {
>>>          uint32_t count;
>>>
>>>          // Mark NOPs as executed
>>> +        a = s.second.stats.sizeInBytes - 1;
>>> +        count = 0;
>>> +        while (a > 0) {
>>> +          if (theCoverageMap->isStartOfInstruction( a )) {
>>> +            break;
>>> +          }
>>> +
>>> +          count++;
>>> +
>>> +          if (theCoverageMap->isNop( a )) {
>>> +            for (la = a; la < (a + count); la++) {
>>> +              theCoverageMap->setWasExecuted( la );
>>> +            }
>>> +
>>> +            count = 0;
>>> +          }
>>> +
>>> +          a--;
>>> +        }
>>> +
>>>          endAddress = s.second.stats.sizeInBytes - 1;
>>>          a = 0;
>>>          while (a < endAddress) {
>>> @@ -223,12 +243,13 @@ namespace Coverage {
>>>                ha++;
>>>                if ( ha >= endAddress )
>>>                  break;
>>> -            } while ( !theCoverageMap->isStartOfInstruction( ha ) );
>>> +            } while ( !theCoverageMap->isStartOfInstruction( ha ) ||
>>> +                      theCoverageMap->isNop( ha ) );
>>>            a = ha;
>>>          }
>>>
>>>          // Now scan through the coverage map of this symbol.
>>> -        endAddress = s.second.stats.sizeInBytes - 1;
>>> +        endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
>>>          a = 0;
>>>          while (a <= endAddress) {
>>>            // If an address was NOT executed, find consecutive unexecuted
>>> @@ -316,7 +337,8 @@ namespace Coverage {
>>>    void DesiredSymbols::createCoverageMap(
>>>      const std::string& exefileName,
>>>      const std::string& symbolName,
>>> -    uint32_t           size
>>> +    uint32_t           size,
>>> +    uint32_t           sizeWithoutNops
>>>    )
>>>    {
>>>      CoverageMapBase* aCoverageMap;
>>> @@ -354,9 +376,10 @@ namespace Coverage {
>>>    

Re: GSoC Project : Package Micro-python

[Joel Sherrill]

On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom  wrote:

> On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan 
> wrote:
> >
> >
> >
> > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom  wrote:
> >>
> >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan 
> wrote:
> >> >
> >> >
> >> > Apologies for the late reply.
> >> >
> >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom 
> wrote:
> >> >>>
> >> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill 
> wrote:
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom 
> wrote:
> >> >>> >>
> >> >>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> >> >>> >> >
> >> >>> >> > Hello Everyone,
> >> >>> >> > I wanted to take Packaging Micro Python up as GSOC project
> this summer and the project will also include packaging LUA and picoC
> >> >>> >> > The ticket for Micro Python  :
> https://devel.rtems.org/ticket/4349
> >> >>> >> > What would be the complete Scope of the project?
> >> >>> >> > And what would be a good starting point?
> >> >>> >> >
> >> >>> >>
> >> >>> >> Well, I guess Joel must have described the task, so I'll leave
> it to
> >> >>> >> him to fill in some more details.
> >> >>> >>
> >> >>> >> Adding RSB packages may be not sufficient coding work for GSoC.
> It is
> >> >>> >> important in the proposal to identify what would be the coding
> >> >>> >> activities involved in this project. For example, we know from
> >> >>> >> experience that Lua can just be built from some minor tailoring
> of its
> >> >>> >> Makefile, so the package is very straightforward. However, the
> >> >>> >> projects you mention are scripting environments, so maybe
> creating a
> >> >>> >> framework in RTEMS for a "shell/intepreter" that can be built as
> an
> >> >>> >> add-on by RSB would be a proper way to scope this effort
> >> >
> >> > Packaging might not be a lot of coding part but adding its
> documentation and its example would be a very iterative and time consuming
> process.
> >>
> >> Remember that code is what counts, while we expect the other stuff to
> >> come along too, you don't want to be doing 90% doco and 10% code. Just
> >> keep it in mind.
> >
> > What would be a good inclusion to this project ?
> > I was thinking long double support since I worked on porting POSIX
> functions I might find it easier.
> > But it might interfere with matt's project if I understand that project
> correctly.
>
> Right, please don't include that. You'll want to think/talk through
> (with Joel, maybe) what could be good code contributions. If the RSB
> packaging is fairly minimal, then creating a suite of examples might
> be one way to increase the SLOC contributions. I also think there is
> merit to the idea of creating a "plug-in" way to add shells to RTEMS.
> Maybe even refactoring our current shell out to a add-on package then.
> Just a thought.
>

I'd rather see two languages with good packaging, examples for RTEMS use
cases, and documentation. It's a fair project.

If you get through those, we can find another language. TCL probably. I
don't expect Forth or  LISP to be high on the list. Lol

>
> >>
> >>
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> > I agree that Lua and Micropython should build easy but I had more
> >> >>> > in mind.
> >> >>> >
> >> >>> > The full project was language stacks for RTEMS with a better user
> >> >>> > experience for Micropython, Lua, Tcl, etc although I am not sure
> what
> >> >>> > etc would entail. I am not sure all three can be completed in the
> new
> >> >>> > GSoC timeframe. All would follow the same pattern:
> >> >
> >> > Etc can be managed while framing the proposal according to how time
> is being managed.
> >> >>>
> >> >>> >
> >> >>> > + RSB package offering a reasonable default and access to
> configuration
> >> >>> > + Examples including at least bare embedded, use of custom
> commands,
> >> >>> > and integrating with RTEMS shell commands Perhaps  interactive
> use with
> >> >>> > command line history and editing integrated if we have that as a
> library now.
> >> >>> > + Documentation specific to RTEMS and the examples
> >> >>> >
> >> >>> > I imagined completely parallel kits for each embedded language we
> wanted
> >> >>> > to support.
> >> >>> >
> >> >>> > Does that help? Should he plan on Micropython and Lua?
> >> >>> >
> >> >>>
> >> >>> Sure. Lua should be easy way to get started and develop the
> >> >>> framework/infrastructure side in Phase 1. Phase 2 could be extension
> >> >>> to micropython / other scripting languages.
> >> >
> >> > Since all the languages will have a similar pattern complex work can
> be put in phase 2.
> >> > From my past experience, it is the part when most work is done :)
> >>
> >> True, but for repeat students, we do expect a bit more acceleration in
> >> the first phase. Usually, we want to see code merged in phase 1 by
> >> repeat students. Just a reminder that the bar is 

Re: [PATCH v6 2/2] covoar/Target_i386: Add NOP patterns

[Gedare Bloom]

this patch is still fine

On Thu, Mar 25, 2021 at 3:50 PM Alex White  wrote:
>
> A couple of NOP patterns found with the pc686 BSP were not detected.
> This has been fixed.
> ---
>  tester/covoar/Target_i386.cc | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc
> index e0c9c0f..4567c1e 100644
> --- a/tester/covoar/Target_i386.cc
> +++ b/tester/covoar/Target_i386.cc
> @@ -87,6 +87,15 @@ namespace Target {
>size = 3;
>return true;
>  }
> +if (!strncmp( [strlen(line)-28], "lea0x0(%esi,%eiz,1),%esi", 
> 28)) {
> +  // Could be 4 or 7 bytes of padding.
> +  if (!strncmp( [strlen(line)-32], "00", 2)) {
> +size = 7;
> +  } else {
> +size = 4;
> +  }
> +  return true;
> +}
>
>  return false;
>}
> --
> 2.27.0
>
> ___
> 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 v6 1/2] covoar: Fix NOP execution marking

[Alex White]

On Thu, Mar 25, 2021 at 6:10 PM Chris Johns  wrote:
>
> On 26/3/21 8:49 am, Alex White wrote:
> > Some NOP instructions were not being marked as executed because they
> > are located at the end of uncovered ranges. This has been fixed.
> > ---
> >  tester/covoar/CoverageMapBase.cc  |  10 +++
> >  tester/covoar/CoverageMapBase.h   |   4 ++
> >  tester/covoar/DesiredSymbols.cc   |  38 +--
> >  tester/covoar/DesiredSymbols.h    |  11 +++-
> >  tester/covoar/ExecutableInfo.cc   |   2 +-
> >  tester/covoar/ExecutableInfo.h    |   4 ++
> >  tester/covoar/ObjdumpProcessor.cc | 105 ++
> >  7 files changed, 138 insertions(+), 36 deletions(-)
> >
> > diff --git a/tester/covoar/CoverageMapBase.cc 
> > b/tester/covoar/CoverageMapBase.cc
> > index ad0080d..6ca5cf7 100644
> > --- a/tester/covoar/CoverageMapBase.cc
> > +++ b/tester/covoar/CoverageMapBase.cc
> > @@ -142,6 +142,11 @@ namespace Coverage {
> >      return size;
> >    }
> > 
> > +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
> > +  {
> > +    return Ranges.at(index).size();
> > +  }
> > +
> >    bool CoverageMapBase::getBeginningOfInstruction(
> >      uint32_t  address,
> >      uint32_t* beginning
> > @@ -178,6 +183,11 @@ namespace Coverage {
> >      return Ranges.front().lowAddress;
> >    }
> > 
> > +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
> > +  {
> > +    return Ranges.at(index).lowAddress;
> > +  }
> > +
> >    bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) 
> > const
> >    {
> >      for ( auto r : Ranges ) {
> > diff --git a/tester/covoar/CoverageMapBase.h 
> > b/tester/covoar/CoverageMapBase.h
> > index 6ad76d3..a58c696 100644
> > --- a/tester/covoar/CoverageMapBase.h
> > +++ b/tester/covoar/CoverageMapBase.h
> > @@ -156,6 +156,8 @@ namespace Coverage {
> >       */
> >      int32_t getFirstLowAddress() const;
> > 
> > +    uint32_t getLowAddressOfRange( size_t index ) const;
> > +
> >      /*!
> >       *  This method returns true and sets the address range if
> >       *  the address falls with the bounds of an address range
> > @@ -177,6 +179,8 @@ namespace Coverage {
> >       */
> >      uint32_t getSize() const;
> > 
> > +    uint32_t getSizeOfRange( size_t index ) const;
> > +
> >      /*!
> >       *  This method returns the address of the beginning of the
> >       *  instruction that contains the specified address.
> > diff --git a/tester/covoar/DesiredSymbols.cc 
> > b/tester/covoar/DesiredSymbols.cc
> > index b9a5bb7..c97b25c 100644
> > --- a/tester/covoar/DesiredSymbols.cc
> > +++ b/tester/covoar/DesiredSymbols.cc
> > @@ -142,7 +142,7 @@ namespace Coverage {
> >        CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
> >        if (theCoverageMap)
> >        {
> > -        // Increment the total sizeInBytes byt the bytes in the symbol
> > +        // Increment the total sizeInBytes by the bytes in the symbol
> >          stats.sizeInBytes += s.second.stats.sizeInBytes;
> > 
> >          // Now scan through the coverage map of this symbol.
> > @@ -202,6 +202,26 @@ namespace Coverage {
> >          uint32_t count;
> > 
> >          // Mark NOPs as executed
> > +        a = s.second.stats.sizeInBytes - 1;
> > +        count = 0;
> > +        while (a > 0) {
> > +          if (theCoverageMap->isStartOfInstruction( a )) {
> > +            break;
> > +          }
> > +
> > +          count++;
> > +
> > +          if (theCoverageMap->isNop( a )) {
> > +            for (la = a; la < (a + count); la++) {
> > +              theCoverageMap->setWasExecuted( la );
> > +            }
> > +
> > +            count = 0;
> > +          }
> > +
> > +          a--;
> > +        }
> > +
> >          endAddress = s.second.stats.sizeInBytes - 1;
> >          a = 0;
> >          while (a < endAddress) {
> > @@ -223,12 +243,13 @@ namespace Coverage {
> >                ha++;
> >                if ( ha >= endAddress )
> >                  break;
> > -            } while ( !theCoverageMap->isStartOfInstruction( ha ) );
> > +            } while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> > +                      theCoverageMap->isNop( ha ) );
> >            a = ha;
> >          }
> > 
> >          // Now scan through the coverage map of this symbol.
> > -        endAddress = s.second.stats.sizeInBytes - 1;
> > +        endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
> >          a = 0;
> >          while (a <= endAddress) {
> >            // If an address was NOT executed, find consecutive unexecuted
> > @@ -316,7 +337,8 @@ namespace Coverage {
> >    void DesiredSymbols::createCoverageMap(
> >      const std::string& exefileName,
> >      const std::string& symbolName,
> > -    uint32_t           size
> > +    uint32_t           size,
> > +    uint32_t           sizeWithoutNops
> >    )
> >    {
> >      CoverageMapBase* aCoverageMap;
> > @@ -354,9 +376,10 @@ namespace Coverage {
> >                    << '/' << size << 

Re: [PATCH v6 1/2] covoar: Fix NOP execution marking

[Chris Johns]

On 26/3/21 8:49 am, Alex White wrote:
> Some NOP instructions were not being marked as executed because they
> are located at the end of uncovered ranges. This has been fixed.
> ---
>  tester/covoar/CoverageMapBase.cc  |  10 +++
>  tester/covoar/CoverageMapBase.h   |   4 ++
>  tester/covoar/DesiredSymbols.cc   |  38 +--
>  tester/covoar/DesiredSymbols.h|  11 +++-
>  tester/covoar/ExecutableInfo.cc   |   2 +-
>  tester/covoar/ExecutableInfo.h|   4 ++
>  tester/covoar/ObjdumpProcessor.cc | 105 ++
>  7 files changed, 138 insertions(+), 36 deletions(-)
> 
> diff --git a/tester/covoar/CoverageMapBase.cc 
> b/tester/covoar/CoverageMapBase.cc
> index ad0080d..6ca5cf7 100644
> --- a/tester/covoar/CoverageMapBase.cc
> +++ b/tester/covoar/CoverageMapBase.cc
> @@ -142,6 +142,11 @@ namespace Coverage {
>  return size;
>}
>  
> +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
> +  {
> +return Ranges.at(index).size();
> +  }
> +
>bool CoverageMapBase::getBeginningOfInstruction(
>  uint32_t  address,
>  uint32_t* beginning
> @@ -178,6 +183,11 @@ namespace Coverage {
>  return Ranges.front().lowAddress;
>}
>  
> +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
> +  {
> +return Ranges.at(index).lowAddress;
> +  }
> +
>bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) 
> const
>{
>  for ( auto r : Ranges ) {
> diff --git a/tester/covoar/CoverageMapBase.h b/tester/covoar/CoverageMapBase.h
> index 6ad76d3..a58c696 100644
> --- a/tester/covoar/CoverageMapBase.h
> +++ b/tester/covoar/CoverageMapBase.h
> @@ -156,6 +156,8 @@ namespace Coverage {
>   */
>  int32_t getFirstLowAddress() const;
>  
> +uint32_t getLowAddressOfRange( size_t index ) const;
> +
>  /*!
>   *  This method returns true and sets the address range if
>   *  the address falls with the bounds of an address range
> @@ -177,6 +179,8 @@ namespace Coverage {
>   */
>  uint32_t getSize() const;
>  
> +uint32_t getSizeOfRange( size_t index ) const;
> +
>  /*!
>   *  This method returns the address of the beginning of the
>   *  instruction that contains the specified address.
> diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
> index b9a5bb7..c97b25c 100644
> --- a/tester/covoar/DesiredSymbols.cc
> +++ b/tester/covoar/DesiredSymbols.cc
> @@ -142,7 +142,7 @@ namespace Coverage {
>CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
>if (theCoverageMap)
>{
> -// Increment the total sizeInBytes byt the bytes in the symbol
> +// Increment the total sizeInBytes by the bytes in the symbol
>  stats.sizeInBytes += s.second.stats.sizeInBytes;
>  
>  // Now scan through the coverage map of this symbol.
> @@ -202,6 +202,26 @@ namespace Coverage {
>  uint32_t count;
>  
>  // Mark NOPs as executed
> +a = s.second.stats.sizeInBytes - 1;
> +count = 0;
> +while (a > 0) {
> +  if (theCoverageMap->isStartOfInstruction( a )) {
> +break;
> +  }
> +
> +  count++;
> +
> +  if (theCoverageMap->isNop( a )) {
> +for (la = a; la < (a + count); la++) {
> +  theCoverageMap->setWasExecuted( la );
> +}
> +
> +count = 0;
> +  }
> +
> +  a--;
> +}
> +
>  endAddress = s.second.stats.sizeInBytes - 1;
>  a = 0;
>  while (a < endAddress) {
> @@ -223,12 +243,13 @@ namespace Coverage {
>ha++;
>if ( ha >= endAddress )
>  break;
> -} while ( !theCoverageMap->isStartOfInstruction( ha ) );
> +} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> +  theCoverageMap->isNop( ha ) );
>a = ha;
>  }
>  
>  // Now scan through the coverage map of this symbol.
> -endAddress = s.second.stats.sizeInBytes - 1;
> +endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
>  a = 0;
>  while (a <= endAddress) {
>// If an address was NOT executed, find consecutive unexecuted
> @@ -316,7 +337,8 @@ namespace Coverage {
>void DesiredSymbols::createCoverageMap(
>  const std::string& exefileName,
>  const std::string& symbolName,
> -uint32_t   size
> +uint32_t   size,
> +uint32_t   sizeWithoutNops
>)
>{
>  CoverageMapBase* aCoverageMap;
> @@ -354,9 +376,10 @@ namespace Coverage {
><< '/' << size << ')'
><< std::endl;
>  
> -if ( itr->second.stats.sizeInBytes < size )
> +if ( itr->second.stats.sizeInBytes < size ) {
>itr->second.stats.sizeInBytes = size;
> -else
> +  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
> +} else
>  

[PATCH v6 1/2] covoar: Fix NOP execution marking

[Alex White]

Some NOP instructions were not being marked as executed because they
are located at the end of uncovered ranges. This has been fixed.
---
 tester/covoar/CoverageMapBase.cc  |  10 +++
 tester/covoar/CoverageMapBase.h   |   4 ++
 tester/covoar/DesiredSymbols.cc   |  38 +--
 tester/covoar/DesiredSymbols.h|  11 +++-
 tester/covoar/ExecutableInfo.cc   |   2 +-
 tester/covoar/ExecutableInfo.h|   4 ++
 tester/covoar/ObjdumpProcessor.cc | 105 ++
 7 files changed, 138 insertions(+), 36 deletions(-)

diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index ad0080d..6ca5cf7 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -142,6 +142,11 @@ namespace Coverage {
 return size;
   }
 
+  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
+  {
+return Ranges.at(index).size();
+  }
+
   bool CoverageMapBase::getBeginningOfInstruction(
 uint32_t  address,
 uint32_t* beginning
@@ -178,6 +183,11 @@ namespace Coverage {
 return Ranges.front().lowAddress;
   }
 
+  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
+  {
+return Ranges.at(index).lowAddress;
+  }
+
   bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) const
   {
 for ( auto r : Ranges ) {
diff --git a/tester/covoar/CoverageMapBase.h b/tester/covoar/CoverageMapBase.h
index 6ad76d3..a58c696 100644
--- a/tester/covoar/CoverageMapBase.h
+++ b/tester/covoar/CoverageMapBase.h
@@ -156,6 +156,8 @@ namespace Coverage {
  */
 int32_t getFirstLowAddress() const;
 
+uint32_t getLowAddressOfRange( size_t index ) const;
+
 /*!
  *  This method returns true and sets the address range if
  *  the address falls with the bounds of an address range
@@ -177,6 +179,8 @@ namespace Coverage {
  */
 uint32_t getSize() const;
 
+uint32_t getSizeOfRange( size_t index ) const;
+
 /*!
  *  This method returns the address of the beginning of the
  *  instruction that contains the specified address.
diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
index b9a5bb7..c97b25c 100644
--- a/tester/covoar/DesiredSymbols.cc
+++ b/tester/covoar/DesiredSymbols.cc
@@ -142,7 +142,7 @@ namespace Coverage {
   CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
   if (theCoverageMap)
   {
-// Increment the total sizeInBytes byt the bytes in the symbol
+// Increment the total sizeInBytes by the bytes in the symbol
 stats.sizeInBytes += s.second.stats.sizeInBytes;
 
 // Now scan through the coverage map of this symbol.
@@ -202,6 +202,26 @@ namespace Coverage {
 uint32_t count;
 
 // Mark NOPs as executed
+a = s.second.stats.sizeInBytes - 1;
+count = 0;
+while (a > 0) {
+  if (theCoverageMap->isStartOfInstruction( a )) {
+break;
+  }
+
+  count++;
+
+  if (theCoverageMap->isNop( a )) {
+for (la = a; la < (a + count); la++) {
+  theCoverageMap->setWasExecuted( la );
+}
+
+count = 0;
+  }
+
+  a--;
+}
+
 endAddress = s.second.stats.sizeInBytes - 1;
 a = 0;
 while (a < endAddress) {
@@ -223,12 +243,13 @@ namespace Coverage {
   ha++;
   if ( ha >= endAddress )
 break;
-} while ( !theCoverageMap->isStartOfInstruction( ha ) );
+} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
+  theCoverageMap->isNop( ha ) );
   a = ha;
 }
 
 // Now scan through the coverage map of this symbol.
-endAddress = s.second.stats.sizeInBytes - 1;
+endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
 a = 0;
 while (a <= endAddress) {
   // If an address was NOT executed, find consecutive unexecuted
@@ -316,7 +337,8 @@ namespace Coverage {
   void DesiredSymbols::createCoverageMap(
 const std::string& exefileName,
 const std::string& symbolName,
-uint32_t   size
+uint32_t   size,
+uint32_t   sizeWithoutNops
   )
   {
 CoverageMapBase* aCoverageMap;
@@ -354,9 +376,10 @@ namespace Coverage {
   << '/' << size << ')'
   << std::endl;
 
-if ( itr->second.stats.sizeInBytes < size )
+if ( itr->second.stats.sizeInBytes < size ) {
   itr->second.stats.sizeInBytes = size;
-else
+  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
+} else
   size = itr->second.stats.sizeInBytes;
   }
 }
@@ -376,6 +399,7 @@ namespace Coverage {
 );
   itr->second.unifiedCoverageMap = aCoverageMap;
   itr->second.stats.sizeInBytes = size;
+  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
 }
   }
 
@@ -479,7 +503,7 @@ namespace 

[PATCH v6 2/2] covoar/Target_i386: Add NOP patterns

[Alex White]

A couple of NOP patterns found with the pc686 BSP were not detected.
This has been fixed.
---
 tester/covoar/Target_i386.cc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc
index e0c9c0f..4567c1e 100644
--- a/tester/covoar/Target_i386.cc
+++ b/tester/covoar/Target_i386.cc
@@ -87,6 +87,15 @@ namespace Target {
   size = 3;
   return true;
 }
+if (!strncmp( [strlen(line)-28], "lea0x0(%esi,%eiz,1),%esi", 28)) 
{
+  // Could be 4 or 7 bytes of padding.
+  if (!strncmp( [strlen(line)-32], "00", 2)) {
+size = 7;
+  } else {
+size = 4;
+  }
+  return true;
+}
 
 return false;
   }
-- 
2.27.0

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

[PATCH v6 0/2] Fix NOP recognition

[Alex White]

v6:
- Consolidate loop conditionals in Coverage::finalizeSymbol()

v5:
- Fix missing std::dec at the end of error message printing in
  Coverage::finalizeSymbol()

v4:
- Add specialized CoverageMapNotFoundError exception class to ExecutableInfo
- Catch ExecutableInfo::CoverageMapNotFoundError in Coverage::finalizeSymbol()

v3:
- Fix double increment of rangeIndex in Coverage::finalizeSymbol()

v2:
- Fix leftover debugging code in Coverage::finalizeSymbol()

This patch set fixes a couple cases where NOP instructions were showing
up as unexecuted in coverage reports.

Alex White (2):
  covoar: Fix NOP execution marking
  covoar/Target_i386: Add NOP patterns

 tester/covoar/CoverageMapBase.cc  |  10 +++
 tester/covoar/CoverageMapBase.h   |   4 ++
 tester/covoar/DesiredSymbols.cc   |  38 +--
 tester/covoar/DesiredSymbols.h|  11 +++-
 tester/covoar/ExecutableInfo.cc   |   2 +-
 tester/covoar/ExecutableInfo.h|   4 ++
 tester/covoar/ObjdumpProcessor.cc | 105 ++
 tester/covoar/Target_i386.cc  |   9 +++
 8 files changed, 147 insertions(+), 36 deletions(-)

-- 
2.27.0

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

Re: [PATCH v5 1/2] covoar: Fix NOP execution marking

[Gedare Bloom]

On Thu, Mar 25, 2021 at 2:42 PM Alex White  wrote:
>
> On Thu, Mar 25, 2021 at 2:38 PM Gedare Bloom  wrote:
> >
> > On Thu, Mar 25, 2021 at 10:05 AM Joel Sherrill  wrote:
> > >
> > >
> > >
> > > On Thu, Mar 25, 2021 at 10:42 AM Gedare Bloom  wrote:
> > >>
> > >> On Thu, Mar 18, 2021 at 12:05 PM Alex White  
> > >> wrote:
> > >> > -// Mark the start of each instruction in the coverage map.
> > >> > -for (auto& instruction : instructions) {
> > >> > -  coverageMap.setIsStartOfInstruction( instruction.address );
> > >> > -}
> > >> > +  // Find the address of the first instruction.
> > >> > +  for (auto& line : instructions) {
> > >> > +if (!line.isInstruction) {
> > >> > +  continue;
> > >> > +}
> > >> > +
> > >> > +firstInstructionAddress = line.address;
> > >> > +break;
> > >> > +  }
> > >> This is a poorly written loop. Anytime you use continue/break to
> > >> control the loop iteration, something is going awry. You can write
> > >> this code equivalently without any continue or break.
> > >
> > >
> > > This loop is very deliberately constructed not to be a for loop because
> > > you need the ability to break at different points to debug issues. Alex
> > > and I spent hours in this loop debugging which I think would have
> > > been more difficult to debug if all the conditions were in a for loop.
> > > This loop was written to explicitly have breakpoints for various
> > > conditions.
> > >
> > > There have been multiple issues with the information reported with
> > > size/length being at the top of that list. Before Alex found the source
> > > of that (not covoar), it resulted in an infinite loop.
> > >
> > > I suppose it can be changed to a for loop as purer academically but
> > > it loses significantly on ability to set breakpoints and debug if there
> > > ever is an issue again.
> > >
> > > Are you willing to make that trade?
> > >
> >
> > You know that what we debug is often much uglier than what we publish.
> > At least, simplify the logic to let the loop work for you.
> >
> > for (auto& line : instructions) {
> >   if ( line.isInstruction ) {
> > firstInstructionAddress = line.address;
> > break;
> >   }
> > }
>
> I will make this change.
>
> >
> > Using continue/break to control loops is antithetical to using loops,
> > and probably doesn't do the compiler any good.
> >
> > >> > +if (!line.isInstruction) {
> > >> > +  continue;
> > >> > +}
> > >> > +
> > >> > +
> > >> > +break;
> > >> > +  }
> > >>
> > >> > +
> > >> > +  if (firstInstructionAddress == UINT32_MAX) {
> > >> > +std::ostringstream what;
> > >> > +what << "Could not find first instruction address for symbol "
> > >> > +  << symbolName << " in " << executableInfo->getFileName();
> > >> > +throw rld::error( what, "Coverage::finalizeSymbol" );
> > >> > +  }
> > >> > +
> > >> > +  int rangeIndex;
> > >> > +  uint32_t lowAddress = UINT32_MAX;
> > >> > +  for (rangeIndex = 0; ; rangeIndex++) {
> > >> > +lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> > >> > +
> > >> > +if (firstInstructionAddress == lowAddress) {
> > >> > +  break;
> > >> ditto... if you're goin to break the loop on this condition, why not
> > >> use this in your for loop?
> > >> for (rangeIndex = 0; firstInstructionAddress != lowAddress ; 
> > >> rangeIndex++) {
>
> I will make this change, too.
>
> > >>
> > >> > +}
> > >> > +  }
> > >> >
> > >> > -// Create a unified coverage map for the symbol.
> > >> > -SymbolsToAnalyze->createCoverageMap(
> > >> > -  executableInfo->getFileName().c_str(), symbolName, size
> > >> > -);
> > >> > +  uint32_t sizeWithoutNops = 
> > >> > coverageMap.getSizeOfRange(rangeIndex);
> > >> > +  uint32_t size = sizeWithoutNops;
> > >> > +  uint32_t highAddress = lowAddress + size - 1;
> > >> > +  uint32_t computedHighAddress = highAddress;
> > >> > +
> > >> > +  // Find the high address as reported by the address of the last 
> > >> > NOP
> > >> > +  // instruction. This ensures that NOPs get marked as executed 
> > >> > later.
> > >> > +  for (auto instruction = instructions.rbegin();
> > >> > +  instruction != instructions.rend();
> > >> > +  instruction++) {
> > >> > +if (instruction->isInstruction) {
> > >> > +  if (instruction->isNop) {
> > >> > +computedHighAddress = instruction->address + 
> > >> > instruction->nopSize;
> > >> > +  }
> > >> > +  break;
> > >> Here too.
>
> I'm not sure I see a more clear way to write this loop while
> eliminating the `break` statement.
>
> Do you have a suggestion?
>
no, this one is alright, since you have a special action to take on
the last iteration.

fwiw, the isInstruction and isNop ought to be methods and not directly
accessing boolean variables, but that is just another C'ism nit ;)

> > >> 

RE: [PATCH v5 1/2] covoar: Fix NOP execution marking

[Alex White]

On Thu, Mar 25, 2021 at 2:38 PM Gedare Bloom  wrote:
>
> On Thu, Mar 25, 2021 at 10:05 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Thu, Mar 25, 2021 at 10:42 AM Gedare Bloom  wrote:
> >>
> >> On Thu, Mar 18, 2021 at 12:05 PM Alex White  wrote:
> >> > -    // Mark the start of each instruction in the coverage map.
> >> > -    for (auto& instruction : instructions) {
> >> > -      coverageMap.setIsStartOfInstruction( instruction.address );
> >> > -    }
> >> > +      // Find the address of the first instruction.
> >> > +      for (auto& line : instructions) {
> >> > +        if (!line.isInstruction) {
> >> > +          continue;
> >> > +        }
> >> > +
> >> > +        firstInstructionAddress = line.address;
> >> > +        break;
> >> > +      }
> >> This is a poorly written loop. Anytime you use continue/break to
> >> control the loop iteration, something is going awry. You can write
> >> this code equivalently without any continue or break.
> >
> >
> > This loop is very deliberately constructed not to be a for loop because
> > you need the ability to break at different points to debug issues. Alex
> > and I spent hours in this loop debugging which I think would have
> > been more difficult to debug if all the conditions were in a for loop.
> > This loop was written to explicitly have breakpoints for various
> > conditions.
> >
> > There have been multiple issues with the information reported with
> > size/length being at the top of that list. Before Alex found the source
> > of that (not covoar), it resulted in an infinite loop.
> >
> > I suppose it can be changed to a for loop as purer academically but
> > it loses significantly on ability to set breakpoints and debug if there
> > ever is an issue again.
> >
> > Are you willing to make that trade?
> >
>
> You know that what we debug is often much uglier than what we publish.
> At least, simplify the logic to let the loop work for you.
>
> for (auto& line : instructions) {
>   if ( line.isInstruction ) {
>     firstInstructionAddress = line.address;
>     break;
>   }
> }

I will make this change.

>
> Using continue/break to control loops is antithetical to using loops,
> and probably doesn't do the compiler any good.
>
> >> > +        if (!line.isInstruction) {
> >> > +          continue;
> >> > +        }
> >> > +
> >> > +
> >> > +        break;
> >> > +      }
> >>
> >> > +
> >> > +      if (firstInstructionAddress == UINT32_MAX) {
> >> > +        std::ostringstream what;
> >> > +        what << "Could not find first instruction address for symbol "
> >> > +          << symbolName << " in " << executableInfo->getFileName();
> >> > +        throw rld::error( what, "Coverage::finalizeSymbol" );
> >> > +      }
> >> > +
> >> > +      int rangeIndex;
> >> > +      uint32_t lowAddress = UINT32_MAX;
> >> > +      for (rangeIndex = 0; ; rangeIndex++) {
> >> > +        lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> >> > +
> >> > +        if (firstInstructionAddress == lowAddress) {
> >> > +          break;
> >> ditto... if you're goin to break the loop on this condition, why not
> >> use this in your for loop?
> >> for (rangeIndex = 0; firstInstructionAddress != lowAddress ; rangeIndex++) 
> >> {

I will make this change, too.

> >>
> >> > +        }
> >> > +      }
> >> >
> >> > -    // Create a unified coverage map for the symbol.
> >> > -    SymbolsToAnalyze->createCoverageMap(
> >> > -      executableInfo->getFileName().c_str(), symbolName, size
> >> > -    );
> >> > +      uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
> >> > +      uint32_t size = sizeWithoutNops;
> >> > +      uint32_t highAddress = lowAddress + size - 1;
> >> > +      uint32_t computedHighAddress = highAddress;
> >> > +
> >> > +      // Find the high address as reported by the address of the last 
> >> > NOP
> >> > +      // instruction. This ensures that NOPs get marked as executed 
> >> > later.
> >> > +      for (auto instruction = instructions.rbegin();
> >> > +          instruction != instructions.rend();
> >> > +          instruction++) {
> >> > +        if (instruction->isInstruction) {
> >> > +          if (instruction->isNop) {
> >> > +            computedHighAddress = instruction->address + 
> >> > instruction->nopSize;
> >> > +          }
> >> > +          break;
> >> Here too.

I'm not sure I see a more clear way to write this loop while
eliminating the `break` statement.

Do you have a suggestion?

> >>
> >> > +        }
> >> > +      }
> >> > +
> >> > +      if (highAddress != computedHighAddress) {
> >> > +        std::cerr << "Function's high address differs between DWARF and 
> >> > objdump: "
> >> > +          << symbolName << " (0x" << std::hex << highAddress << " and 
> >> > 0x"
> >> > +          << computedHighAddress - 1 << ")" << std::dec << std::endl;
> >> > +        size = computedHighAddress - lowAddress;
> >> > +      }
> >> > +
> >> > +      // If there are NOT already saved instructions, save them.
> >> > +      

Re: Implicit yield in priority inheritance: bug or feature?

[Gedare Bloom]

On Thu, Mar 25, 2021 at 12:39 PM Sebastian Huber
 wrote:
>
> Hello,
>
> I specify currently the Classic API semaphore obtain/release behaviour.
> This includes the locking protocol. While testing the MrsP and priority
> inheritance protocols I noticed a strange behaviour. When a thread (the
> blocker) gives its priority to the thread of a semaphore owner, then
> this priority is appended to its priority group. If another with the
> same priority as the blocker is ready, then the semaphore obtain will
> yield the processor to this thread and not the owner of the semaphore.
> To me this looks like a bug. There seems to be no test case for this in
> the test suite. I see no test result changes with this patch:
>
> diff --git a/cpukit/score/src/threadchangepriority.c
> b/cpukit/score/src/threadchangepriority.c
>
> index 13e9147916..824a4c41ab 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -214,7 +214,7 @@ void _Thread_Priority_perform_actions(
> the_thread,
> queue,
> the_thread->Wait.operations,
> -  false,
> +  true,
> queue_context
>   );
>
> For MrsP semaphores, this implicit yield is quite bad in some cases,
> since threads blocked on a MrsP semaphore do a busy wait and an implicit
> yield means we could end up in threads doing busy waits instead of
> helping the owner.
>

This is tricky. I had considered this case in the uniprocessor
implementation during the rework to fix the PIP bugs
(https://gedare.github.io/pdf/gadia_verifying_2016.pdf), but we did
not do much to test it or to make any modeling decision about what
should be the correct behavior, in case "Two threads have the same
priority, one has a lower priority than the others." Probably no one
considered this corner case deeply. In general real-time modeling, we
assume one task per priority, while in real systems we allow tasks to
share a priority with the understanding that there is no
prioritization or guarantees among them--the real-time analysis should
treat them as a single group. So in the uniprocessor PIP it doesn't
matter if the inheriting thread runs next or another similarly
high-priority thread runs.

I agree however that the behavior is bad when spinlocks are in use,
and it may be considered a bug in the SMP implementation. Do you know
if any of the academic papers on MrsP address this problem / provide
any guidance for us to consider?

Gedare

> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5 1/2] covoar: Fix NOP execution marking

[Gedare Bloom]

On Thu, Mar 25, 2021 at 10:05 AM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 10:42 AM Gedare Bloom  wrote:
>>
>> On Thu, Mar 18, 2021 at 12:05 PM Alex White  wrote:
>> >
>> > Some NOP instructions were not being marked as executed because they
>> > are located at the end of uncovered ranges. This has been fixed.
>> > ---
>> >  tester/covoar/CoverageMapBase.cc  |  10 +++
>> >  tester/covoar/CoverageMapBase.h   |   4 ++
>> >  tester/covoar/DesiredSymbols.cc   |  38 +--
>> >  tester/covoar/DesiredSymbols.h|  11 ++-
>> >  tester/covoar/ExecutableInfo.cc   |   2 +-
>> >  tester/covoar/ExecutableInfo.h|   4 ++
>> >  tester/covoar/ObjdumpProcessor.cc | 109 +++---
>> >  7 files changed, 142 insertions(+), 36 deletions(-)
>> >
>> > diff --git a/tester/covoar/CoverageMapBase.cc 
>> > b/tester/covoar/CoverageMapBase.cc
>> > index ad0080d..6ca5cf7 100644
>> > --- a/tester/covoar/CoverageMapBase.cc
>> > +++ b/tester/covoar/CoverageMapBase.cc
>> > @@ -142,6 +142,11 @@ namespace Coverage {
>> >  return size;
>> >}
>> >
>> > +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
>> > +  {
>> > +return Ranges.at(index).size();
>> > +  }
>> > +
>> >bool CoverageMapBase::getBeginningOfInstruction(
>> >  uint32_t  address,
>> >  uint32_t* beginning
>> > @@ -178,6 +183,11 @@ namespace Coverage {
>> >  return Ranges.front().lowAddress;
>> >}
>> >
>> > +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
>> > +  {
>> > +return Ranges.at(index).lowAddress;
>> > +  }
>> > +
>> >bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) 
>> > const
>> >{
>> >  for ( auto r : Ranges ) {
>> > diff --git a/tester/covoar/CoverageMapBase.h 
>> > b/tester/covoar/CoverageMapBase.h
>> > index 6ad76d3..a58c696 100644
>> > --- a/tester/covoar/CoverageMapBase.h
>> > +++ b/tester/covoar/CoverageMapBase.h
>> > @@ -156,6 +156,8 @@ namespace Coverage {
>> >   */
>> >  int32_t getFirstLowAddress() const;
>> >
>> > +uint32_t getLowAddressOfRange( size_t index ) const;
>> > +
>> >  /*!
>> >   *  This method returns true and sets the address range if
>> >   *  the address falls with the bounds of an address range
>> > @@ -177,6 +179,8 @@ namespace Coverage {
>> >   */
>> >  uint32_t getSize() const;
>> >
>> > +uint32_t getSizeOfRange( size_t index ) const;
>> > +
>> >  /*!
>> >   *  This method returns the address of the beginning of the
>> >   *  instruction that contains the specified address.
>> > diff --git a/tester/covoar/DesiredSymbols.cc 
>> > b/tester/covoar/DesiredSymbols.cc
>> > index b9a5bb7..c97b25c 100644
>> > --- a/tester/covoar/DesiredSymbols.cc
>> > +++ b/tester/covoar/DesiredSymbols.cc
>> > @@ -142,7 +142,7 @@ namespace Coverage {
>> >CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
>> >if (theCoverageMap)
>> >{
>> > -// Increment the total sizeInBytes byt the bytes in the symbol
>> > +// Increment the total sizeInBytes by the bytes in the symbol
>> >  stats.sizeInBytes += s.second.stats.sizeInBytes;
>> >
>> >  // Now scan through the coverage map of this symbol.
>> > @@ -202,6 +202,26 @@ namespace Coverage {
>> >  uint32_t count;
>> >
>> >  // Mark NOPs as executed
>> > +a = s.second.stats.sizeInBytes - 1;
>> > +count = 0;
>> > +while (a > 0) {
>> > +  if (theCoverageMap->isStartOfInstruction( a )) {
>> > +break;
>> > +  }
>> > +
>> > +  count++;
>> > +
>> > +  if (theCoverageMap->isNop( a )) {
>> > +for (la = a; la < (a + count); la++) {
>> > +  theCoverageMap->setWasExecuted( la );
>> > +}
>> > +
>> > +count = 0;
>> > +  }
>> > +
>> > +  a--;
>> > +}
>> > +
>> >  endAddress = s.second.stats.sizeInBytes - 1;
>> >  a = 0;
>> >  while (a < endAddress) {
>> > @@ -223,12 +243,13 @@ namespace Coverage {
>> >ha++;
>> >if ( ha >= endAddress )
>> >  break;
>> > -} while ( !theCoverageMap->isStartOfInstruction( ha ) );
>> > +} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
>> > +  theCoverageMap->isNop( ha ) );
>> >a = ha;
>> >  }
>> >
>> >  // Now scan through the coverage map of this symbol.
>> > -endAddress = s.second.stats.sizeInBytes - 1;
>> > +endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
>> >  a = 0;
>> >  while (a <= endAddress) {
>> >// If an address was NOT executed, find consecutive unexecuted
>> > @@ -316,7 +337,8 @@ namespace Coverage {
>> >void DesiredSymbols::createCoverageMap(
>> >  const std::string& exefileName,
>> >  const std::string& symbolName,
>> > -uint32_t   size
>> > +uint32_t  

Implicit yield in priority inheritance: bug or feature?

[Sebastian Huber]

Hello,

I specify currently the Classic API semaphore obtain/release behaviour. 
This includes the locking protocol. While testing the MrsP and priority 
inheritance protocols I noticed a strange behaviour. When a thread (the 
blocker) gives its priority to the thread of a semaphore owner, then 
this priority is appended to its priority group. If another with the 
same priority as the blocker is ready, then the semaphore obtain will 
yield the processor to this thread and not the owner of the semaphore. 
To me this looks like a bug. There seems to be no test case for this in 
the test suite. I see no test result changes with this patch:


diff --git a/cpukit/score/src/threadchangepriority.c 
b/cpukit/score/src/threadchangepriority.c


index 13e9147916..824a4c41ab 100644
--- a/cpukit/score/src/threadchangepriority.c
+++ b/cpukit/score/src/threadchangepriority.c
@@ -214,7 +214,7 @@ void _Thread_Priority_perform_actions(
   the_thread,
   queue,
   the_thread->Wait.operations,
-  false,
+  true,
   queue_context
 );

For MrsP semaphores, this implicit yield is quite bad in some cases, 
since threads blocked on a MrsP semaphore do a busy wait and an implicit 
yield means we could end up in threads doing busy waits instead of 
helping the owner.


--
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: Policy for return by reference values in error cases

[Joel Sherrill]

On Thu, Mar 25, 2021, 1:16 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/03/2021 20:21, Gedare Bloom wrote:
>
> >> On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber<
> sebastian.hu...@embedded-brains.de>  wrote:
> >>> On 23/03/2021 18:48, Joel Sherrill wrote:
> >>>
>  My first thought is that I don't like covering up for applications
>  that do the wrong thing.
> > +.5
> >
> >>> This topic just came up recently in a discussion about defensive
> >>> programming. We also test for NULL pointers.
> > +1
> Ok, I will leave it as it is for now unless there is a strong desire to
> change this.
>

Is this one of our small rules in the coding style?

>
> --
> 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: Policy for return by reference values in error cases

[Sebastian Huber]

On 23/03/2021 20:21, Gedare Bloom wrote:


On Tue, Mar 23, 2021 at 12:58 PM Sebastian 
Huber  wrote:

On 23/03/2021 18:48, Joel Sherrill wrote:


My first thought is that I don't like covering up for applications
that do the wrong thing.

+.5


This topic just came up recently in a discussion about defensive
programming. We also test for NULL pointers.

+1
Ok, I will leave it as it is for now unless there is a strong desire to 
change 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 BSP: Add SDMMC-driver (Note: Extends libbsd media01)

[Christian MAUDERER]

Hello Gedare,

Am 25.03.21 um 16:51 schrieb Gedare Bloom:

I'm not confident about assessing the libbsd patches. Hopefully
someone else may comment, but not too many experts in that area yet :)

I guess the one thing that concerned me is filling the media with a
pattern. I suppose one should know what the test does, and that it
will destroy all data on the disk. Maybe that is already
documented/expected, but it should be clear.


I only implemented a command that _can_ be used to fill a file. It 
doesn't do that automatically but is used on the shell. If you call it 
without arguments it will only print a help text. So it's something that 
need activity by the user to destroy the disk ;-)


The command has been useful for me for the last two or three storage 
drivers. Therefore I thought I wanted to put it into the public. It 
isn't really useful as a general purpose command so I put it into 
media01 which is the test that (from my point of view) will be used most 
often to develop storage drivers in libbsd.


Best regards

Christian



On Thu, Mar 25, 2021 at 2:35 AM Christian Mauderer
 wrote:


Hello,

the patch set for RTEMS, libbsd and docs add a SDMMC driver for STM32H7
to libbsd. Note that I added the md5 command to media01 which is useful
when testing storage devices. Beneath that I added a command that can
fill a disk or a file with an incrementing number which - again - can be
useful for testing storage media. The later command is only added to
media01 because I don't think it's a useful general purpose command but
rather a pure test command.

Patches belonging to this set:

RTEMS:
[PATCH rtems 1/2] stm32h7: Add SDMMC modules to clock.
[PATCH rtems 2/2] stm32h7: Add init for sdmmc pins.

libbsd:
[PATCH rtems-libbsd 1/3] testsuite/media01: Enable md5 command
[PATCH rtems-libbsd 2/3] testsuite/media01: Add pattern test.
[PATCH rtems-libbsd 3/3] STM32H7: Add SDMMC driver

docs:
[PATCH rtems-docs] user/bsps: Add STM32H7 SDMMC driver

Best regards

Christian

___
devel mailing list
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: [PATCH v5 1/2] covoar: Fix NOP execution marking

[Joel Sherrill]

On Thu, Mar 25, 2021 at 10:42 AM Gedare Bloom  wrote:

> On Thu, Mar 18, 2021 at 12:05 PM Alex White 
> wrote:
> >
> > Some NOP instructions were not being marked as executed because they
> > are located at the end of uncovered ranges. This has been fixed.
> > ---
> >  tester/covoar/CoverageMapBase.cc  |  10 +++
> >  tester/covoar/CoverageMapBase.h   |   4 ++
> >  tester/covoar/DesiredSymbols.cc   |  38 +--
> >  tester/covoar/DesiredSymbols.h|  11 ++-
> >  tester/covoar/ExecutableInfo.cc   |   2 +-
> >  tester/covoar/ExecutableInfo.h|   4 ++
> >  tester/covoar/ObjdumpProcessor.cc | 109 +++---
> >  7 files changed, 142 insertions(+), 36 deletions(-)
> >
> > diff --git a/tester/covoar/CoverageMapBase.cc
> b/tester/covoar/CoverageMapBase.cc
> > index ad0080d..6ca5cf7 100644
> > --- a/tester/covoar/CoverageMapBase.cc
> > +++ b/tester/covoar/CoverageMapBase.cc
> > @@ -142,6 +142,11 @@ namespace Coverage {
> >  return size;
> >}
> >
> > +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
> > +  {
> > +return Ranges.at(index).size();
> > +  }
> > +
> >bool CoverageMapBase::getBeginningOfInstruction(
> >  uint32_t  address,
> >  uint32_t* beginning
> > @@ -178,6 +183,11 @@ namespace Coverage {
> >  return Ranges.front().lowAddress;
> >}
> >
> > +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
> > +  {
> > +return Ranges.at(index).lowAddress;
> > +  }
> > +
> >bool CoverageMapBase::getRange( uint32_t address, AddressRange& range
> ) const
> >{
> >  for ( auto r : Ranges ) {
> > diff --git a/tester/covoar/CoverageMapBase.h
> b/tester/covoar/CoverageMapBase.h
> > index 6ad76d3..a58c696 100644
> > --- a/tester/covoar/CoverageMapBase.h
> > +++ b/tester/covoar/CoverageMapBase.h
> > @@ -156,6 +156,8 @@ namespace Coverage {
> >   */
> >  int32_t getFirstLowAddress() const;
> >
> > +uint32_t getLowAddressOfRange( size_t index ) const;
> > +
> >  /*!
> >   *  This method returns true and sets the address range if
> >   *  the address falls with the bounds of an address range
> > @@ -177,6 +179,8 @@ namespace Coverage {
> >   */
> >  uint32_t getSize() const;
> >
> > +uint32_t getSizeOfRange( size_t index ) const;
> > +
> >  /*!
> >   *  This method returns the address of the beginning of the
> >   *  instruction that contains the specified address.
> > diff --git a/tester/covoar/DesiredSymbols.cc
> b/tester/covoar/DesiredSymbols.cc
> > index b9a5bb7..c97b25c 100644
> > --- a/tester/covoar/DesiredSymbols.cc
> > +++ b/tester/covoar/DesiredSymbols.cc
> > @@ -142,7 +142,7 @@ namespace Coverage {
> >CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
> >if (theCoverageMap)
> >{
> > -// Increment the total sizeInBytes byt the bytes in the symbol
> > +// Increment the total sizeInBytes by the bytes in the symbol
> >  stats.sizeInBytes += s.second.stats.sizeInBytes;
> >
> >  // Now scan through the coverage map of this symbol.
> > @@ -202,6 +202,26 @@ namespace Coverage {
> >  uint32_t count;
> >
> >  // Mark NOPs as executed
> > +a = s.second.stats.sizeInBytes - 1;
> > +count = 0;
> > +while (a > 0) {
> > +  if (theCoverageMap->isStartOfInstruction( a )) {
> > +break;
> > +  }
> > +
> > +  count++;
> > +
> > +  if (theCoverageMap->isNop( a )) {
> > +for (la = a; la < (a + count); la++) {
> > +  theCoverageMap->setWasExecuted( la );
> > +}
> > +
> > +count = 0;
> > +  }
> > +
> > +  a--;
> > +}
> > +
> >  endAddress = s.second.stats.sizeInBytes - 1;
> >  a = 0;
> >  while (a < endAddress) {
> > @@ -223,12 +243,13 @@ namespace Coverage {
> >ha++;
> >if ( ha >= endAddress )
> >  break;
> > -} while ( !theCoverageMap->isStartOfInstruction( ha ) );
> > +} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> > +  theCoverageMap->isNop( ha ) );
> >a = ha;
> >  }
> >
> >  // Now scan through the coverage map of this symbol.
> > -endAddress = s.second.stats.sizeInBytes - 1;
> > +endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
> >  a = 0;
> >  while (a <= endAddress) {
> >// If an address was NOT executed, find consecutive unexecuted
> > @@ -316,7 +337,8 @@ namespace Coverage {
> >void DesiredSymbols::createCoverageMap(
> >  const std::string& exefileName,
> >  const std::string& symbolName,
> > -uint32_t   size
> > +uint32_t   size,
> > +uint32_t   sizeWithoutNops
> >)
> >{
> >  CoverageMapBase* aCoverageMap;
> > @@ -354,9 +376,10 @@ namespace Coverage {
> ><< '/' << size << 

Re: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Oh wow. That makes so much more sense now! Thanks very much for the
clarification!

Sincerely,

Matt

On Thu, Mar 25, 2021 at 2:18 PM Joel Sherrill  wrote:
>
>
>
> On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> Thanks very much, that's a big help!  Correct, I've been updating the
>> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
>> in rtems/cpukit and implemented in Newlib.
>>
>> One additional question, please: I haven't yet looked into the source
>> of NetBSD or FreeBSD, but I do see that Newlib already implements
>> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
>> sockatmark (net.cc). None of them are defined in the rtems environment
>> yet. Is there any reason why the NetBSD/FreeBSD version would be
>> preferable to Newlib for these? Or is it just a matter of testing
>> what's out there to find what works well in the rtems environment?
>
>
> Without looking at the newlib git repo, I can tell you that the files
> you cite are the implementation of those methods for Cygwin. Just
> because they are in C++. :)
>
> The parts of the newlib repo RTEMS uses are under the newlib/
> subdirectory not the cygwin one. Within that, there is a libc/sys and
> only libc/sys/rtems is used for RTEMS. The others are for different
> operating systems. There are a few places with "machine" directory
> structures. Only the ones for the architecture you are building for
> is used.
>
> As to why NetBSD for libdl, that is because portions of the code
> originated there.
>
> And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
> source as we can keep it.
>
>>
>>
>> In my proposal I'll take your advice and work on some of the easier
>> ones first in order to get the experience and process down.
>
>
> There are tickets for a lot of methods. The rtems-docs repo has the
> csv file (e.g. spreadsheet) which tracks RTEMS support against
> various standards. The RTEMS POSIX Compliance Guide is generated
> from that csv file. Between those, you can find other methods to ask
> about. In general, if it is required by the Software Communications
> Architecture (SCA) or FACE Technical Standard, then it is a method
> someone expected to possibly be used in an embedded system.
> SCA is a set of POSIX profiles focused on software defined radios and
> the FACE Technical Standard was developed with avionics in mind.
>
> But any are fair game if they are actually implementable. I don;t think
> the Compliance Guide says it yet, but we decided last year that
> wordexp() is likely not supportable on RTEMS. The newlib
> implementation assumes the presence of a shell with wildcard expansion
> and ability to fork a process.
>
> --joel
>
>>
>>
>> Thank you again for your time!
>>
>> Matt
>>
>> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>> >
>> > Wow! Good work. There is a lot to digest here. Comments interspersed.
>> >
>> > I assume the spreadsheet is updated.
>> >
>> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  
>> > wrote:
>> >>
>> >> Hi Dr. Joel,
>> >>
>> >> I've gone over the list a few times now and see a few categories shaping 
>> >> up:
>> >>
>> >> 1) Already done (In Newlib source, defined in libc.a):
>> >> a) reallocarray
>> >> b) qsort_r
>> >> c) memmem
>> >> d) strlcat / strlcpy
>> >> d) wcslcat / wcslcpy
>> >> *Out of this group, strlcat and strlcpy also show up in
>> >> src/rtems/cpukit. Why is that?
>> >
>> >
>> > The good news is that we support these. :)
>> >
>> > It looks to me that strlcat and strlcpy are used in cpukit but not 
>> > implemented
>> > there. Where do you think they are implemented.
>> >
>> > This is a good example where a source code browser is helpful. grep can
>> > often answer the question but a source code browser can be easier. 
>> > Personally,
>> > I use cscope but that is exceedingly old school. Any modern IDE should be
>> > helpful.
>> >
>> >>
>> >> 2) Not done yet (Do not show up in Newlib source or RTEMS):
>> >> a) getlocalename_l
>> >> b) posix_getdents
>> >> c) sem_clockwait
>> >> d) sig2str / str2sig
>> >>
>> >> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
>> >> a) pthread_cond_clockwait
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
>> >> b) pthread_mutex_clocklock
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
>> >> c) pthread_rwlock_clockrdlock
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> >> c) pthread_rwlock_clockwrlock
>> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> >> *It looks like some groundwork was done, but the methods are not yet 
>> >> supported.
>> >
>> >
>> > The paths you point to are C++ files that would implement C++ features
>> > using the available POSIX services. So they are users, not providers.
>> >
>> > All of the pthread services related to these are implemented in
>> > cpukit/posix/src. I think you can configure a clock for all these now
>> > to be used by detailed on 

Re: [PATCH rtems 2/2] stm32h7: Add init for sdmmc pins.

[Gedare Bloom]

the 2 rtems patches are in stm32h7 bsp only, go ahead looks fine

On Thu, Mar 25, 2021 at 2:35 AM Christian Mauderer
 wrote:
>
> ---
>  bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c|  2 +
>  bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c | 88 ++
>  spec/build/bsps/arm/stm32h7/bspstm32h7.yml |  1 +
>  3 files changed, 91 insertions(+)
>  create mode 100644 bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
>
> diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c 
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
> index edafb06def..eb8dbe71f1 100644
> --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
> +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
> @@ -594,6 +594,7 @@ HAL_StatusTypeDef HAL_SD_DeInit(SD_HandleTypeDef *hsd)
>  }
>
>
> +#ifndef __rtems__
>  /**
>* @brief  Initializes the SD MSP.
>* @param  hsd: Pointer to SD handle
> @@ -608,6 +609,7 @@ __weak void HAL_SD_MspInit(SD_HandleTypeDef *hsd)
>  the HAL_SD_MspInit could be implemented in the user file
> */
>  }
> +#endif /* __rtems__ */
>
>  /**
>* @brief  De-Initialize SD MSP.
> diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c 
> b/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
> new file mode 100644
> index 00..2bbc4ff953
> --- /dev/null
> +++ b/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (C) 2020 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.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +
> +static const stm32h7_gpio_config gpiob = {
> +  .regs = GPIOB,
> +  .config = {
> +.Pin = GPIO_PIN_8 | GPIO_PIN_9,
> +.Mode = GPIO_MODE_AF_PP,
> +.Pull = GPIO_NOPULL,
> +.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
> +.Alternate = GPIO_AF7_SDMMC1
> +  }
> +};
> +
> +static const stm32h7_gpio_config gpioc_af12 = {
> +  .regs = GPIOC,
> +  .config = {
> +.Pin = GPIO_PIN_8 | GPIO_PIN_9 | GPIO_PIN_10 | GPIO_PIN_11 | GPIO_PIN_12,
> +.Mode = GPIO_MODE_AF_PP,
> +.Pull = GPIO_NOPULL,
> +.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
> +.Alternate = GPIO_AF12_SDMMC1
> +  }
> +};
> +
> +static const stm32h7_gpio_config gpioc_af8 = {
> +  .regs = GPIOC,
> +  .config = {
> +.Pin = GPIO_PIN_6 | GPIO_PIN_7,
> +.Mode = GPIO_MODE_AF_PP,
> +.Pull = GPIO_NOPULL,
> +.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
> +.Alternate = GPIO_AF8_SDMMC1
> +  }
> +};
> +
> +static const stm32h7_gpio_config gpiod = {
> +  .regs = GPIOD,
> +  .config = {
> +.Pin = GPIO_PIN_2,
> +.Mode = GPIO_MODE_AF_PP,
> +.Pull = GPIO_NOPULL,
> +.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
> +.Alternate = GPIO_AF12_SDMMC1
> +  }
> +};
> +
> +void
> +HAL_SD_MspInit(SD_HandleTypeDef *hsd)
> +{
> +  stm32h7_clk_enable(STM32H7_MODULE_SDMMC1);
> +  stm32h7_gpio_init();
> +  stm32h7_gpio_init(_af12);
> +  stm32h7_gpio_init(_af8);
> +  stm32h7_gpio_init();
> +  __HAL_RCC_SDMMC1_FORCE_RESET();
> +  __HAL_RCC_SDMMC1_RELEASE_RESET();
> +}
> diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml 
> b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
> index 80e13472c8..5b3ecc6a89 100644
> --- a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
> +++ b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
> @@ -417,6 +417,7 @@ source:
>  - bsps/arm/stm32h7/start/stm32h7-config-per.c
>  - bsps/arm/stm32h7/start/stm32h7-config-pwr.c
>  - bsps/arm/stm32h7/start/stm32h7-hal-eth.c
> +- bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
>  - bsps/arm/stm32h7/start/stm32h7-hal-uart.c
>  - bsps/arm/stm32h7/start/stm32h7-hal.c
>  - bsps/arm/stm32h7/start/system_stm32h7xx.c
> --
> 2.26.2
>
> 

Re: [PATCH rtems-docs] user/bsps: Add STM32H7 SDMMC driver

[Gedare Bloom]

doc looks good

On Thu, Mar 25, 2021 at 2:36 AM Christian Mauderer
 wrote:
>
> ---
>  user/bsps/arm/stm32h7.rst | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
> index 3eee511..483d029 100644
> --- a/user/bsps/arm/stm32h7.rst
> +++ b/user/bsps/arm/stm32h7.rst
> @@ -31,3 +31,29 @@ USB Host Driver
>  ---
>
>  The USB host driver ``dwc_otg`` is provided by the ``libbsd``.
> +
> +SD/MMC Driver
> +-
> +
> +The SDMMC driver ``st_sdmmc`` is provided by the ``libbsd``.
> +
> +The default initialization is done for the STM32H743I-EVAL 2 board.
> +
> +To use different pins, you can create a ``HAL_SD_MspInit()`` function in your
> +application that overwrites the default one defined in ``RTEMS``. If you 
> don't
> +have direction lines like on the evaluation board, you can just skip
> +initializing these pins.
> +
> +If you want to use a different number of data lines, another polarity for the
> +data direction pins, a different voltage or similar, you have to redefine
> +``st_sdmmc_get_config()`` (normally provided by ``libbsd``) in your 
> application.
> +
> +Known limitations:
> +
> +* Currently 1.8V signaling is not implemented. Therefore higher speeds like 
> used
> +  for UHS cards are not available. All cards fall back to High Speed 
> transfers.
> +* The driver uses the IDMA only. MDMA is currently not implemented. For 
> SDMMC1
> +  that means that the memory buffers can only come from AXI SRAM, QSPI 
> memory,
> +  Flash or the FMC (SDRAM, ...). The internal SRAM1, SRAM2, SRAM3 and SRAM4 
> is
> +  not supported. SDMMC2 should not have that limitation. See ST AN5200 
> "Getting
> +  started with STM32H7 Series SDMMC host controller" for more details.
> --
> 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 v5 2/2] covoar/Target_i386: Add NOP patterns

[Gedare Bloom]

This patch looks fine.

On Thu, Mar 18, 2021 at 12:05 PM Alex White  wrote:
>
> A couple of NOP patterns found with the pc686 BSP were not detected.
> This has been fixed.
> ---
>  tester/covoar/Target_i386.cc | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc
> index e0c9c0f..4567c1e 100644
> --- a/tester/covoar/Target_i386.cc
> +++ b/tester/covoar/Target_i386.cc
> @@ -87,6 +87,15 @@ namespace Target {
>size = 3;
>return true;
>  }
> +if (!strncmp( [strlen(line)-28], "lea0x0(%esi,%eiz,1),%esi", 
> 28)) {
> +  // Could be 4 or 7 bytes of padding.
> +  if (!strncmp( [strlen(line)-32], "00", 2)) {
> +size = 7;
> +  } else {
> +size = 4;
> +  }
> +  return true;
> +}
>
>  return false;
>}
> --
> 2.27.0
>
> ___
> 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 v5 1/2] covoar: Fix NOP execution marking

[Gedare Bloom]

On Thu, Mar 18, 2021 at 12:05 PM Alex White  wrote:
>
> Some NOP instructions were not being marked as executed because they
> are located at the end of uncovered ranges. This has been fixed.
> ---
>  tester/covoar/CoverageMapBase.cc  |  10 +++
>  tester/covoar/CoverageMapBase.h   |   4 ++
>  tester/covoar/DesiredSymbols.cc   |  38 +--
>  tester/covoar/DesiredSymbols.h|  11 ++-
>  tester/covoar/ExecutableInfo.cc   |   2 +-
>  tester/covoar/ExecutableInfo.h|   4 ++
>  tester/covoar/ObjdumpProcessor.cc | 109 +++---
>  7 files changed, 142 insertions(+), 36 deletions(-)
>
> diff --git a/tester/covoar/CoverageMapBase.cc 
> b/tester/covoar/CoverageMapBase.cc
> index ad0080d..6ca5cf7 100644
> --- a/tester/covoar/CoverageMapBase.cc
> +++ b/tester/covoar/CoverageMapBase.cc
> @@ -142,6 +142,11 @@ namespace Coverage {
>  return size;
>}
>
> +  uint32_t CoverageMapBase::getSizeOfRange( size_t index ) const
> +  {
> +return Ranges.at(index).size();
> +  }
> +
>bool CoverageMapBase::getBeginningOfInstruction(
>  uint32_t  address,
>  uint32_t* beginning
> @@ -178,6 +183,11 @@ namespace Coverage {
>  return Ranges.front().lowAddress;
>}
>
> +  uint32_t CoverageMapBase::getLowAddressOfRange( size_t index ) const
> +  {
> +return Ranges.at(index).lowAddress;
> +  }
> +
>bool CoverageMapBase::getRange( uint32_t address, AddressRange& range ) 
> const
>{
>  for ( auto r : Ranges ) {
> diff --git a/tester/covoar/CoverageMapBase.h b/tester/covoar/CoverageMapBase.h
> index 6ad76d3..a58c696 100644
> --- a/tester/covoar/CoverageMapBase.h
> +++ b/tester/covoar/CoverageMapBase.h
> @@ -156,6 +156,8 @@ namespace Coverage {
>   */
>  int32_t getFirstLowAddress() const;
>
> +uint32_t getLowAddressOfRange( size_t index ) const;
> +
>  /*!
>   *  This method returns true and sets the address range if
>   *  the address falls with the bounds of an address range
> @@ -177,6 +179,8 @@ namespace Coverage {
>   */
>  uint32_t getSize() const;
>
> +uint32_t getSizeOfRange( size_t index ) const;
> +
>  /*!
>   *  This method returns the address of the beginning of the
>   *  instruction that contains the specified address.
> diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
> index b9a5bb7..c97b25c 100644
> --- a/tester/covoar/DesiredSymbols.cc
> +++ b/tester/covoar/DesiredSymbols.cc
> @@ -142,7 +142,7 @@ namespace Coverage {
>CoverageMapBase* theCoverageMap = s.second.unifiedCoverageMap;
>if (theCoverageMap)
>{
> -// Increment the total sizeInBytes byt the bytes in the symbol
> +// Increment the total sizeInBytes by the bytes in the symbol
>  stats.sizeInBytes += s.second.stats.sizeInBytes;
>
>  // Now scan through the coverage map of this symbol.
> @@ -202,6 +202,26 @@ namespace Coverage {
>  uint32_t count;
>
>  // Mark NOPs as executed
> +a = s.second.stats.sizeInBytes - 1;
> +count = 0;
> +while (a > 0) {
> +  if (theCoverageMap->isStartOfInstruction( a )) {
> +break;
> +  }
> +
> +  count++;
> +
> +  if (theCoverageMap->isNop( a )) {
> +for (la = a; la < (a + count); la++) {
> +  theCoverageMap->setWasExecuted( la );
> +}
> +
> +count = 0;
> +  }
> +
> +  a--;
> +}
> +
>  endAddress = s.second.stats.sizeInBytes - 1;
>  a = 0;
>  while (a < endAddress) {
> @@ -223,12 +243,13 @@ namespace Coverage {
>ha++;
>if ( ha >= endAddress )
>  break;
> -} while ( !theCoverageMap->isStartOfInstruction( ha ) );
> +} while ( !theCoverageMap->isStartOfInstruction( ha ) ||
> +  theCoverageMap->isNop( ha ) );
>a = ha;
>  }
>
>  // Now scan through the coverage map of this symbol.
> -endAddress = s.second.stats.sizeInBytes - 1;
> +endAddress = s.second.stats.sizeInBytesWithoutNops - 1;
>  a = 0;
>  while (a <= endAddress) {
>// If an address was NOT executed, find consecutive unexecuted
> @@ -316,7 +337,8 @@ namespace Coverage {
>void DesiredSymbols::createCoverageMap(
>  const std::string& exefileName,
>  const std::string& symbolName,
> -uint32_t   size
> +uint32_t   size,
> +uint32_t   sizeWithoutNops
>)
>{
>  CoverageMapBase* aCoverageMap;
> @@ -354,9 +376,10 @@ namespace Coverage {
><< '/' << size << ')'
><< std::endl;
>
> -if ( itr->second.stats.sizeInBytes < size )
> +if ( itr->second.stats.sizeInBytes < size ) {
>itr->second.stats.sizeInBytes = size;
> -else
> +  itr->second.stats.sizeInBytesWithoutNops = sizeWithoutNops;
> +} else
>

RE: [PATCH v5 0/2] Fix NOP recognition

[Alex White]

ping

> -Original Message-
> From: Alex White 
> Sent: Thursday, March 18, 2021 1:05 PM
> To: devel@rtems.org
> Cc: Alex White 
> Subject: [PATCH v5 0/2] Fix NOP recognition
> 
> v5:
> - Fix missing std::dec at the end of error message printing in
>   Coverage::finalizeSymbol()
> 
> v4:
> - Add specialized CoverageMapNotFoundError exception class to
> ExecutableInfo
> - Catch ExecutableInfo::CoverageMapNotFoundError in
> Coverage::finalizeSymbol()
> 
> v3:
> - Fix double increment of rangeIndex in Coverage::finalizeSymbol()
> 
> v2:
> - Fix leftover debugging code in Coverage::finalizeSymbol()
> 
> This patch set fixes a couple cases where NOP instructions were showing up
> as unexecuted in coverage reports.
> 
> Alex White (2):
>   covoar: Fix NOP execution marking
>   covoar/Target_i386: Add NOP patterns
> 
>  tester/covoar/CoverageMapBase.cc  |  10 +++
>  tester/covoar/CoverageMapBase.h   |   4 ++
>  tester/covoar/DesiredSymbols.cc   |  38 +--
>  tester/covoar/DesiredSymbols.h|  11 ++-
>  tester/covoar/ExecutableInfo.cc   |   2 +-
>  tester/covoar/ExecutableInfo.h|   4 ++
>  tester/covoar/ObjdumpProcessor.cc | 109 +++
> ---
>  tester/covoar/Target_i386.cc  |   9 +++
>  8 files changed, 151 insertions(+), 36 deletions(-)
> 
> --
> 2.27.0

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

Re: [PATCH rtems-docs v3 1/6] prefixes: Update installation prefix

[Gedare Bloom]

I'm pushing this patch set. Eventually we'll want to figure out how to
deal with this.

On Tue, Mar 23, 2021 at 9:39 AM Gedare Bloom  wrote:
>
> On Tue, Mar 23, 2021 at 9:28 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Mar 23, 2021 at 10:16 AM Gedare Bloom  wrote:
> >>
> >> On Mon, Mar 22, 2021 at 3:12 PM Chris Johns  wrote:
> >> >
> >> > On 23/3/21 4:41 am, Gedare Bloom wrote:> I wonder what is your opinion, 
> >> > should
> >> > we bump these tutorials with
> >> > > every version? And, is the find/replace of the commands the best way
> >> > > to do this?
> >> > >
> >> > > I feel like this topic comes up now and again. Maintaining these
> >> > > examples is a little fragile.
> >> >
> >> > It is fragile and I have in the past invested some time looking for a 
> >> > way to
> >> > automatically manage these version based blocks of documentation however 
> >> > subtle
> >> > change happen so making it automatic is difficult. Arguments to commands 
> >> > change
> >> > and if there is captured output it needs to change.
> >> >
> >> > > @Ida: Thanks for the patches,
> >> >
> >> > Yes, thank you. The patches are great.
> >> >
> >> > > now we'll need to determine if we want
> >> > > to bump these examples like this, and whether we should consider a
> >> > > better way to maintain this stuff in the future.
> >> >
> >> > I am open to solutions. A few ideas are:
> >> >
> >> > 1. Group commands we consider as stable interfaces and see if the RTEMS 
> >> > version
> >> > can be supplied via a conf variable passed in by waf. This would lower 
> >> > the
> >> > number of changes.
> >> >
> >> > 2. Tag version specific blocks with something in a comment. Making a 
> >> > change is
> >> > part of the solution however I find knowing there is a change to make is 
> >> > harder.
> >> > If we can grep the sources we could see. For example:
> >> >
> >> I like tagging.
> >>
> >> > .. rtems-version-block: 5
> >> >
> >
> >
> > Texinfo had variables. Looking at Sphinx docs, I see this:
> >
> > https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions
> >
> > Does that work? Could we have
> >
> > .. |rtems-version| replace:: 6
> >
> > This should work in text without doing any magic. It looks like example
> > and code blocks may need a special block for this to work. I think this
> > page has a solution to that
> >
> >  
> > https://stackoverflow.com/questions/42158111/variable-substitution-not-working-properly-in-sphinx
> >
> > This won't help when command line arguments change and things like the
> > transition from the sis to erc32 BSP will still need work.
> >
> It also doesn't address that example output changes with each version.
> That's the bigger problem here.
>
> >> > The version number is updated when changed so we can see what needs to 
> >> > be done.
> >> > This would be helpful when making releases.
> >> >
> >> > 3. Other ideas ...
> >> >
> >> A script/tutorial to regenerate these parts could work also. Kind of a
> >> guide how to update for a new version, and what needs to be
> >> run/captured as output examples.
> >>
> >> > Chris
> >> ___
> >> 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: #4328: New APIs added to POSIX Standard (2021)

[Joel Sherrill]

On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce  wrote:

> Hi Dr. Joel,
>
> Thanks very much, that's a big help!  Correct, I've been updating the
> spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
> in rtems/cpukit and implemented in Newlib.
>
> One additional question, please: I haven't yet looked into the source
> of NetBSD or FreeBSD, but I do see that Newlib already implements
> ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
> sockatmark (net.cc). None of them are defined in the rtems environment
> yet. Is there any reason why the NetBSD/FreeBSD version would be
> preferable to Newlib for these? Or is it just a matter of testing
> what's out there to find what works well in the rtems environment?
>

Without looking at the newlib git repo, I can tell you that the files
you cite are the implementation of those methods for Cygwin. Just
because they are in C++. :)

The parts of the newlib repo RTEMS uses are under the newlib/
subdirectory not the cygwin one. Within that, there is a libc/sys and
only libc/sys/rtems is used for RTEMS. The others are for different
operating systems. There are a few places with "machine" directory
structures. Only the ones for the architecture you are building for
is used.

As to why NetBSD for libdl, that is because portions of the code
originated there.

And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD
source as we can keep it.


>
> In my proposal I'll take your advice and work on some of the easier
> ones first in order to get the experience and process down.
>

There are tickets for a lot of methods. The rtems-docs repo has the
csv file (e.g. spreadsheet) which tracks RTEMS support against
various standards. The RTEMS POSIX Compliance Guide is generated
from that csv file. Between those, you can find other methods to ask
about. In general, if it is required by the Software Communications
Architecture (SCA) or FACE Technical Standard, then it is a method
someone expected to possibly be used in an embedded system.
SCA is a set of POSIX profiles focused on software defined radios and
the FACE Technical Standard was developed with avionics in mind.

But any are fair game if they are actually implementable. I don;t think
the Compliance Guide says it yet, but we decided last year that
wordexp() is likely not supportable on RTEMS. The newlib
implementation assumes the presence of a shell with wildcard expansion
and ability to fork a process.

--joel


>
> Thank you again for your time!
>
> Matt
>
> On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
> >
> > Wow! Good work. There is a lot to digest here. Comments interspersed.
> >
> > I assume the spreadsheet is updated.
> >
> > On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce 
> wrote:
> >>
> >> Hi Dr. Joel,
> >>
> >> I've gone over the list a few times now and see a few categories
> shaping up:
> >>
> >> 1) Already done (In Newlib source, defined in libc.a):
> >> a) reallocarray
> >> b) qsort_r
> >> c) memmem
> >> d) strlcat / strlcpy
> >> d) wcslcat / wcslcpy
> >> *Out of this group, strlcat and strlcpy also show up in
> >> src/rtems/cpukit. Why is that?
> >
> >
> > The good news is that we support these. :)
> >
> > It looks to me that strlcat and strlcpy are used in cpukit but not
> implemented
> > there. Where do you think they are implemented.
> >
> > This is a good example where a source code browser is helpful. grep can
> > often answer the question but a source code browser can be easier.
> Personally,
> > I use cscope but that is exceedingly old school. Any modern IDE should be
> > helpful.
> >
> >>
> >> 2) Not done yet (Do not show up in Newlib source or RTEMS):
> >> a) getlocalename_l
> >> b) posix_getdents
> >> c) sem_clockwait
> >> d) sig2str / str2sig
> >>
> >> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
> >> a) pthread_cond_clockwait
> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
> >> b) pthread_mutex_clocklock
> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
> >> c) pthread_rwlock_clockrdlock
> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
> >> c) pthread_rwlock_clockwrlock
> >> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
> >> *It looks like some groundwork was done, but the methods are not yet
> supported.
> >
> >
> > The paths you point to are C++ files that would implement C++ features
> > using the available POSIX services. So they are users, not providers.
> >
> > All of the pthread services related to these are implemented in
> > cpukit/posix/src. I think you can configure a clock for all these now
> > to be used by detailed on wait and timedwait calls. My understanding
> > is that these would let you use a specific clock on a per blocking call
> > basis.
> >
> > First question is which clocks are intended to be supported.
> >
> > Second is the pattern of picking which timeout queue to go on when
> > now it is coded to let you pick one which is used for the 

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

That is how it was done in the lwIP demo provided by STM, I simply adopted
that. The SRAM3 is small, but big enough for lwIP, so all of it is used
completely by lwIP.
How would you place the descriptors in code so that these linker script
sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
the source code?

Kind Regards
Robin Müller

On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/02/2021 14:50, Robin Müller wrote:
>
> > The following link contains more theoretical information about why
> > these sections were placed at these addresses:
> >
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> > <
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> >
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 3 Feb 2021 at 14:44, Robin Müller  > > wrote:
> >
> > The DMA descriptors need to be placed at the start of the SRAM3
> > and need to be aligned in a certain way. The RX buffer will take
> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
> > placed
> > behind the DMA descriptors. It also needs to be placed in a way
> > that the MPU configuration required for the DMA descriptors will
> > not do something with the RX buffers.
> > In the example provided by STM32, the first 256 bytes are
> > configured by MPU Config.
> >
> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
> the .nocache area. This is in the D2 domain. The Ethernet module is in
> the D2 domain. I am not sure why you have to change this to the smaller
> SRAM3? The libbsd driver works well with the current setting.
>
> --
> 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: #4328: New APIs added to POSIX Standard (2021)

[Matthew Joyce]

Hi Dr. Joel,

Thanks very much, that's a big help!  Correct, I've been updating the
spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used
in rtems/cpukit and implemented in Newlib.

One additional question, please: I haven't yet looked into the source
of NetBSD or FreeBSD, but I do see that Newlib already implements
ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and
sockatmark (net.cc). None of them are defined in the rtems environment
yet. Is there any reason why the NetBSD/FreeBSD version would be
preferable to Newlib for these? Or is it just a matter of testing
what's out there to find what works well in the rtems environment?

In my proposal I'll take your advice and work on some of the easier
ones first in order to get the experience and process down.

Thank you again for your time!

Matt

On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill  wrote:
>
> Wow! Good work. There is a lot to digest here. Comments interspersed.
>
> I assume the spreadsheet is updated.
>
> On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce  wrote:
>>
>> Hi Dr. Joel,
>>
>> I've gone over the list a few times now and see a few categories shaping up:
>>
>> 1) Already done (In Newlib source, defined in libc.a):
>> a) reallocarray
>> b) qsort_r
>> c) memmem
>> d) strlcat / strlcpy
>> d) wcslcat / wcslcpy
>> *Out of this group, strlcat and strlcpy also show up in
>> src/rtems/cpukit. Why is that?
>
>
> The good news is that we support these. :)
>
> It looks to me that strlcat and strlcpy are used in cpukit but not implemented
> there. Where do you think they are implemented.
>
> This is a good example where a source code browser is helpful. grep can
> often answer the question but a source code browser can be easier. Personally,
> I use cscope but that is exceedingly old school. Any modern IDE should be
> helpful.
>
>>
>> 2) Not done yet (Do not show up in Newlib source or RTEMS):
>> a) getlocalename_l
>> b) posix_getdents
>> c) sem_clockwait
>> d) sig2str / str2sig
>>
>> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:
>> a) pthread_cond_clockwait
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)
>> b) pthread_mutex_clocklock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)
>> c) pthread_rwlock_clockrdlock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> c) pthread_rwlock_clockwrlock
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)
>> *It looks like some groundwork was done, but the methods are not yet 
>> supported.
>
>
> The paths you point to are C++ files that would implement C++ features
> using the available POSIX services. So they are users, not providers.
>
> All of the pthread services related to these are implemented in
> cpukit/posix/src. I think you can configure a clock for all these now
> to be used by detailed on wait and timedwait calls. My understanding
> is that these would let you use a specific clock on a per blocking call
> basis.
>
> First question is which clocks are intended to be supported.
>
> Second is the pattern of picking which timeout queue to go on when
> now it is coded to let you pick one which is used for the life of the object.
>
>>
>> 4) Misc (In Newlib source, not defined in libc.a, appear in RTEMS in
>> various ways)
>> a) getentropy (an alternate version is defined in RTEMS librtemsbsd.a,
>> in src/rtems/bsps/shared/dev/getentropy/getentropy-cpucounter.c. The
>> comments note that it is not cryptographically secure, so it may not
>> fit the bill for the getentropy() mentioned in the Open Group
>> document)
>
>
> I am far from a cryptography expert but this looks like a case where
> this method would be considered supported with the disclaimer that
> the quality of the entropy value depends on the BSP. If the user has
> specific requirements, they will need to verify the implementation
> used by the BSP by default is appropriate.
>
>>
>> b) ppoll (appears in rtems/6/share/gdb/syscalls)
>
>
> You need to be more careful with the grep. These again are in the
> installed tools and in this case, they appear in an XML file. Referenced
> but not implemented.
>
> ppoll() will need to come from rtems-libbsd. The required system call
> is included but disabled currently. AFAIK this means it is possible to
> provide this but that would require a more detailed discussion in case
> some underlying capability is missing. Chris Johns and Sebastian
> Huber would be the ones to guide here.
>
> Ruling: Likely possible.
>
>>
>> c) dladdr (appears in rtems/cpukit but not defined)
>
>
> I think this can be implemented in libdl but I am not sure if the
> code from NetBSD from this would directly work or just be a guide.
>
>>
>>
>> 5) Others?
>> It looks like there was work done on methods like sockatmark and
>> pselect, but I don't see them supported as yet. Should those be added
>> to the list or are they still being worked on?
>
>
> These would come from rtems-libbsd.
>
> I think sockatmark.c is implemented in 

[PATCH rtems-docs] user/bsps: Add STM32H7 SDMMC driver

[Christian Mauderer]

---
 user/bsps/arm/stm32h7.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
index 3eee511..483d029 100644
--- a/user/bsps/arm/stm32h7.rst
+++ b/user/bsps/arm/stm32h7.rst
@@ -31,3 +31,29 @@ USB Host Driver
 ---
 
 The USB host driver ``dwc_otg`` is provided by the ``libbsd``.
+
+SD/MMC Driver
+-
+
+The SDMMC driver ``st_sdmmc`` is provided by the ``libbsd``.
+
+The default initialization is done for the STM32H743I-EVAL 2 board.
+
+To use different pins, you can create a ``HAL_SD_MspInit()`` function in your
+application that overwrites the default one defined in ``RTEMS``. If you don't
+have direction lines like on the evaluation board, you can just skip
+initializing these pins.
+
+If you want to use a different number of data lines, another polarity for the
+data direction pins, a different voltage or similar, you have to redefine
+``st_sdmmc_get_config()`` (normally provided by ``libbsd``) in your 
application.
+
+Known limitations:
+
+* Currently 1.8V signaling is not implemented. Therefore higher speeds like 
used
+  for UHS cards are not available. All cards fall back to High Speed transfers.
+* The driver uses the IDMA only. MDMA is currently not implemented. For SDMMC1
+  that means that the memory buffers can only come from AXI SRAM, QSPI memory,
+  Flash or the FMC (SDRAM, ...). The internal SRAM1, SRAM2, SRAM3 and SRAM4 is
+  not supported. SDMMC2 should not have that limitation. See ST AN5200 "Getting
+  started with STM32H7 Series SDMMC host controller" for more details.
-- 
2.26.2

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

[PATCH rtems-libbsd 3/3] STM32H7: Add SDMMC driver

[Christian Mauderer]

---
 libbsd.py |   2 +
 rtemsbsd/include/bsp/nexus-devices.h  |   2 +
 rtemsbsd/include/bsp/st-sdmmc-config.h|  71 ++
 .../include/machine/rtems-bsd-nexus-bus.h |  22 +
 rtemsbsd/sys/dev/mmc/st-sdmmc-config.c|  46 +
 rtemsbsd/sys/dev/mmc/st-sdmmc.c   | 847 ++
 6 files changed, 990 insertions(+)
 create mode 100644 rtemsbsd/include/bsp/st-sdmmc-config.h
 create mode 100644 rtemsbsd/sys/dev/mmc/st-sdmmc-config.c
 create mode 100644 rtemsbsd/sys/dev/mmc/st-sdmmc.c

diff --git a/libbsd.py b/libbsd.py
index f8a35e6c6..befa1a1a5 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -228,6 +228,8 @@ class rtems(builder.Module):
 'sys/dev/ffec/if_ffec_mcf548x.c',
 'sys/dev/ffec/if_ffec_mpc8xx.c',
 'sys/dev/input/touchscreen/tsc_lpc32xx.c',
+'sys/dev/mmc/st-sdmmc.c',
+'sys/dev/mmc/st-sdmmc-config.c',
 'sys/dev/smc/if_smc_nexus.c',
 'sys/dev/stmac/if_stmac.c',
 'sys/dev/tsec/if_tsec_nexus.c',
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 53a22798b..efe4fcb4f 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -193,6 +193,8 @@ static const rtems_bsd_device_resource dwcotg_res[] = {
 };
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(dwcotg, 0, RTEMS_ARRAY_SIZE(dwcotg_res),
 dwcotg_res);
+RTEMS_BSD_DRIVER_ST_SDMMC(0, SDMMC1_BASE, DLYB_SDMMC1_BASE, SDMMC1_IRQn);
+RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DRIVER_USB;
 RTEMS_BSD_DRIVER_USB_MASS;
 
diff --git a/rtemsbsd/include/bsp/st-sdmmc-config.h 
b/rtemsbsd/include/bsp/st-sdmmc-config.h
new file mode 100644
index 0..b44159918
--- /dev/null
+++ b/rtemsbsd/include/bsp/st-sdmmc-config.h
@@ -0,0 +1,71 @@
+/* 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.
+ */
+
+#ifndef BSP_ST_SDMMC_CONFIG_H
+#define BSP_ST_SDMMC_CONFIG_H
+
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+struct st_sdmmc_config {
+   /**
+* Number of data lines. Can be 1, 4 or 8
+*/
+   uint8_t data_lines;
+   /**
+* Polarity of the DIR pins. See "SDMMC_POWER" register in the
+* STM32H7xx data sheet for that. If you don't have the lines, you can
+* use any value.
+*/
+   bool dirpol;
+   /**
+* Possible OCR voltages. Should be something like
+* MMC_OCR_290_300 | MMC_OCR_300_310 depending on card supply.
+*/
+   uint32_t ocr_voltage;
+};
+
+/**
+ * Get hardware specific configuration for SDMMC.
+ *
+ * This function can be overwritten in the application to adapt to another 
board
+ * configuration. The sdmmc_base points to the base address of the SDMMC
+ * instance. The cfg structure is set to zero before calling this function so
+ * that only the necessary fields have to be initialized.
+ */
+void st_sdmmc_get_config(uintptr_t sdmmc_base, struct st_sdmmc_config *cfg);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* BSP_ST_SDMMC_CONFIG_H */
diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index f1ca66d70..5902c58c6 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -243,6 +243,28 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(mmcsd, mmc)
 #endif /* RTEMS_BSD_DRIVER_MMC */
 
+#if !defined(RTEMS_BSD_DRIVER_ST_SDMMC)
+  #define RTEMS_BSD_DRIVER_ST_SDMMC(_num, _base, 

[PATCH rtems-libbsd 2/3] testsuite/media01: Add pattern test.

[Christian Mauderer]

---
 libbsd.py|   2 +-
 testsuite/media01/pattern-test.c | 337 +++
 testsuite/media01/pattern-test.h |  44 
 testsuite/media01/test_main.c|   5 +-
 4 files changed, 386 insertions(+), 2 deletions(-)
 create mode 100644 testsuite/media01/pattern-test.c
 create mode 100644 testsuite/media01/pattern-test.h

diff --git a/libbsd.py b/libbsd.py
index a2056f364..f8a35e6c6 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5402,7 +5402,7 @@ class tests(builder.Module):
   runTest = False, netTest = True,
   extraLibs = ['telnetd']))
 self.addTest(mm.generator['test']('smp01', ['test_main'], extraLibs = 
['rtemstest']))
-self.addTest(mm.generator['test']('media01', ['test_main'],
+self.addTest(mm.generator['test']('media01', ['test_main', 
'pattern-test'],
   runTest = False,
   extraLibs = ['ftpd', 'telnetd']))
 self.addTest(mm.generator['test']('mcast01', ['test_main']))
diff --git a/testsuite/media01/pattern-test.c b/testsuite/media01/pattern-test.c
new file mode 100644
index 0..4b00cb736
--- /dev/null
+++ b/testsuite/media01/pattern-test.c
@@ -0,0 +1,337 @@
+/**
+ * @file
+ *
+ * @brief Command to fill a file with a pattern.
+ *
+ * The written pattern is a simple 32 bit counter which makes it easy to find
+ * problems where buffers are not written to the correct location or where some
+ * blocks are missing.
+ *
+ * This file can be either compiled as part of RTEMS or as a stand alone Linux
+ * or (most likely) FreeBSD application. To compile it as stand alone, just use
+ * "gcc pattern-test.c"
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 embedded brains GmbH.
+ *
+ * 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 __rtems__
+#include "pattern-test.h"
+#endif /* __rtems__ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MIN(X, Y) (((X) < (Y)) ? (X) : (Y))
+
+static const char * const usage =
+   "Fill a file or a device file with a simple incrementing 32 bit 
pattern.\n"
+   "Use with:\n"
+   "pattern [fill|check][ 
[]]\n"
+   "Arguments:\n"
+   "All numbers can be decimal (e.g. 256) or hex (e.g. 0x100)\n"
+   " and  is in bytes\n"
+   " start with this counter value\n"
+   ": Only relevant for check. Can be: \n"
+   "  : print the first  errors\n"
+   "  \"short\": Print all errors but short form\n";
+
+static int
+check_and_process_params(
+   int argc,
+   char *argv[],
+   int open_flags,
+   int *fd,
+   size_t *size,
+   size_t *block_size,
+   uint8_t **block,
+   uint8_t **read_block,
+   int *max_errors,
+   bool *short_output,
+   uint32_t *start_value
+)
+{
+   if (argc < 4) {
+   printf(usage);
+   return -1;
+   }
+
+   if (argc > 4) {
+   *start_value = strtoul(argv[4], NULL, 0);
+   } else {
+   *start_value = 0;
+   }
+
+   if (short_output != NULL && max_errors != NULL) {
+   *short_output = false;
+   *max_errors = 1;
+   if (argc > 5) {
+   if (strcmp("short", argv[5]) == 0) {
+   *max_errors = -1;
+   *short_output = true;
+   } else {
+   *max_errors = strtol(argv[5], NULL, 0);
+   if 

[PATCH rtems-libbsd 1/3] testsuite/media01: Enable md5 command

[Christian Mauderer]

---
 testsuite/media01/test_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/testsuite/media01/test_main.c b/testsuite/media01/test_main.c
index dcab32208..9c05fc077 100644
--- a/testsuite/media01/test_main.c
+++ b/testsuite/media01/test_main.c
@@ -262,6 +262,7 @@ early_initialization(void)
 #define CONFIGURE_SHELL_COMMAND_MV
 #define CONFIGURE_SHELL_COMMAND_RM
 #define CONFIGURE_SHELL_COMMAND_MALLOC_INFO
+#define CONFIGURE_SHELL_COMMAND_MD5
 
 #define CONFIGURE_SHELL_COMMAND_FDISK
 #define CONFIGURE_SHELL_COMMAND_BLKSTATS
-- 
2.26.2

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

STM32H7 BSP: Add SDMMC-driver (Note: Extends libbsd media01)

[Christian Mauderer]

Hello,

the patch set for RTEMS, libbsd and docs add a SDMMC driver for STM32H7
to libbsd. Note that I added the md5 command to media01 which is useful
when testing storage devices. Beneath that I added a command that can
fill a disk or a file with an incrementing number which - again - can be
useful for testing storage media. The later command is only added to
media01 because I don't think it's a useful general purpose command but
rather a pure test command.

Patches belonging to this set:

RTEMS:
[PATCH rtems 1/2] stm32h7: Add SDMMC modules to clock.
[PATCH rtems 2/2] stm32h7: Add init for sdmmc pins.

libbsd:
[PATCH rtems-libbsd 1/3] testsuite/media01: Enable md5 command
[PATCH rtems-libbsd 2/3] testsuite/media01: Add pattern test.
[PATCH rtems-libbsd 3/3] STM32H7: Add SDMMC driver

docs:
[PATCH rtems-docs] user/bsps: Add STM32H7 SDMMC driver

Best regards

Christian

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

[PATCH rtems 1/2] stm32h7: Add SDMMC modules to clock.

[Christian Mauderer]

---
 bsps/arm/stm32h7/include/stm32h7/hal.h |  4 +++-
 bsps/arm/stm32h7/start/stm32h7-hal.c   | 14 --
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/stm32h7/include/stm32h7/hal.h 
b/bsps/arm/stm32h7/include/stm32h7/hal.h
index de38f1a5e8..e1bbd49ceb 100644
--- a/bsps/arm/stm32h7/include/stm32h7/hal.h
+++ b/bsps/arm/stm32h7/include/stm32h7/hal.h
@@ -66,7 +66,9 @@ typedef enum {
   STM32H7_MODULE_USB1_OTG,
   STM32H7_MODULE_USB1_OTG_ULPI,
   STM32H7_MODULE_USB2_OTG,
-  STM32H7_MODULE_USB2_OTG_ULPI
+  STM32H7_MODULE_USB2_OTG_ULPI,
+  STM32H7_MODULE_SDMMC1,
+  STM32H7_MODULE_SDMMC2,
 } stm32h7_module_index;
 
 stm32h7_module_index stm32h7_get_module_index(const void *regs);
diff --git a/bsps/arm/stm32h7/start/stm32h7-hal.c 
b/bsps/arm/stm32h7/start/stm32h7-hal.c
index 3dcc3098f4..d042a5b8c9 100644
--- a/bsps/arm/stm32h7/start/stm32h7-hal.c
+++ b/bsps/arm/stm32h7/start/stm32h7-hal.c
@@ -84,6 +84,12 @@ stm32h7_module_index stm32h7_get_module_index(const void 
*regs)
 #endif
 case RNG_BASE:
   return STM32H7_MODULE_RNG;
+case SDMMC1_BASE:
+case DLYB_SDMMC1_BASE:
+  return STM32H7_MODULE_SDMMC1;
+case SDMMC2_BASE:
+case DLYB_SDMMC2_BASE:
+  return STM32H7_MODULE_SDMMC2;
   }
 
   return STM32H7_MODULE_INVALID;
@@ -132,7 +138,9 @@ static const stm32h7_clk_info stm32h7_clk[] = {
   [STM32H7_MODULE_USB1_OTG] = { >AHB1ENR, RCC_AHB1ENR_USB1OTGHSEN },
   [STM32H7_MODULE_USB1_OTG_ULPI] = { >AHB1ENR, 
RCC_AHB1ENR_USB1OTGHSULPIEN },
   [STM32H7_MODULE_USB2_OTG] = { >AHB1ENR, RCC_AHB1ENR_USB2OTGHSEN },
-  [STM32H7_MODULE_USB2_OTG_ULPI] = { >AHB1ENR, 
RCC_AHB1ENR_USB2OTGHSULPIEN }
+  [STM32H7_MODULE_USB2_OTG_ULPI] = { >AHB1ENR, 
RCC_AHB1ENR_USB2OTGHSULPIEN },
+  [STM32H7_MODULE_SDMMC1] = { >AHB3ENR, RCC_AHB3ENR_SDMMC1EN },
+  [STM32H7_MODULE_SDMMC2] = { >AHB2ENR, RCC_AHB2ENR_SDMMC2EN },
 };
 
 void stm32h7_clk_enable(stm32h7_module_index index)
@@ -203,7 +211,9 @@ static const stm32h7_clk_info stm32h7_clk_low_power[] = {
   [STM32H7_MODULE_USB1_OTG] = { >AHB1LPENR, RCC_AHB1LPENR_USB1OTGHSLPEN },
   [STM32H7_MODULE_USB1_OTG_ULPI] = { >AHB1LPENR, 
RCC_AHB1LPENR_USB1OTGHSULPILPEN },
   [STM32H7_MODULE_USB2_OTG] = { >AHB1LPENR, RCC_AHB1LPENR_USB2OTGHSLPEN },
-  [STM32H7_MODULE_USB2_OTG_ULPI] = { >AHB1LPENR, 
RCC_AHB1LPENR_USB2OTGHSULPILPEN }
+  [STM32H7_MODULE_USB2_OTG_ULPI] = { >AHB1LPENR, 
RCC_AHB1LPENR_USB2OTGHSULPILPEN },
+  [STM32H7_MODULE_SDMMC1] = { >AHB3LPENR, RCC_AHB3LPENR_SDMMC1LPEN },
+  [STM32H7_MODULE_SDMMC2] = { >AHB2LPENR, RCC_AHB2LPENR_SDMMC2LPEN },
 };
 
 void stm32h7_clk_low_power_enable(stm32h7_module_index index)
-- 
2.26.2

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

[PATCH rtems 2/2] stm32h7: Add init for sdmmc pins.

[Christian Mauderer]

---
 bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c|  2 +
 bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c | 88 ++
 spec/build/bsps/arm/stm32h7/bspstm32h7.yml |  1 +
 3 files changed, 91 insertions(+)
 create mode 100644 bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c

diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c 
b/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
index edafb06def..eb8dbe71f1 100644
--- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
+++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_sd.c
@@ -594,6 +594,7 @@ HAL_StatusTypeDef HAL_SD_DeInit(SD_HandleTypeDef *hsd)
 }
 
 
+#ifndef __rtems__
 /**
   * @brief  Initializes the SD MSP.
   * @param  hsd: Pointer to SD handle
@@ -608,6 +609,7 @@ __weak void HAL_SD_MspInit(SD_HandleTypeDef *hsd)
 the HAL_SD_MspInit could be implemented in the user file
*/
 }
+#endif /* __rtems__ */
 
 /**
   * @brief  De-Initialize SD MSP.
diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c 
b/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
new file mode 100644
index 00..2bbc4ff953
--- /dev/null
+++ b/bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+static const stm32h7_gpio_config gpiob = {
+  .regs = GPIOB,
+  .config = {
+.Pin = GPIO_PIN_8 | GPIO_PIN_9,
+.Mode = GPIO_MODE_AF_PP,
+.Pull = GPIO_NOPULL,
+.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
+.Alternate = GPIO_AF7_SDMMC1
+  }
+};
+
+static const stm32h7_gpio_config gpioc_af12 = {
+  .regs = GPIOC,
+  .config = {
+.Pin = GPIO_PIN_8 | GPIO_PIN_9 | GPIO_PIN_10 | GPIO_PIN_11 | GPIO_PIN_12,
+.Mode = GPIO_MODE_AF_PP,
+.Pull = GPIO_NOPULL,
+.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
+.Alternate = GPIO_AF12_SDMMC1
+  }
+};
+
+static const stm32h7_gpio_config gpioc_af8 = {
+  .regs = GPIOC,
+  .config = {
+.Pin = GPIO_PIN_6 | GPIO_PIN_7,
+.Mode = GPIO_MODE_AF_PP,
+.Pull = GPIO_NOPULL,
+.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
+.Alternate = GPIO_AF8_SDMMC1
+  }
+};
+
+static const stm32h7_gpio_config gpiod = {
+  .regs = GPIOD,
+  .config = {
+.Pin = GPIO_PIN_2,
+.Mode = GPIO_MODE_AF_PP,
+.Pull = GPIO_NOPULL,
+.Speed = GPIO_SPEED_FREQ_VERY_HIGH,
+.Alternate = GPIO_AF12_SDMMC1
+  }
+};
+
+void
+HAL_SD_MspInit(SD_HandleTypeDef *hsd)
+{
+  stm32h7_clk_enable(STM32H7_MODULE_SDMMC1);
+  stm32h7_gpio_init();
+  stm32h7_gpio_init(_af12);
+  stm32h7_gpio_init(_af8);
+  stm32h7_gpio_init();
+  __HAL_RCC_SDMMC1_FORCE_RESET();
+  __HAL_RCC_SDMMC1_RELEASE_RESET();
+}
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
index 80e13472c8..5b3ecc6a89 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
@@ -417,6 +417,7 @@ source:
 - bsps/arm/stm32h7/start/stm32h7-config-per.c
 - bsps/arm/stm32h7/start/stm32h7-config-pwr.c
 - bsps/arm/stm32h7/start/stm32h7-hal-eth.c
+- bsps/arm/stm32h7/start/stm32h7-hal-sdmmc.c
 - bsps/arm/stm32h7/start/stm32h7-hal-uart.c
 - bsps/arm/stm32h7/start/stm32h7-hal.c
 - bsps/arm/stm32h7/start/system_stm32h7xx.c
-- 
2.26.2

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