date:20210810

Re: [PATCH 1/2] score: Replace priority prepend it with flags

2021-08-10 Thread Sebastian Huber


On 10/08/2021 16:50, Sebastian Huber wrote:

On 10/08/2021 16:46, Gedare Bloom wrote:

This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't think what is the
right word however for how you decide to break ties.) So you can just
leave it be for now and ignore my rambling. :)


Thanks for the review. Maybe we have more flags in the future. If not we 
can still rename it after some time.


Actually I am not sure if we really need more flags. What about:

/**
 * @brief The priority group flags indicate if the priority should be 
appended

 *   or prepended to its priority group.
 */
typedef enum {
  /**
   * @brief The priority group prepend flag indicates that the priority 
should

   *   be prepended to its priority group.
   */
  PRIORITY_GROUP_PREPEND = 0,

  /**
   * @brief The priority group append flag indicates that the priority 
should

   *   be appended to its priority group.
   */
  PRIORITY_GROUP_APPEND = 1
} Priority_Group;

--
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: Having a problem with an out of the box setup for STM32F4

2021-08-10 Thread groups

Sorry, I put in newlib and this stupid mail program put in newly.

> On 2021-August-10, at 15:48, Mr. Andrei Chichak  wrote:
> 
> From what I can figure out, there seems to be a problem with the 
> out-of-the-box build of newly that the STM32F4 uses.
> 
> memset() goes for a few ARM instructions and then seems to intentionally 
> branch into, what the map file indicates is, the middle of fflush().
> 
> newly would have been built with this command (from the quick start section 
> of the RTEMS user manual)
> 
> ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
> 6/rtems-arm
> 
> Help. I’m drowning.
> 
> Andrei

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

Re: Having a problem with an out of the box setup for STM32F4

2021-08-10 Thread Mr. Andrei Chichak

From what I can figure out, there seems to be a problem with the out-of-the-box 
build of newly that the STM32F4 uses.

memset() goes for a few ARM instructions and then seems to intentionally branch 
into, what the map file indicates is, the middle of fflush().

newly would have been built with this command (from the quick start section of 
the RTEMS user manual)

../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 6/rtems-arm

Help. I’m drowning.

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

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

2021-08-10 Thread Ida Delphine

Hi everyone,
I was able to successfully build LLVM from source using "ninja" instead of
"make" after a couple of failed attempts because I kept running out of
resources.

Is there anything else I am supposed to do as far building LLVM is
concerned? Or will every user first have to clone the llvm repo and build
it from source like I did?

On Fri, 16 Jul 2021, 5:28 am Chris Johns,  wrote:

> Hi,
>
> I will bring the discussion to the devel list and I hope the comments are
> in
> line with the purpose of the project. Please correct what I say if it is
> not.
>
> The pre-commit script that is in github review is a good base and I
> believe it
> solves that problem for those on Linux. It is a great start and it is nice
> to see.
>
> The work needs to mature and progress and that means a few things. I was
> approached by Joel about where this would live in rtems-tools. As the
> script
> stands it is not suitable for rtems-tool because the format is specific to
> the
> score code in rtems.git.
>
> I think a pre-commit script needs to live in the repo it is for in a spot
> a user
> can copy to the hooks directory of their repo. For example `git-hooks`.
>
> A git hooks script for rtems.git needs to run on all the supported hosts
> or we
> may result in patches being left on the floor. If a contributor's host OS
> is not
> supported and the patch is rejected for formatting reasons picked up by the
> check the contributor may just walk away.
>
> The script should use `/usr/bin/env python3` and it needs to check for a
> range
> of `clang-format` instances. FreeBSD has a package that installs the format
> command as `clang-format10` for LLVM 10 and `clang-format11` for version
> 11.
>
> A contributor being able to run the script may depend on the host having a
> package or packages installed. Given this is for RTEMS development that is
> fine.
> The script needs to handle any set up errors nicely if something is
> missing. I
> prefer we avoid the "experts" approach to error management.
>
> There is possible future work adding a command to rtems-tools. Ida and I
> discussed this on discord and we decided a command called `rtems-style`
> would be
> nice. It would be nice if that command checked, ie `--mode=check`, a style
> as
> well as `--mode=reformat` to automatically reformat a source file.
>
> A command for rtems-tools has to support python2 and python3 and it has to
> handle errors in suitable manner. Printing uncaught exception is not OK. It
> should also be self contained and not depend on any pip python packages.
>
> If an `rtems-style` command is created and installed when rtems-tool is
> installed the pre-commit git script could be made to use it and so the
> style is
> held in a single location.
>
> Finally an rtems-style command could be extended to support python
> (--lang=python) or other styles for other code formats. This is inline
> with our
> other eco-system interfaces we provide.
>
> I hope this helps.
>
> Chris
>
> On 16/7/21 5:13 am, Ida Delphine wrote:
> > I will check on this
> >
> > On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom  > > wrote:
> >
> > On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine  > > wrote:
> > >
> > > Hello everyone,
> > > From the discussion on discord it looks like clang-format cannot be
> > installed on MacOS and FreeBSD. Is there any alternative or way to
> have it
> > on these operating systems?
> > >
> > What are the challenges with them? Can clang-format be built from
> > source on those hosts?
> >
> > > On Wed, 5 May 2021, 10:21 pm Ida Delphine,  > > wrote:
> > >>
> > >> Hello everyone,
> > >>
> > >> Regarding this project (https://devel.rtems.org/ticket/3860
> > ) I went with clang-format as
> we all
> > agreed. I have tested it on some "score" files and it made some
> changes
> > which I don't think are very much in line with the RTEMS coding
> style.
> > However, it wasn't really clear if we will chage the RTEMS coding
> style or
> > try to make changes to clang-format to fit the style.
> > >> Please will love to know the best option.
> > >>
> > >> Cheers,
> > >> Ida.
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org 
> > > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] score: Replace priority prepend it with flags

2021-08-10 Thread Sebastian Huber


On 10/08/2021 16:46, Gedare Bloom wrote:

This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't think what is the
right word however for how you decide to break ties.) So you can just
leave it be for now and ignore my rambling. :)


Thanks for the review. Maybe we have more flags in the future. If not we 
can still rename it after some time.


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

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

Re: [PATCH 2/2] score: Replace the single use of a sequence lock

2021-08-10 Thread Gedare Bloom

ok

On Tue, Aug 10, 2021 at 8:34 AM Sebastian Huber
 wrote:
>
> In SMP configurations, on 64-bit architectures use plain atomic
> operations to set/get the priority value of a scheduler node.  On 32-bit
> architectures use an ISR lock.  Using a sequence lock has no real
> benefit since it uses atomic read-modify-write operations for both the
> read and the write lock.  Simply use a ticket lock instead so that only
> one SMP synchronization primitive is used for everything.
> ---
>  cpukit/include/rtems/score/schedulernode.h| 14 ++--
>  .../include/rtems/score/schedulernodeimpl.h   | 64 +--
>  .../score/src/schedulerdefaultnodedestroy.c   |  4 +-
>  3 files changed, 57 insertions(+), 25 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/schedulernode.h 
> b/cpukit/include/rtems/score/schedulernode.h
> index 1dba200dca..e344479718 100644
> --- a/cpukit/include/rtems/score/schedulernode.h
> +++ b/cpukit/include/rtems/score/schedulernode.h
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  /**
>   * @addtogroup RTEMSScoreScheduler
> @@ -197,14 +197,20 @@ struct Scheduler_Node {
>   * least-significant bit which indicates if the thread should be appended
>   * (bit set) or prepended (bit cleared) to its priority group, see
>   * SCHEDULER_PRIORITY_APPEND().
> + *
> + * @see _Scheduler_Node_get_priority() and 
> _Scheduler_Node_set_priority().
>   */
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +Atomic_Ulong value;
> +#else
>  Priority_Control value;
> +#endif
>
> -#if defined(RTEMS_SMP)
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
>  /**
> - * @brief Sequence lock to synchronize priority value updates.
> + * @brief The lock protects the priority value.
>   */
> -SMP_sequence_lock_Control Lock;
> +ISR_lock_Control Lock;
>  #endif
>} Priority;
>  };
> diff --git a/cpukit/include/rtems/score/schedulernodeimpl.h 
> b/cpukit/include/rtems/score/schedulernodeimpl.h
> index 3da29bb37e..3f90d4a6f5 100644
> --- a/cpukit/include/rtems/score/schedulernodeimpl.h
> +++ b/cpukit/include/rtems/score/schedulernodeimpl.h
> @@ -100,13 +100,36 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_initialize(
>node->Wait.Priority.scheduler = scheduler;
>node->user = the_thread;
>node->idle = NULL;
> -  _SMP_sequence_lock_Initialize( >Priority.Lock );
> +#if CPU_SIZEOF_POINTER != 8
> +  _ISR_lock_Initialize( >Priority.Lock, "Scheduler Node Priority" );
> +#endif
>  #else
>(void) scheduler;
>(void) the_thread;
>  #endif
>  }
>
> +/**
> + * @brief Destroys a node.
> + *
> + * @param scheduler is the scheduler of the node.
> + *
> + * @param[in, out] node is the node to destroy.
> + */
> +RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_destroy(
> +  const struct _Scheduler_Control *scheduler,
> +  Scheduler_Node  *node
> +)
> +{
> +  (void) scheduler;
> +
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
> +  _ISR_lock_Destroy( >Priority.Lock );
> +#else
> +  (void) node;
> +#endif
> +}
> +
>  /**
>   * @brief Gets the scheduler of the node.
>   *
> @@ -148,17 +171,18 @@ RTEMS_INLINE_ROUTINE Priority_Control 
> _Scheduler_Node_get_priority(
>  {
>Priority_Control priority;
>
> -#if defined(RTEMS_SMP)
> -  unsigned int seq;
> -
> -  do {
> -seq = _SMP_sequence_lock_Read_begin( >Priority.Lock );
> -#endif
> -
> -priority = node->Priority.value;
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +  priority = _Atomic_Fetch_add_ulong(
> +>Priority.value,
> +0,
> +ATOMIC_ORDER_RELAXED
> +  );
> +#else
> +  ISR_lock_Context lock_context;
>
> -#if defined(RTEMS_SMP)
> -  } while ( _SMP_sequence_lock_Read_retry( >Priority.Lock, seq ) );
> +  _ISR_lock_Acquire( >Priority.Lock, _context );
> +  priority = node->Priority.value;
> +  _ISR_lock_Release( >Priority.Lock, _context );
>  #endif
>
>return priority;
> @@ -180,16 +204,18 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_set_priority(
>Priority_Flagsflags
>  )
>  {
> -#if defined(RTEMS_SMP)
> -  unsigned int seq;
> -
> -  seq = _SMP_sequence_lock_Write_begin( >Priority.Lock );
> -#endif
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +  _Atomic_Store_ulong(
> +>Priority.value,
> +new_priority | (Priority_Control) flags,
> +ATOMIC_ORDER_RELAXED
> +  );
> +#else
> +  ISR_lock_Context lock_context;
>
> +  _ISR_lock_Acquire( >Priority.Lock, _context );
>node->Priority.value = new_priority | ( (Priority_Control) flags );
> -
> -#if defined(RTEMS_SMP)
> -  _SMP_sequence_lock_Write_end( >Priority.Lock, seq );
> +  _ISR_lock_Release( >Priority.Lock, _context );
>  #endif
>  }
>
> diff --git a/cpukit/score/src/schedulerdefaultnodedestroy.c 
> b/cpukit/score/src/schedulerdefaultnodedestroy.c
> index 796896d854..33cdfd4c69 100644
> --- a/cpukit/score/src/schedulerdefaultnodedestroy.c
> +++ b/cpukit/score/src/schedulerdefaultnodedestroy.c
> @@ -21,12 +21,12 @@
>

Re: [PATCH 1/2] score: Replace priority prepend it with flags

2021-08-10 Thread Gedare Bloom

This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't think what is the
right word however for how you decide to break ties.) So you can just
leave it be for now and ignore my rambling. :)

On Tue, Aug 10, 2021 at 8:34 AM Sebastian Huber
 wrote:
>
> Use an enum instead of a boolean to indicated if a priority should be
> appended or prepended to its priority group.  This makes the code more
> expressive and it a bit more efficient since a branch in
> _Scheduler_Node_set_priority() is avoided.
> ---
>  cpukit/include/rtems/posix/muteximpl.h|  2 +-
>  cpukit/include/rtems/score/coremuteximpl.h|  2 +-
>  cpukit/include/rtems/score/priorityimpl.h | 39 +--
>  cpukit/include/rtems/score/schedulerimpl.h| 12 +-
>  .../include/rtems/score/schedulernodeimpl.h   | 26 ++---
>  cpukit/include/rtems/score/threadimpl.h   | 20 +-
>  cpukit/posix/src/pthreadsetschedparam.c   |  2 +-
>  cpukit/posix/src/pthreadsetschedprio.c|  2 +-
>  cpukit/rtems/src/tasksetpriority.c|  2 +-
>  cpukit/score/src/scheduleredfreleasejob.c |  2 +-
>  cpukit/score/src/threadchangepriority.c   | 36 ++---
>  cpukit/score/src/threadqops.c | 18 -
>  cpukit/score/src/threadrestart.c  |  4 +-
>  testsuites/smptests/smpscheduler03/test.c | 33 +---
>  14 files changed, 116 insertions(+), 84 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/muteximpl.h 
> b/cpukit/include/rtems/posix/muteximpl.h
> index 4a475aac5e..4908f8f259 100644
> --- a/cpukit/include/rtems/posix/muteximpl.h
> +++ b/cpukit/include/rtems/posix/muteximpl.h
> @@ -273,7 +273,7 @@ RTEMS_INLINE_ROUTINE void _POSIX_Mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_APPEND_FLAG,
>queue_context
>  );
>  _Thread_Wait_release( owner, queue_context );
> diff --git a/cpukit/include/rtems/score/coremuteximpl.h 
> b/cpukit/include/rtems/score/coremuteximpl.h
> index b281c52889..c97ffcf351 100644
> --- a/cpukit/include/rtems/score/coremuteximpl.h
> +++ b/cpukit/include/rtems/score/coremuteximpl.h
> @@ -377,7 +377,7 @@ RTEMS_INLINE_ROUTINE void 
> _CORE_ceiling_mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_APPEND_FLAG,
>_context
>  );
>  _Thread_Wait_release_critical( owner, _context );
> diff --git a/cpukit/include/rtems/score/priorityimpl.h 
> b/cpukit/include/rtems/score/priorityimpl.h
> index 7a14ec97b8..4958bfc77f 100644
> --- a/cpukit/include/rtems/score/priorityimpl.h
> +++ b/cpukit/include/rtems/score/priorityimpl.h
> @@ -37,6 +37,24 @@ extern "C" {
>   * @{
>   */
>
> + /**
> +  * @brief The priority flags indicate if the priority should be appended or
> +  *   prepended to its priority group.
> +  */
> +typedef enum {
> +  /**
> +   * @brief Priority prepend flag indicates that the priority should be 
> prepended
> +   *   to its priority group.
> +   */
> +  PRIORITY_PREPEND_FLAG = 0,
> +
> +  /**
> +   * @brief Priority append flag indicates that the priority should be 
> appended
> +   *   to its priority group.
> +   */
> +  PRIORITY_APPEND_FLAG = 1
> +} Priority_Flags;
> +
>  /**
>   * @brief Initializes the priority actions empty.
>   *
> @@ -465,7 +483,7 @@ typedef void ( *Priority_Add_handler )(
>
>  typedef void ( *Priority_Change_handler )(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Flagsflags,
>Priority_Actions *actions,
>void *arg
>  );
> @@ -482,19 +500,19 @@ typedef void ( *Priority_Remove_handler )(
>   * This method does nothing.
>   *
>   * @param aggregation Is ignored by the method.
> - * @param prepend_it Is ignored by the method.
> + * @param flags Is ignored by the method.
>   * @param actions Is ignored by the method.
>   * @param arg Is ignored by the method.
>   */
>  RTEMS_INLINE_ROUTINE void _Priority_Change_nothing(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Flagsflags,
>Priority_Actions *actions,
>void *arg
>  )
>  {
>(void) aggregation;
> -  (void) prepend_it;
> +  (void) flags;
>(void) actions;
>(void) arg;
>  }
> @@ -547,7 +565,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Non_empty_insert(
>
>if ( is_new_minimum ) {
>  aggregation->Node.priority = node->priority;
> -( *change )( aggregation, false, actions, arg );
> +( *change )( aggregation, PRIORITY_APPEND_FLAG, actions, arg );
>}
>  }
>
> @@ -619,7 +637,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Extract(
>
>  if ( node->priority < min->priority ) {
>

Re: [PATCH] rtems: Fix rtems_partition_return_buffer()

2021-08-10 Thread Gedare Bloom

looks good, maybe one small clarification:

On Tue, Aug 10, 2021 at 4:44 AM Sebastian Huber
 wrote:
>
> The rtems_partition_return_buffer() wrongly accepted which were exactly
> at the buffer area end.  Use the buffer area limit address for the range
> checking.
>
> Close #4490.
> ---
>  cpukit/include/rtems/monitor.h|  2 +-
>  cpukit/include/rtems/rtems/partdata.h |  9 -
>  cpukit/libmisc/monitor/mon-part.c |  5 +++--
>  cpukit/rtems/src/partcreate.c |  8 ++--
>  cpukit/rtems/src/partreturnbuffer.c   | 17 ++---
>  5 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/cpukit/include/rtems/monitor.h b/cpukit/include/rtems/monitor.h
> index d0a79c03be..9367e2b6e8 100644
> --- a/cpukit/include/rtems/monitor.h
> +++ b/cpukit/include/rtems/monitor.h
> @@ -192,7 +192,7 @@ typedef struct {
>  rtems_name  name;
>/* end of common portion */
>rtems_attribute attribute;
> -  void *  start_addr;
> +  const void *start_addr;
>uint32_tlength;
>uint32_tbuf_size;
>uint32_tused_blocks;
> diff --git a/cpukit/include/rtems/rtems/partdata.h 
> b/cpukit/include/rtems/rtems/partdata.h
> index 4f4132ac6b..4c4eca3d17 100644
> --- a/cpukit/include/rtems/rtems/partdata.h
> +++ b/cpukit/include/rtems/rtems/partdata.h
> @@ -50,15 +50,14 @@ typedef struct {
>  #endif
>
>/**
> -   * @brief This member contains the physical starting address of the buffer
> -   *   area.
> +   * @brief This member contains the base address of the buffer area.
Probably it is clear, but could add here "This is the address of the
first valid byte in the buffer." to mirror the suggestion below that
clarifies the meaning of limit.

> */
> -  void *starting_address;
> +  const void *base_address;
>
>/**
> -   * @brief This member contains the size of the buffer area in bytes.
> +   * @brief This member contains the limit address of the buffer area.
Maybe add: "This is the address of the last valid byte in the buffer."

> */
> -  uintptr_t length;
> +  const void *limit_address;
>
>/**
> * @brief This member contains the size of each buffer in bytes.
> diff --git a/cpukit/libmisc/monitor/mon-part.c 
> b/cpukit/libmisc/monitor/mon-part.c
> index 18034cd58f..654700ebfc 100644
> --- a/cpukit/libmisc/monitor/mon-part.c
> +++ b/cpukit/libmisc/monitor/mon-part.c
> @@ -22,8 +22,9 @@ rtems_monitor_part_canonical(
>  const Partition_Control *rtems_part = (const Partition_Control *) 
> part_void;
>
>  canonical_part->attribute = rtems_part->attribute_set;
> -canonical_part->start_addr = rtems_part->starting_address;
> -canonical_part->length = rtems_part->length;
> +canonical_part->start_addr = rtems_part->base_address;
> +canonical_part->length = (uint32_t) ( (uintptr_t)
> +rtems_part->limit_address + 1 - (uintptr_t) rtems_part->base_address 
> );
>  canonical_part->buf_size = rtems_part->buffer_size;
>  canonical_part->used_blocks = rtems_part->number_of_used_blocks;
>  }
> diff --git a/cpukit/rtems/src/partcreate.c b/cpukit/rtems/src/partcreate.c
> index 012a416a1a..61249749f3 100644
> --- a/cpukit/rtems/src/partcreate.c
> +++ b/cpukit/rtems/src/partcreate.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,8 +41,11 @@ static void _Partition_Initialize(
>rtems_attributeattribute_set
>  )
>  {
> -  the_partition->starting_address  = starting_address;
> -  the_partition->length= length;
> +  const void *limit_address;
> +
> +  limit_address = _Addresses_Add_offset( starting_address, length - 1 );
> +  the_partition->base_address  = starting_address;
> +  the_partition->limit_address = limit_address;
>the_partition->buffer_size   = buffer_size;
>the_partition->attribute_set = attribute_set;
>the_partition->number_of_used_blocks = 0;
> diff --git a/cpukit/rtems/src/partreturnbuffer.c 
> b/cpukit/rtems/src/partreturnbuffer.c
> index f5ab7d85f9..68302f1163 100644
> --- a/cpukit/rtems/src/partreturnbuffer.c
> +++ b/cpukit/rtems/src/partreturnbuffer.c
> @@ -33,7 +33,7 @@ static bool _Partition_Is_address_on_buffer_boundary(
>
>offset = _Addresses_Subtract(
>  the_buffer,
> -the_partition->starting_address
> +the_partition->base_address
>);
>
>return ( offset % the_partition->buffer_size ) == 0;
> @@ -44,14 +44,17 @@ static bool _Partition_Is_address_a_buffer_begin(
> const void  *the_buffer
>  )
>  {
> -  void *starting;
> -  void *ending;
> +  const void *base;
> +  const void *limit;
>
> -  starting = the_partition->starting_address;
> -  ending   = _Addresses_Add_offset( starting, the_partition->length );
> +  base = the_partition->base_address;
> +  limit = the_partition->limit_address;
>
> -  return _Addresses_Is_in_range( the_buffer, starting, ending )
> -&&

[PATCH 2/2] score: Replace the single use of a sequence lock

2021-08-10 Thread Sebastian Huber

In SMP configurations, on 64-bit architectures use plain atomic
operations to set/get the priority value of a scheduler node.  On 32-bit
architectures use an ISR lock.  Using a sequence lock has no real
benefit since it uses atomic read-modify-write operations for both the
read and the write lock.  Simply use a ticket lock instead so that only
one SMP synchronization primitive is used for everything.
---
 cpukit/include/rtems/score/schedulernode.h| 14 ++--
 .../include/rtems/score/schedulernodeimpl.h   | 64 +--
 .../score/src/schedulerdefaultnodedestroy.c   |  4 +-
 3 files changed, 57 insertions(+), 25 deletions(-)

diff --git a/cpukit/include/rtems/score/schedulernode.h 
b/cpukit/include/rtems/score/schedulernode.h
index 1dba200dca..e344479718 100644
--- a/cpukit/include/rtems/score/schedulernode.h
+++ b/cpukit/include/rtems/score/schedulernode.h
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /**
  * @addtogroup RTEMSScoreScheduler
@@ -197,14 +197,20 @@ struct Scheduler_Node {
  * least-significant bit which indicates if the thread should be appended
  * (bit set) or prepended (bit cleared) to its priority group, see
  * SCHEDULER_PRIORITY_APPEND().
+ *
+ * @see _Scheduler_Node_get_priority() and _Scheduler_Node_set_priority().
  */
+#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
+Atomic_Ulong value;
+#else
 Priority_Control value;
+#endif
 
-#if defined(RTEMS_SMP)
+#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
 /**
- * @brief Sequence lock to synchronize priority value updates.
+ * @brief The lock protects the priority value.
  */
-SMP_sequence_lock_Control Lock;
+ISR_lock_Control Lock;
 #endif
   } Priority;
 };
diff --git a/cpukit/include/rtems/score/schedulernodeimpl.h 
b/cpukit/include/rtems/score/schedulernodeimpl.h
index 3da29bb37e..3f90d4a6f5 100644
--- a/cpukit/include/rtems/score/schedulernodeimpl.h
+++ b/cpukit/include/rtems/score/schedulernodeimpl.h
@@ -100,13 +100,36 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_initialize(
   node->Wait.Priority.scheduler = scheduler;
   node->user = the_thread;
   node->idle = NULL;
-  _SMP_sequence_lock_Initialize( >Priority.Lock );
+#if CPU_SIZEOF_POINTER != 8
+  _ISR_lock_Initialize( >Priority.Lock, "Scheduler Node Priority" );
+#endif
 #else
   (void) scheduler;
   (void) the_thread;
 #endif
 }
 
+/**
+ * @brief Destroys a node.
+ *
+ * @param scheduler is the scheduler of the node.
+ *
+ * @param[in, out] node is the node to destroy.
+ */
+RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_destroy(
+  const struct _Scheduler_Control *scheduler,
+  Scheduler_Node  *node
+)
+{
+  (void) scheduler;
+
+#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
+  _ISR_lock_Destroy( >Priority.Lock );
+#else
+  (void) node;
+#endif
+}
+
 /**
  * @brief Gets the scheduler of the node.
  *
@@ -148,17 +171,18 @@ RTEMS_INLINE_ROUTINE Priority_Control 
_Scheduler_Node_get_priority(
 {
   Priority_Control priority;
 
-#if defined(RTEMS_SMP)
-  unsigned int seq;
-
-  do {
-seq = _SMP_sequence_lock_Read_begin( >Priority.Lock );
-#endif
-
-priority = node->Priority.value;
+#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
+  priority = _Atomic_Fetch_add_ulong(
+>Priority.value,
+0,
+ATOMIC_ORDER_RELAXED
+  );
+#else
+  ISR_lock_Context lock_context;
 
-#if defined(RTEMS_SMP)
-  } while ( _SMP_sequence_lock_Read_retry( >Priority.Lock, seq ) );
+  _ISR_lock_Acquire( >Priority.Lock, _context );
+  priority = node->Priority.value;
+  _ISR_lock_Release( >Priority.Lock, _context );
 #endif
 
   return priority;
@@ -180,16 +204,18 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_set_priority(
   Priority_Flagsflags
 )
 {
-#if defined(RTEMS_SMP)
-  unsigned int seq;
-
-  seq = _SMP_sequence_lock_Write_begin( >Priority.Lock );
-#endif
+#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
+  _Atomic_Store_ulong(
+>Priority.value,
+new_priority | (Priority_Control) flags,
+ATOMIC_ORDER_RELAXED
+  );
+#else
+  ISR_lock_Context lock_context;
 
+  _ISR_lock_Acquire( >Priority.Lock, _context );
   node->Priority.value = new_priority | ( (Priority_Control) flags );
-
-#if defined(RTEMS_SMP)
-  _SMP_sequence_lock_Write_end( >Priority.Lock, seq );
+  _ISR_lock_Release( >Priority.Lock, _context );
 #endif
 }
 
diff --git a/cpukit/score/src/schedulerdefaultnodedestroy.c 
b/cpukit/score/src/schedulerdefaultnodedestroy.c
index 796896d854..33cdfd4c69 100644
--- a/cpukit/score/src/schedulerdefaultnodedestroy.c
+++ b/cpukit/score/src/schedulerdefaultnodedestroy.c
@@ -21,12 +21,12 @@
 #endif
 
 #include 
+#include 
 
 void _Scheduler_default_Node_destroy(
   const Scheduler_Control *scheduler,
   Scheduler_Node  *node
 )
 {
-  (void) scheduler;
-  (void) node;
+  _Scheduler_Node_do_destroy( scheduler, node );
 }
-- 
2.26.2

___
devel mailing list
devel@rtems.org

[PATCH 1/2] score: Replace priority prepend it with flags

2021-08-10 Thread Sebastian Huber

Use an enum instead of a boolean to indicated if a priority should be
appended or prepended to its priority group.  This makes the code more
expressive and it a bit more efficient since a branch in
_Scheduler_Node_set_priority() is avoided.
---
 cpukit/include/rtems/posix/muteximpl.h|  2 +-
 cpukit/include/rtems/score/coremuteximpl.h|  2 +-
 cpukit/include/rtems/score/priorityimpl.h | 39 +--
 cpukit/include/rtems/score/schedulerimpl.h| 12 +-
 .../include/rtems/score/schedulernodeimpl.h   | 26 ++---
 cpukit/include/rtems/score/threadimpl.h   | 20 +-
 cpukit/posix/src/pthreadsetschedparam.c   |  2 +-
 cpukit/posix/src/pthreadsetschedprio.c|  2 +-
 cpukit/rtems/src/tasksetpriority.c|  2 +-
 cpukit/score/src/scheduleredfreleasejob.c |  2 +-
 cpukit/score/src/threadchangepriority.c   | 36 ++---
 cpukit/score/src/threadqops.c | 18 -
 cpukit/score/src/threadrestart.c  |  4 +-
 testsuites/smptests/smpscheduler03/test.c | 33 +---
 14 files changed, 116 insertions(+), 84 deletions(-)

diff --git a/cpukit/include/rtems/posix/muteximpl.h 
b/cpukit/include/rtems/posix/muteximpl.h
index 4a475aac5e..4908f8f259 100644
--- a/cpukit/include/rtems/posix/muteximpl.h
+++ b/cpukit/include/rtems/posix/muteximpl.h
@@ -273,7 +273,7 @@ RTEMS_INLINE_ROUTINE void _POSIX_Mutex_Set_priority(
   owner,
   _mutex->Priority_ceiling,
   priority_ceiling,
-  false,
+  PRIORITY_APPEND_FLAG,
   queue_context
 );
 _Thread_Wait_release( owner, queue_context );
diff --git a/cpukit/include/rtems/score/coremuteximpl.h 
b/cpukit/include/rtems/score/coremuteximpl.h
index b281c52889..c97ffcf351 100644
--- a/cpukit/include/rtems/score/coremuteximpl.h
+++ b/cpukit/include/rtems/score/coremuteximpl.h
@@ -377,7 +377,7 @@ RTEMS_INLINE_ROUTINE void _CORE_ceiling_mutex_Set_priority(
   owner,
   _mutex->Priority_ceiling,
   priority_ceiling,
-  false,
+  PRIORITY_APPEND_FLAG,
   _context
 );
 _Thread_Wait_release_critical( owner, _context );
diff --git a/cpukit/include/rtems/score/priorityimpl.h 
b/cpukit/include/rtems/score/priorityimpl.h
index 7a14ec97b8..4958bfc77f 100644
--- a/cpukit/include/rtems/score/priorityimpl.h
+++ b/cpukit/include/rtems/score/priorityimpl.h
@@ -37,6 +37,24 @@ extern "C" {
  * @{
  */
 
+ /**
+  * @brief The priority flags indicate if the priority should be appended or
+  *   prepended to its priority group.
+  */
+typedef enum {
+  /**
+   * @brief Priority prepend flag indicates that the priority should be 
prepended
+   *   to its priority group.
+   */
+  PRIORITY_PREPEND_FLAG = 0,
+
+  /**
+   * @brief Priority append flag indicates that the priority should be appended
+   *   to its priority group.
+   */
+  PRIORITY_APPEND_FLAG = 1
+} Priority_Flags;
+
 /**
  * @brief Initializes the priority actions empty.
  *
@@ -465,7 +483,7 @@ typedef void ( *Priority_Add_handler )(
 
 typedef void ( *Priority_Change_handler )(
   Priority_Aggregation *aggregation,
-  bool  prepend_it,
+  Priority_Flagsflags,
   Priority_Actions *actions,
   void *arg
 );
@@ -482,19 +500,19 @@ typedef void ( *Priority_Remove_handler )(
  * This method does nothing.
  *
  * @param aggregation Is ignored by the method.
- * @param prepend_it Is ignored by the method.
+ * @param flags Is ignored by the method.
  * @param actions Is ignored by the method.
  * @param arg Is ignored by the method.
  */
 RTEMS_INLINE_ROUTINE void _Priority_Change_nothing(
   Priority_Aggregation *aggregation,
-  bool  prepend_it,
+  Priority_Flagsflags,
   Priority_Actions *actions,
   void *arg
 )
 {
   (void) aggregation;
-  (void) prepend_it;
+  (void) flags;
   (void) actions;
   (void) arg;
 }
@@ -547,7 +565,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Non_empty_insert(
 
   if ( is_new_minimum ) {
 aggregation->Node.priority = node->priority;
-( *change )( aggregation, false, actions, arg );
+( *change )( aggregation, PRIORITY_APPEND_FLAG, actions, arg );
   }
 }
 
@@ -619,7 +637,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Extract(
 
 if ( node->priority < min->priority ) {
   aggregation->Node.priority = min->priority;
-  ( *change )( aggregation, true, actions, arg );
+  ( *change )( aggregation, PRIORITY_PREPEND_FLAG, actions, arg );
 }
   }
 }
@@ -654,7 +672,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Extract_non_empty(
 
   if ( node->priority < min->priority ) {
 aggregation->Node.priority = min->priority;
-( *change )( aggregation, true, actions, arg );
+( *change )( aggregation, PRIORITY_PREPEND_FLAG, actions, arg );
   }
 }
 
@@ -666,8 +684,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Extract_non_empty(
  *
  * @param[in, out] aggregation The aggregation to change the node in.
  * @param node The node that has a new priority and

Re: [PATCH v4] bsps: Move optfdt* files to shared parent directory

2021-08-10 Thread Alan Cudmore

The master branch works for me. I tried the raspberrypi and
raspberrypi2 BSPS and they work fine. I built the beagleboneblack BSP
but did not run it.

When this one line patch is installed, SMP works too:
https://lists.rtems.org/pipermail/devel/2021-August/068832.html
Alan

On Mon, Aug 9, 2021 at 1:37 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Aug 9, 2021, 10:14 AM Pranav Dangi  wrote:
>>
>> Hi joel,
>> I had sent you a rebased patch as a direct attachment, I will ping that 
>> thread once again. Did that fail too?
>
>
> I just pushed a patch you sent me directly. Is it ok on master now?
>
> --joel
>>
>>
>> Thanks,
>> pranav
>>
>> On Mon, 9 Aug 2021, 20:40 Joel Sherrill,  wrote:
>>>
>>> On Mon, Aug 9, 2021 at 10:00 AM Gedare Bloom  wrote:
>>> >
>>> > Hi Joel,
>>> >
>>> > On Fri, Jul 16, 2021 at 10:40 AM Joel Sherrill  wrote:
>>> > >
>>> > > I'm doing a build sweep of all BSPs. When that completes, I plan to
>>> > > push this unless there are comments.
>>> > >
>>> > Did/can you push this?
>>>
>>> It doesn't apply for me. Could be a rebase is needed or it didn't survive
>>> the email client. If it's just an email issue, just send it to me directly 
>>> as an
>>> attachment possibly compressed to avoid any chance of email clients
>>> getting smart.
>>>
>>> Applying: bsps: Move optfdt* files to shared parent directory
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtro.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/beagle/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/beagle/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtcpyro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtmxsz.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtro.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/arm/imx/optfdtuboot.yml:1
>>> error: spec/build/bsps/arm/imx/optfdtuboot.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/powerpc/qoriq/optfdtro.yml:1
>>> error: spec/build/bsps/powerpc/qoriq/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtcpyro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtcpyro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtmxsz.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtmxsz.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtro.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtro.yml: patch does not apply
>>> error: patch failed: spec/build/bsps/riscv/riscv/optfdtuboot.yml:1
>>> error: spec/build/bsps/riscv/riscv/optfdtuboot.yml: patch does not apply
>>> Patch failed at 0001 bsps: Move optfdt* files to shared parent directory
>>> The copy of the patch that failed is found in:
>>>/home/joel/rtems-work/rtems/.git/rebase-apply/patch
>>>
>>>
>>> >
>>> > > On Fri, Jul 16, 2021 at 9:51 AM pranav  wrote:
>>> > > >
>>> > > > ---
>>> > > >  .../arm/altera-cyclone-v/bspalteracyclonev.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/grp.yml  |  8 
>>> > > >  spec/build/bsps/arm/beagle/optfdtcpyro.yml  | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtmxsz.yml   | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/beagle/optfdtro.yml | 16 
>>> > > >  spec/build/bsps/arm/beagle/optfdtuboot.yml  | 16 
>>> > > >  spec/build/bsps/arm/imx/bspimx.yml  |  8 
>>> > > >  spec/build/bsps/arm/imx/optfdtcpyro.yml | 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtmxsz.yml  | 17 
>>> > > > -
>>> > > >  spec/build/bsps/arm/imx/optfdtro.yml| 16 
>>> > > >  spec/build/bsps/arm/imx/optfdtuboot.yml | 16 
>>> > > >  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml  |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml   |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtro.yml |  0
>>> > > >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml  |  0
>>> > > >  spec/build/bsps/powerpc/qoriq/grp.yml   |  4 ++--
>>> > > >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml| 17 
>>> > > >

[PATCH] rtems: Fix rtems_partition_return_buffer()

2021-08-10 Thread Sebastian Huber

The rtems_partition_return_buffer() wrongly accepted which were exactly
at the buffer area end.  Use the buffer area limit address for the range
checking.

Close #4490.
---
 cpukit/include/rtems/monitor.h|  2 +-
 cpukit/include/rtems/rtems/partdata.h |  9 -
 cpukit/libmisc/monitor/mon-part.c |  5 +++--
 cpukit/rtems/src/partcreate.c |  8 ++--
 cpukit/rtems/src/partreturnbuffer.c   | 17 ++---
 5 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/cpukit/include/rtems/monitor.h b/cpukit/include/rtems/monitor.h
index d0a79c03be..9367e2b6e8 100644
--- a/cpukit/include/rtems/monitor.h
+++ b/cpukit/include/rtems/monitor.h
@@ -192,7 +192,7 @@ typedef struct {
 rtems_name  name;
   /* end of common portion */
   rtems_attribute attribute;
-  void *  start_addr;
+  const void *start_addr;
   uint32_tlength;
   uint32_tbuf_size;
   uint32_tused_blocks;
diff --git a/cpukit/include/rtems/rtems/partdata.h 
b/cpukit/include/rtems/rtems/partdata.h
index 4f4132ac6b..4c4eca3d17 100644
--- a/cpukit/include/rtems/rtems/partdata.h
+++ b/cpukit/include/rtems/rtems/partdata.h
@@ -50,15 +50,14 @@ typedef struct {
 #endif
 
   /**
-   * @brief This member contains the physical starting address of the buffer
-   *   area.
+   * @brief This member contains the base address of the buffer area.
*/
-  void *starting_address;
+  const void *base_address;
 
   /**
-   * @brief This member contains the size of the buffer area in bytes.
+   * @brief This member contains the limit address of the buffer area.
*/
-  uintptr_t length;
+  const void *limit_address;
 
   /**
* @brief This member contains the size of each buffer in bytes.
diff --git a/cpukit/libmisc/monitor/mon-part.c 
b/cpukit/libmisc/monitor/mon-part.c
index 18034cd58f..654700ebfc 100644
--- a/cpukit/libmisc/monitor/mon-part.c
+++ b/cpukit/libmisc/monitor/mon-part.c
@@ -22,8 +22,9 @@ rtems_monitor_part_canonical(
 const Partition_Control *rtems_part = (const Partition_Control *) 
part_void;
 
 canonical_part->attribute = rtems_part->attribute_set;
-canonical_part->start_addr = rtems_part->starting_address;
-canonical_part->length = rtems_part->length;
+canonical_part->start_addr = rtems_part->base_address;
+canonical_part->length = (uint32_t) ( (uintptr_t)
+rtems_part->limit_address + 1 - (uintptr_t) rtems_part->base_address );
 canonical_part->buf_size = rtems_part->buffer_size;
 canonical_part->used_blocks = rtems_part->number_of_used_blocks;
 }
diff --git a/cpukit/rtems/src/partcreate.c b/cpukit/rtems/src/partcreate.c
index 012a416a1a..61249749f3 100644
--- a/cpukit/rtems/src/partcreate.c
+++ b/cpukit/rtems/src/partcreate.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,8 +41,11 @@ static void _Partition_Initialize(
   rtems_attributeattribute_set
 )
 {
-  the_partition->starting_address  = starting_address;
-  the_partition->length= length;
+  const void *limit_address;
+
+  limit_address = _Addresses_Add_offset( starting_address, length - 1 );
+  the_partition->base_address  = starting_address;
+  the_partition->limit_address = limit_address;
   the_partition->buffer_size   = buffer_size;
   the_partition->attribute_set = attribute_set;
   the_partition->number_of_used_blocks = 0;
diff --git a/cpukit/rtems/src/partreturnbuffer.c 
b/cpukit/rtems/src/partreturnbuffer.c
index f5ab7d85f9..68302f1163 100644
--- a/cpukit/rtems/src/partreturnbuffer.c
+++ b/cpukit/rtems/src/partreturnbuffer.c
@@ -33,7 +33,7 @@ static bool _Partition_Is_address_on_buffer_boundary(
 
   offset = _Addresses_Subtract(
 the_buffer,
-the_partition->starting_address
+the_partition->base_address
   );
 
   return ( offset % the_partition->buffer_size ) == 0;
@@ -44,14 +44,17 @@ static bool _Partition_Is_address_a_buffer_begin(
const void  *the_buffer
 )
 {
-  void *starting;
-  void *ending;
+  const void *base;
+  const void *limit;
 
-  starting = the_partition->starting_address;
-  ending   = _Addresses_Add_offset( starting, the_partition->length );
+  base = the_partition->base_address;
+  limit = the_partition->limit_address;
 
-  return _Addresses_Is_in_range( the_buffer, starting, ending )
-&& _Partition_Is_address_on_buffer_boundary( the_partition, the_buffer );
+  if ( !_Addresses_Is_in_range( the_buffer, base, limit ) ) {
+return false;
+  }
+
+  return _Partition_Is_address_on_buffer_boundary( the_partition, the_buffer );
 }
 
 static void _Partition_Free_buffer(
-- 
2.26.2

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

Re: Guidance on constructing an RTEMS6 BSP

2021-08-10 Thread Sebastian Huber


On 10/08/2021 08:31, gro...@chichak.ca wrote:
../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
--target=arm-rtems6 --with-rtems-bsp=stm32f4 --with-rtems-tests=yes 
6/rtems-kernel


I usually build the tools with the RSB and then separately build the BSP 
from a Git clone.


--
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: Guidance on constructing an RTEMS6 BSP

2021-08-10 Thread groups

Hi Sebastian,

So far there is no code. The BSP won’t build. The only code is:

../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 
--target=arm-rtems6 --with-rtems-bsp=stm32f4 --with-rtems-tests=yes 
6/rtems-kernel


Andrei



> On 2021-August-10, at 00:20, Sebastian Huber 
>  > wrote:
> 
> Hello Andrei,
> 
> sorry, I am a bit busy at the moment. I would try to share as much code as 
> possible (not easy with the STM source code organization) and use BSP options 
> to customize for the variants.
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de 
> 
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/ 
> 

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

Re: [PATCH 1/2] score: Replace priority prepend it with flags

Re: Having a problem with an out of the box setup for STM32F4

Re: Having a problem with an out of the box setup for STM32F4

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

Re: [PATCH 1/2] score: Replace priority prepend it with flags

Re: [PATCH 2/2] score: Replace the single use of a sequence lock

Re: [PATCH 1/2] score: Replace priority prepend it with flags

Re: [PATCH] rtems: Fix rtems_partition_return_buffer()

[PATCH 2/2] score: Replace the single use of a sequence lock

[PATCH 1/2] score: Replace priority prepend it with flags

Re: [PATCH v4] bsps: Move optfdt* files to shared parent directory

[PATCH] rtems: Fix rtems_partition_return_buffer()

Re: Guidance on constructing an RTEMS6 BSP

Re: Guidance on constructing an RTEMS6 BSP

14 matches

Site Navigation

Mail list logo

Footer information