from:"Martin Erik Werner"

[PATCH] Avoid StopIteration exception for non-rtems .pc

2023-10-05 Thread Martin Erik Werner

_arch_from_arch_bsp() and _bsp_from_arch_bsp() has overly optimistic
assumptions that the argument must contain a '-'-separated field which
starts with "rtems". These functions are intended to find the target
triplet or the bsp parts of strings like "sparc-gaisler-rtems5-leon3"
and "arm-rtems6-xilinx_zynq_zc702"

But _find_installed_arch_bsps() may call _arch_from_arch_bsp() with the
name (without file extension) of any file which ends with ".pc",
including for example "expat". This triggers a StopIteration exception
when trying to find the next field after the "rtems" field, since no
"rtems" field exists to start with.

Rework these function to remove the preconditions, so that they return
None if no "rtems" field exist or if no field exists before or after the
"rtems" field.

It could be argued. based on their name, that calling these functions
with something that is not a triplet-bsp string is incorrect to start
with, but attempting to address that is not done here.
---

This should fix the issue discovered by David Siddons and Frank Kühndel
described in the "build failed" thread from 2023-07-23 in the
rtems-users mailing list with message-id:
<8e6c2841-ae9e-aacf-de84-e6340d204...@embedded-brains.de>

I have tested this fix when compiling the simple quickstart application
for the sparc-gaisler-rtems5-leon3 and arm-rtems6-xilinx_zynq_zc702
targets, but I have not verified execution of the build results, this is
probably the amount of testing that I will be able to perform at the
moment.

 rtems.py | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/rtems.py b/rtems.py
index c65a7d2..a29d281 100644
--- a/rtems.py
+++ b/rtems.py
@@ -859,15 +859,17 @@ def _check_arch_bsps(req, config, path, archs, version):
 
 def _arch_from_arch_bsp(arch_bsp):
 fields = arch_bsp.split('-')
-rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
-return '-'.join(fields[:(rtems_field_index + 1)])
-
+for i, field in enumerate(fields):
+if field.startswith('rtems') and fields[:(i + 1)] is not None:
+return '-'.join(fields[:(i + 1)])
+return None
 
 def _bsp_from_arch_bsp(arch_bsp):
 fields = arch_bsp.split('-')
-rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
-return '-'.join(fields[(rtems_field_index + 1):])
-
+for i, field in enumerate(fields):
+if field.startswith('rtems') and fields[(i + 1):] is not None:
+return '-'.join(fields[(i + 1):])
+return None
 
 def _pkgconfig_path(path):
 return os.path.join(path, 'lib', 'pkgconfig')
-- 
2.30.2

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

[PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet

2023-05-24 Thread Martin Erik Werner

Rework the splitting of arch and bsp to rely on the last field in the
arch section starting with "rtems", instead of relying on the arch being
exactly two fields in size.

This makes sure that toolchains with a vendor field in their target
triplet can be used with this build system.

Toolchains produced by the RTEMS source builder tend to omit the vendor
field, but for example the SPARC LEON/ERC32 toolchain provided by
Gaisler through the RCC package does include a vendor field.
---

v2 fixes an off-by-one error in list indexing compared to v1.

 rtems.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/rtems.py b/rtems.py
index 0b24645..c65a7d2 100644
--- a/rtems.py
+++ b/rtems.py
@@ -858,11 +858,15 @@ def _check_arch_bsps(req, config, path, archs, version):
 
 
 def _arch_from_arch_bsp(arch_bsp):
-return '-'.join(arch_bsp.split('-')[:2])
+fields = arch_bsp.split('-')
+rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
+return '-'.join(fields[:(rtems_field_index + 1)])
 
 
 def _bsp_from_arch_bsp(arch_bsp):
-return '-'.join(arch_bsp.split('-')[2:])
+fields = arch_bsp.split('-')
+rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
+return '-'.join(fields[(rtems_field_index + 1):])
 
 
 def _pkgconfig_path(path):
-- 
2.30.2

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

[PATCH rtems_waf] Allow vendor field in toolchain target triplet

2023-05-24 Thread Martin Erik Werner

Rework the splitting of arch and bsp to rely on the last field in the
arch section starting with "rtems", instead of relying on the arch being
exactly two fields in size.

This makes sure that toolchains with a vendor field in their target
triplet can be used with this build system.

Toolchains produced by the RTEMS source builder tend to omit the vendor
field, but for example the SPARC LEON/ERC32 toolchain provided by
Gaisler through the RCC package does include a vendor field.
---
 rtems.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/rtems.py b/rtems.py
index 0b24645..076560d 100644
--- a/rtems.py
+++ b/rtems.py
@@ -858,11 +858,15 @@ def _check_arch_bsps(req, config, path, archs, version):
 
 
 def _arch_from_arch_bsp(arch_bsp):
-return '-'.join(arch_bsp.split('-')[:2])
+fields = arch_bsp.split('-')
+rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
+return '-'.join(fields[:(rtems_field_index + 1)])
 
 
 def _bsp_from_arch_bsp(arch_bsp):
-return '-'.join(arch_bsp.split('-')[2:])
+fields = arch_bsp.split('-')
+rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
+return '-'.join(fields[rtems_field_index:])
 
 
 def _pkgconfig_path(path):
-- 
2.30.2

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

[PATCH rtems-docs 2/2] c-user/message/directives.rst: Regen from spec

2023-02-11 Thread Martin Erik Werner

Regenerate message queue directives from the rtems-central spec in
order
to include the detailed note about non-atomicity of broadcast.

This file is selectively added, other changes in generated files are
omitted.

Update #4804.
---
 c-user/message/directives.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/c-user/message/directives.rst b/c-
user/message/directives.rst
index a13e4c7..ac53ec4 100644
--- a/c-user/message/directives.rst
+++ b/c-user/message/directives.rst
@@ -758,6 +758,14 @@ The execution time of this directive is directly
related to the number of tasks
 waiting on the message queue, although it is more efficient than the
equivalent
 number of invocations of :ref:`InterfaceRtemsMessageQueueSend`.
 
+:ref:`InterfaceRtemsMessageQueueBroadcast` unblocks :term:`receivers
+` in a non-atomic way. Meaning, it will not only
:term:`unblock`
+those :term:`receivers ` it finds waiting at the queue when
+:ref:`InterfaceRtemsMessageQueueBroadcast` is invoked but also any new
+:term:`receivers ` which start waiting for messages after
+:ref:`InterfaceRtemsMessageQueueBroadcast` is invoked and before it
returns.
+This may lead to infinite unblocking loops.
+
 .. rubric:: CONSTRAINTS:
 
 The following constraints apply to this directive:
-- 
2.30.2

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

[PATCH rtems-docs 1/2] c-user/message/operations.rst: Don't claim atomic

2023-02-11 Thread Martin Erik Werner

rtems_message_queue_broadcast() is not atomic, since it unblocks each
task after copying the message into their message buffer. So remove the
wording indicating that it is atomic.

Also reword the overall description slightly with "each" instead of
"every", and add "until no more tasks remain", in order to further hint
at the non-atomicity of the operation.

Update #4804.
---
 c-user/message/operations.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/c-user/message/operations.rst b/c-
user/message/operations.rst
index 4d34661..46081a3 100644
--- a/c-user/message/operations.rst
+++ b/c-user/message/operations.rst
@@ -70,8 +70,8 @@ queue which has a full queue of pending messages.
 Broadcasting a Message
 --
 
-The ``rtems_message_queue_broadcast`` directive sends the same message
to every
-task waiting on the specified message queue as an atomic operation. 
The
+The ``rtems_message_queue_broadcast`` directive sends the same message
to each
+task waiting on the specified message queue until no more tasks
remain.  The
 message is copied to each waiting task's message buffer and each task
is
 unblocked.  The number of tasks which were unblocked is returned to
the caller.
 
-- 
2.30.2


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

[PATCH rtems-central 2/2] spec: Add msg broadcast non-atomicity note to doc

2023-02-11 Thread Martin Erik Werner

rtems_message_queue_broadcast() may, under certain circumstances, copy
the message to tasks which were not waiting on the message queue when
the broadcast started, and may copy the message multiple times to the
same task.

This behaviour is, based on discussion in #4804, something that might
be
unlikely to change.

Expose the note regarding this behaviour that already existed in
the requirement spec in the main documentation as well. Removing the
"Currently" wording.

Update #4804.
---
 modules/rtems-docs  | 2 +-
 spec/rtems/message/if/broadcast.yml | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/modules/rtems-docs b/modules/rtems-docs
index cb375249..e4e70bc5 16
--- a/modules/rtems-docs
+++ b/modules/rtems-docs
@@ -1 +1 @@
-Subproject commit cb375249c59bf7542c4115668dcfbcd7d50d41de
+Subproject commit e4e70bc54c581d01a988fde075c711f3c6acc9e5
diff --git a/spec/rtems/message/if/broadcast.yml
b/spec/rtems/message/if/broadcast.yml
index 0a2f77b3..61ba4106 100644
--- a/spec/rtems/message/if/broadcast.yml
+++ b/spec/rtems/message/if/broadcast.yml
@@ -44,6 +44,14 @@ notes: |
   The execution time of this directive is directly related to the
number of
   tasks waiting on the message queue, although it is more efficient
than the
   equivalent number of invocations of ${send:/name}.
+
+  ${../if/broadcast:/name} unblocks ${../glossary/receiver:/plural} in
a
+  non-atomic way. Meaning, it will not only
${../glossary/unblock:/term} those
+  ${../glossary/receiver:/plural} it finds waiting at the queue when
+  ${../if/broadcast:/name} is invoked but also any new
+  ${../glossary/receiver:/plural} which start waiting for messages
after
+  ${../if/broadcast:/name} is invoked and before it returns. This may
lead to
+  infinite unblocking loops.
 params:
 - description: |
 is the queue identifier.
-- 
2.30.2

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

[PATCH rtems-central 1/2] spec: Fix none-atomic -> non-atomic typo

2023-02-11 Thread Martin Erik Werner

---
 spec/rtems/message/req/broadcast.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/rtems/message/req/broadcast.yml
b/spec/rtems/message/req/broadcast.yml
index b0e1af12..4b2d0f41 100644
--- a/spec/rtems/message/req/broadcast.yml
+++ b/spec/rtems/message/req/broadcast.yml
@@ -88,7 +88,7 @@ post-conditions:
   waiting for a message at the ${/glossary/messagequeue:/term}.
 
   Note: Currently, ${../if/broadcast:/name} unblocks
-  ${../glossary/receiver:/plural} in a none-atomic way. Meaning,
+  ${../glossary/receiver:/plural} in a non-atomic way. Meaning,
   it will not only ${../glossary/unblock:/term} those
   ${../glossary/receiver:/plural} it finds waiting at the queue
   when ${../if/broadcast:/name} is invoked but also any new
-- 
2.30.2

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

[PATCH] score: Fix minor Rhe->The typo in doxygen

2023-01-22 Thread Martin Erik Werner

---
Intentionally not part of commit message:
Another minor typo in documentation, discovered by chance while browsing
the doxygen site.

 cpukit/include/rtems/score/coremsgimpl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/coremsgimpl.h 
b/cpukit/include/rtems/score/coremsgimpl.h
index 8ed5719e04..a11beef938 100644
--- a/cpukit/include/rtems/score/coremsgimpl.h
+++ b/cpukit/include/rtems/score/coremsgimpl.h
@@ -430,7 +430,7 @@ static inline Status_Control _CORE_message_queue_Urgent(
 /**
  * @brief Acquires the message queue.
  *
- * @param[in, out] the_message_queue Rhe message queue to acquire.
+ * @param[in, out] the_message_queue The message queue to acquire.
  * @param queue_context The thread queue context.
  */
 static inline void _CORE_message_queue_Acquire(
-- 
2.30.2

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

[PATCH rtems-docs] c-user/message/directives.rst: byes->bytes typo

2023-01-21 Thread Martin Erik Werner

---
 c-user/message/directives.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/message/directives.rst b/c-user/message/directives.rst
index 9cb88e2..a13e4c7 100644
--- a/c-user/message/directives.rst
+++ b/c-user/message/directives.rst
@@ -727,7 +727,7 @@ Broadcasts the messages to the tasks waiting at the queue.
 
 This directive causes all tasks that are waiting at the queue specified by
 ``id`` to be unblocked and sent the message contained in ``buffer``.  Before a
-task is unblocked, the message ``buffer`` of ``size`` byes in length is copied
+task is unblocked, the message ``buffer`` of ``size`` bytes in length is copied
 to that task's message buffer.  The number of tasks that were unblocked is
 returned in ``count``.
 
-- 
2.30.2

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

Re: [PATCH v2] tests/validation: Fix 64bit test failure

2021-02-15 Thread Martin Erik Werner

On Mon, 2021-02-15 at 09:19 -0600, Kinsey Moore wrote:
> From: Ryan Long 
> 
> The ts-validation-0 test currently fails on 64bit BSPs due to a
> limitation of the message structure. Changing the max message size to a
> size_t type and adjusting the expected value in the test resolves this.

This talks about the message size, but the change is to the pending
count?

> Closes #4179.

This seems to be the wrong bug reference, is #4197 the correct one?

If this change is correct there are a couple of casts left over now
which maybe should be adjusted as well?:

cpukit/score/src/coremsg.c:64:(size_t) maximum_pending_messages * 
buffer_size,
cpukit/score/src/coremsg.c:89:(size_t) maximum_pending_messages,

I'm however wondering if this is the right way to fix this...

I'm guessing that the failure mentioned is based on this specification
in rtems-central : spec/rtems/message/req/construct-errors.yml

393 - enabled-by: true
394   post-conditions:
395 Status: InvNum
396   pre-conditions:
397 Area: all
398 AreaSize: all
399 Id:
400 - Id
401 MaxPending:
402 - Big
403 MaxSize:
404 - Valid
405 Name:
406 - Valid
407 Queues:
408 - Avail

Which in practice seems to specify that 

rtems_message_queue_create
(
name,
UINT32_MAX /* count */,
1 /* size */,
attribute_set,

);

must fail with RTEMS_INVALID_NUMBER due to

117  - name: Big
118    test-code: |
119      ctx->config.maximum_pending_messages = UINT32_MAX;
120    text: |
121      The maximum number of pending messages of the message queue 
configuration
122      shall be big enough so that a calculation to get the message buffer
123      storage area size overflows.

which in the code looks like

/* Make sure the memory allocation size computation does not overflow */
if ( maximum_pending_messages > SIZE_MAX / buffer_size ) {  
  return STATUS_MESSAGE_QUEUE_INVALID_NUMBER;   
}   

But when the SIZE_MAX is a 64bit size_t, then UINT32_MAX * (1 + buffer
overhead) cannot reasonably overflow SIZE_MAX, so this will report
success instead of the expected invalid number which is the failure
seen in the validation test, is that correct?

If so, it seems very odd to change the interface just to allow this
failure to occur.

Would it be possible to instead specify that if

SIZE_MAX >= UINT32_MAX * (1 + buffer overhead)

then this case should be skipped, or expects success?

-- 
Martin Erik Werner
Software Developer | AAC Clyde Space
aac-clydespace.com/privacy-policy

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

RTEMS Documentation BSD licensing

2020-03-06 Thread Martin Erik Werner

Based on the dual-licensing work done as part of 
https://devel.rtems.org/ticket/3899 I was wondering what the licensing
state would be for the documentation going forward?

Previously, as far as I understand it, contributions were implicitly
licensed under BY-SA (CC-BY-SA-4.0 international) by the author and
RTEMS uses and redistributes the content with this license?

With this dual-licensing I understand that contributions will now be
implicitly licensed under both BSD (BSD-2-Clause) and BY-SA by the
author for contributions to some (or all?) parts.

Is there any documentation that will indicate this more specifically?
"If you contribute to this item, your agre to provide your
contributions under this(these) license(s)".

Will the documentation with inbound BSD/BY-SA contributions still be
outbound licensed under BY-SA in the "web" documentation? Or will this
documenation shift to being outbound BSD/BY-SA as well?

BSD is inbound compatible with BY-SA, right? If so I would guess that
providing contributions under BSD would be the same as providing them
under BSD and BY-SA (since one can simply take BSD and make it BY-SA)?

Assuming that BSD is inbound compatible with BY-SA, would it then make
sense to use only BSD as both inbound and outbound for the doxygen-
shared part of the "web" documentation?

If it remains outbound BY-SA-only there would be an assymetry, and for
example have the mild hitch that only the RTEMS project itself is
allowed to copy documentation to BSD-doxygen.

-- 
Martin Erik Werner 

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

RTEMS Documentation BSD (re)licensing statement for my contributions

2020-03-06 Thread Martin Erik Werner

(By request. Also added to https://devel.rtems.org/ticket/3899)

All previous contributions to the RTEMS documentation authored by me
(Martin Erik Werner) are, unless otherwise specified, licensed under
the terms of either

the Creative Commons Attribution Share Alike 4.0 International license
(https://spdx.org/licenses/CC-BY-SA-4.0)

or, at your option

the BSD 2-Clause "Simplified" License (
https://spdx.org/licenses/BSD-2-Clause).

-- 
Martin Erik Werner 

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

[PATCH] c-user: Remove spurious "is undefined. "

2020-02-28 Thread Martin Erik Werner

Remove a spurious "is undefined.  " fragment which was likely a leftover
from sentence re-use.
---
 c-user/self_contained_objects.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/c-user/self_contained_objects.rst 
b/c-user/self_contained_objects.rst
index 1c1e664..0be1423 100644
--- a/c-user/self_contained_objects.rst
+++ b/c-user/self_contained_objects.rst
@@ -159,8 +159,7 @@ They must be destroyed via
 
 * :c:func:`rtems_mutex_destroy`.
 
-is undefined.  Objects of the type :c:type:`rtems_recursive_mutex` must be
-initialized via
+Objects of the type :c:type:`rtems_recursive_mutex` must be initialized via
 
 * :c:func:`RTEMS_RECURSIVE_MUTEX_INITIALIZER`, or
 
-- 
2.20.1

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

[PATCH] c-user: Add & update ratemon get return values

2020-02-28 Thread Martin Erik Werner

Add a description of the previously missing RTEMS_NOT_DEFINED return
value for rtems_rate_monotonic_get_status().

Update the RTEMS_SUCCESSFUL return value descriptions for
rtems_rate_monotonic_get_status() and
rtems_rate_monotonic_get_statistics() which incorrectly used the same
description as rtems_rate_monotonic_period().
---
 c-user/rate_monotonic_manager.rst | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/c-user/rate_monotonic_manager.rst 
b/c-user/rate_monotonic_manager.rst
index 1cc55fe..6152005 100644
--- a/c-user/rate_monotonic_manager.rst
+++ b/c-user/rate_monotonic_manager.rst
@@ -871,11 +871,14 @@ DIRECTIVE STATUS CODES:
  :class: rtems-table
 
  * - ``RTEMS_SUCCESSFUL``
-   - period initiated successfully
+   - period status retrieved successfully
  * - ``RTEMS_INVALID_ID``
- invalid rate monotonic period id
  * - ``RTEMS_INVALID_ADDRESS``
- invalid address of status
+ * - ``RTEMS_NOT_DEFINED``
+   - no status is available due to the cpu usage of the task having been
+ reset since the period initiated
 
 *DESCRIPTION:
 This directive returns status information associated with the rate
@@ -938,7 +941,7 @@ DIRECTIVE STATUS CODES:
  :class: rtems-table
 
  * - ``RTEMS_SUCCESSFUL``
-   - period initiated successfully
+   - period statistics retrieved successfully
  * - ``RTEMS_INVALID_ID``
- invalid rate monotonic period id
  * - ``RTEMS_INVALID_ADDRESS``
-- 
2.20.1

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

[PATCH] Fix a minor "suspect" -> "subject" wording error

2020-02-22 Thread Martin Erik Werner

---
The word "suspect" here looked like a mistake and I have changed it
based on this assumption.

If it is not a mistake, what does "suspect" mean in this context?

 c-user/self_contained_objects.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/self_contained_objects.rst 
b/c-user/self_contained_objects.rst
index a581e0e..1c1e664 100644
--- a/c-user/self_contained_objects.rst
+++ b/c-user/self_contained_objects.rst
@@ -29,7 +29,7 @@ has some weaknesses:
 * The object identifier is only known at run-time.  This hinders compiler
   optimizations and static analysis.
 
-* The objects reside in a table, e.g. they are suspect to false sharing of
+* The objects reside in a table, e.g. they are subject to false sharing of
   cache lines :cite:`Drepper:2007:Memory`.
 
 * The object operations use a rich set of options and attributes.  For each
-- 
2.20.1

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

[PATCH] Use EAGAIN for POSIX mq wait in ISR error

2020-01-19 Thread Martin Erik Werner

Modify the status code returned by _CORE_message_queue_Submit() when it
detects a wait bout to happen in an ISR (which would be deadly) to
return a status which translated to EAGAIN instead of ENOMEM.

(This is only relevant for POSIX message queues, since classic message
queues cannot block on send.)

The motivation is to match the "most related" errno value returned from
mq_send() and mq_timedsend() according to POSIX, via opengroup

  [EAGAIN]
  The O_NONBLOCK flag is set in the message queue description
  associated with mqdes, and the specified message queue is full.

or via the RTEMS POSIX users documentation

  EAGAIN
The message queue is non-blocking, and there is no room on the queue
for another message as specified by the mq_maxmsg.

Neither of these matches the case ofi avoided ISR wait perfectly, but
they seem to be the closest equivalent, unless it is desirable to keep a
new non-standard error for this case. It is presumed that this is not
desirable.

The previously returned ENOMEM error value is not documented in either
the opengroup or the RTEMS POSIX uses documentation.

Based on the discussion in:
https://lists.rtems.org/pipermail/devel/2020-January/056891.html
Message-Id: 
---
 cpukit/include/rtems/score/status.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/status.h 
b/cpukit/include/rtems/score/status.h
index 34002559aa..fe1f0e87e6 100644
--- a/cpukit/include/rtems/score/status.h
+++ b/cpukit/include/rtems/score/status.h
@@ -90,7 +90,7 @@ typedef enum {
   STATUS_MESSAGE_INVALID_SIZE =
 STATUS_BUILD( STATUS_CLASSIC_INVALID_SIZE, EMSGSIZE ),
   STATUS_MESSAGE_QUEUE_WAIT_IN_ISR =
-STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, ENOMEM ),
+STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, EAGAIN ),
   STATUS_MESSAGE_QUEUE_WAS_DELETED =
 STATUS_BUILD( STATUS_CLASSIC_OBJECT_WAS_DELETED, EBADF ),
   STATUS_MINUS_ONE =
-- 
2.20.1

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

[PATCH] Remove invalid unsatisfied retval from msg submit

2020-01-18 Thread Martin Erik Werner

The return value RTEMS_UNSATISFIED cannot be returned by message queue
send/urgent in the classical API, so remove this from the documentation.

Based on the discussion in:
https://lists.rtems.org/pipermail/devel/2020-January/056891.html
Message-Id: 
---
 c-user/message_manager.rst | 4 
 1 file changed, 4 deletions(-)

diff --git a/c-user/message_manager.rst b/c-user/message_manager.rst
index 3132f2c..9fe1a1a 100644
--- a/c-user/message_manager.rst
+++ b/c-user/message_manager.rst
@@ -448,8 +448,6 @@ DIRECTIVE STATUS CODES:
- invalid message size
  * - ``RTEMS_INVALID_ADDRESS``
- ``buffer`` is NULL
- * - ``RTEMS_UNSATISFIED``
-   - out of message buffers
  * - ``RTEMS_TOO_MANY``
- queue's limit has been reached
 
@@ -506,8 +504,6 @@ DIRECTIVE STATUS CODES:
- invalid message size
  * - ``RTEMS_INVALID_ADDRESS``
- ``buffer`` is NULL
- * - ``RTEMS_UNSATISFIED``
-   - out of message buffers
  * - ``RTEMS_TOO_MANY``
- queue's limit has been reached
 
-- 
2.20.1

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

"too many" vs "unsatisfied" status from msg send

2020-01-16 Thread Martin Erik Werner

Hi,

In the documentation for rtems_message_queue_{send,urgent} there are
two limit-related statuses:

* - ``RTEMS_UNSATISFIED`` 
  - out of message buffers
* - ``RTEMS_TOO_MANY``
  - queue's limit has been reached

What is the difference between these?

Superficially I would guess that they both indicate that the queue
already has the maximum amount of messages pending?

>From a brief look at the code, my guess would be that RTEMS_UNSATISFIED
cannot be returned by this function?

While digging in the code, I also noticed that if
RTEMS_SCORE_COREMSG_ENABLE_BLOCKING_SEND is set, the
_CORE_message_queue_Submit() function can return
STATUS_MESSAGE_QUEUE_WAIT_IN_ISR which translates to
RTEMS_INTERNAL_ERROR, is this status deliberately omitted from the
documentation for rtems_message_queue_{send,urgent}?

-- 
Martin Erik Werner 

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

Re: [PATCH 1/2] barrier: Remove leftover semaphore remnants

2019-10-11 Thread Martin Erik Werner

On Wed, 2019-10-02 at 17:00 -0500, Joel Sherrill wrote:
> 
> 
> On Wed, Oct 2, 2019 at 2:52 PM Martin Erik Werner <
> martinerikwer...@gmail.com> wrote:
(...)
> > On Tue, 2019-10-01 at 18:02 -0500, Joel Sherrill wrote:
> > > 
> > > 
> > > On Tue, Oct 1, 2019, 5:07 PM Gedare Bloom 
> > wrote:
> > > > On Tue, Oct 1, 2019 at 3:53 PM Gedare Bloom 
> > > > wrote:
> > > > >
> > > > > On Wed, Sep 4, 2019 at 3:36 PM Martin Erik Werner
> > > > >  wrote:
> > > > > >
> > > > > > Remove various incorrect references to "lock" and "obtain"
> > and
> > > > to an
> > > > > > option set which is not part of the barrier interface.
> > > > > >
> > > > > > It looks like the barrier documentation was started based
> > on a
> > > > copy of
> > > > > > the semaphore documentation and these things are surviving
> > > > remnants.
> > > > > >
> > > > > > Also remove an unfinished sentence in the barrier wait
> > > > description,
> > > > > > since the intended information is already provided in the
> > under
> > > > the NOTE
> > > > > > label.
> > > > > Thanks for your contribution!  I have a few minor comments:
> > > > >
> > > > > > ---
> > > > > >  c-user/barrier_manager.rst | 38 +++---
> > 
> > > > 
> > > > > >  1 file changed, 7 insertions(+), 31 deletions(-)
> > > > > >
> > > > > > diff --git a/c-user/barrier_manager.rst b/c-
> > > > user/barrier_manager.rst
> > > > > > index b0bf3bf..e5d69b0 100644
> > > > > > --- a/c-user/barrier_manager.rst
> > > > > > +++ b/c-user/barrier_manager.rst
> > > > > > @@ -324,8 +324,7 @@ NOTES:
> > > > > >
> > > > > >  .. _rtems_barrier_wait:
> > > > > >
> > > > > > -.. index:: obtain a barrier
> > > > > > -.. index:: lock a barrier
> > > > > > +.. index:: wait at a barrier
> > > > > >  .. index:: rtems_barrier_wait
> > > > > >
> > > > > >  BARRIER_WAIT - Wait at a barrier
> > > > > > @@ -356,14 +355,11 @@ DIRECTIVE STATUS CODES:
> > > > > >
> > > > > >  DESCRIPTION:
> > > > > >
> > > > > > -This directive acquires the barrier specified by
> > ``id``. 
> > > > The
> > > > > > -``RTEMS_WAIT`` and ``RTEMS_NO_WAIT`` components of the
> > > > options parameter
> > > > > > -indicate whether the calling task wants to wait for
> > the
> > > > barrier to become
> > > > > > -available or return immediately if the barrier is not
> > > > currently available.
> > > > > > -With either ``RTEMS_WAIT`` or ``RTEMS_NO_WAIT``, if
> > the
> > > > current barrier
> > > > > > -count is positive, then it is decremented by one and
> > the
> > > > barrier is
> > > > > > -successfully acquired by returning immediately with a
> > > > successful return
> > > > > > -code.
> > > > > > +This directive waits at the barrier specified by
> > ``id``. 
> > > > The timeout
> > > > > > +parameter specifies the maximum interval the calling
> > task
> > > > is willing to be
> > > > > > +blocked waiting for the barrier.  If it is set to
> > > > ``RTEMS_NO_TIMEOUT``,
> > > > > > +then the calling task will wait forever.  If the
> > barrier
> > > > is available or
> > > > > 1. "will wait forever" -> "will wait forever if it doesn't
> > get
> > > > > released" or something more precise, even just "may wait
> > forever"
> > > 
> > > Will wait until the barrier is released/opened. Then add there is
> > no
> > > option for no wait as found in other APIs. 
> > 
> > Ok, so
> > "If it is set to ``RTEMS_NO_TIMEOUT``, then the calling task will
> > wait
> > until the barrier is released."
> > ?
> > 
> > The whole "If the barrier is available or the ``RTEMS_NO_WAIT``

Re: [PATCH 1/2] barrier: Remove leftover semaphore remnants

2019-10-02 Thread Martin Erik Werner

Thanks for the review! Discussion regarding suggested rewording and
cleanup are inline below.

One minor thing that I also noticed was in the background section there
is a "cticket" which looks like a typo in "Similarly, cticket holders
gather at the gates of arenas [...]". Unless it's some shorthand for
concert-tickets that I'm unaware of? Unless it's intended I'll add that
change to this patch set as well.

On Tue, 2019-10-01 at 18:02 -0500, Joel Sherrill wrote:
> 
> 
> On Tue, Oct 1, 2019, 5:07 PM Gedare Bloom  wrote:
> > On Tue, Oct 1, 2019 at 3:53 PM Gedare Bloom 
> > wrote:
> > >
> > > On Wed, Sep 4, 2019 at 3:36 PM Martin Erik Werner
> > >  wrote:
> > > >
> > > > Remove various incorrect references to "lock" and "obtain" and
> > to an
> > > > option set which is not part of the barrier interface.
> > > >
> > > > It looks like the barrier documentation was started based on a
> > copy of
> > > > the semaphore documentation and these things are surviving
> > remnants.
> > > >
> > > > Also remove an unfinished sentence in the barrier wait
> > description,
> > > > since the intended information is already provided in the under
> > the NOTE
> > > > label.
> > > Thanks for your contribution!  I have a few minor comments:
> > >
> > > > ---
> > > >  c-user/barrier_manager.rst | 38 +++---
> > 
> > > >  1 file changed, 7 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/c-user/barrier_manager.rst b/c-
> > user/barrier_manager.rst
> > > > index b0bf3bf..e5d69b0 100644
> > > > --- a/c-user/barrier_manager.rst
> > > > +++ b/c-user/barrier_manager.rst
> > > > @@ -324,8 +324,7 @@ NOTES:
> > > >
> > > >  .. _rtems_barrier_wait:
> > > >
> > > > -.. index:: obtain a barrier
> > > > -.. index:: lock a barrier
> > > > +.. index:: wait at a barrier
> > > >  .. index:: rtems_barrier_wait
> > > >
> > > >  BARRIER_WAIT - Wait at a barrier
> > > > @@ -356,14 +355,11 @@ DIRECTIVE STATUS CODES:
> > > >
> > > >  DESCRIPTION:
> > > >
> > > > -This directive acquires the barrier specified by ``id``. 
> > The
> > > > -``RTEMS_WAIT`` and ``RTEMS_NO_WAIT`` components of the
> > options parameter
> > > > -indicate whether the calling task wants to wait for the
> > barrier to become
> > > > -available or return immediately if the barrier is not
> > currently available.
> > > > -With either ``RTEMS_WAIT`` or ``RTEMS_NO_WAIT``, if the
> > current barrier
> > > > -count is positive, then it is decremented by one and the
> > barrier is
> > > > -successfully acquired by returning immediately with a
> > successful return
> > > > -code.
> > > > +This directive waits at the barrier specified by ``id``. 
> > The timeout
> > > > +parameter specifies the maximum interval the calling task
> > is willing to be
> > > > +blocked waiting for the barrier.  If it is set to
> > ``RTEMS_NO_TIMEOUT``,
> > > > +then the calling task will wait forever.  If the barrier
> > is available or
> > > 1. "will wait forever" -> "will wait forever if it doesn't get
> > > released" or something more precise, even just "may wait forever"
> 
> Will wait until the barrier is released/opened. Then add there is no
> option for no wait as found in other APIs. 

Ok, so
"If it is set to ``RTEMS_NO_TIMEOUT``, then the calling task will wait
until the barrier is released."
?

The whole "If the barrier is available or the ``RTEMS_NO_WAIT`` option
component is set, then the timeout is ignored." wording is another
semaphore leftover that I missed when moving things around.

I'm thinking I'll remove that whole sentence. replacing it with one of
the following alternatives (or a mix thereof):

It is not possible to make the calling task return based on the timeout
without wating for at least one clock tick.

There is no equivalent to the ``RTEMS_NO_WAIT`` option for this directive,
hence the minimum timeout possible is one clock tick.
   
It is not possible to make the calling task return immediately based on the
timeout, the minimum timeout is 1 clock tick.
   
The minimum timeout interval is one clock tick and it is therefore not
p

[Resend] [PATCH 0/2] rtems-doc barrier fixes

2019-10-01 Thread Martin Erik Werner

Hi,

I'm re-sending this patch set since I received no reply previously (2019-09-04).

Martin Erik Werner (2):
  barrier: Remove leftover semaphore remnants
  barrier: Remove unfinished sentence

 c-user/barrier_manager.rst | 45 ++---
 1 file changed, 10 insertions(+), 35 deletions(-)

-- 
2.11.0

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

[PATCH 2/2] barrier: Remove unfinished sentence

2019-10-01 Thread Martin Erik Werner

Remove the unfinished sentence
"Since a barrier is, by definition, never immediately [...]"
and jump directly to
"The task may wait [forever or for a timeout]"
instead.

I cannot figure out what the unfinished sentence is supposed to be -
"released"? "passed"?
---
 c-user/barrier_manager.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst
index e5d69b0..9a57645 100644
--- a/c-user/barrier_manager.rst
+++ b/c-user/barrier_manager.rst
@@ -119,10 +119,9 @@ Waiting at a Barrier
 
 
 The ``rtems_barrier_wait`` directive is used to wait at
-the specified barrier.  Since a barrier is, by definition, never immediately,
-the task may wait forever for the barrier to be released or it may
-specify a timeout.  Specifying a timeout limits the interval the task will
-wait before returning with an error status code.
+the specified barrier.  The task may wait forever for the barrier to be
+released or it may specify a timeout.  Specifying a timeout limits the interval
+the task will wait before returning with an error status code.
 
 If the barrier is configured as automatic and there are already one less then
 the maximum number of waiters, then the call will unblock all tasks waiting at
-- 
2.11.0

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

[PATCH 1/2] barrier: Remove leftover semaphore remnants

2019-10-01 Thread Martin Erik Werner

Remove various incorrect references to "lock" and "obtain" and to an
option set which is not part of the barrier interface.

It looks like the barrier documentation was started based on a copy of
the semaphore documentation and these things are surviving remnants.

Also remove an unfinished sentence in the barrier wait description,
since the intended information is already provided in the under the NOTE
label.
---
 c-user/barrier_manager.rst | 38 +++---
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst
index b0bf3bf..e5d69b0 100644
--- a/c-user/barrier_manager.rst
+++ b/c-user/barrier_manager.rst
@@ -324,8 +324,7 @@ NOTES:
 
 .. _rtems_barrier_wait:
 
-.. index:: obtain a barrier
-.. index:: lock a barrier
+.. index:: wait at a barrier
 .. index:: rtems_barrier_wait
 
 BARRIER_WAIT - Wait at a barrier
@@ -356,14 +355,11 @@ DIRECTIVE STATUS CODES:
 
 DESCRIPTION:
 
-This directive acquires the barrier specified by ``id``.  The
-``RTEMS_WAIT`` and ``RTEMS_NO_WAIT`` components of the options parameter
-indicate whether the calling task wants to wait for the barrier to become
-available or return immediately if the barrier is not currently available.
-With either ``RTEMS_WAIT`` or ``RTEMS_NO_WAIT``, if the current barrier
-count is positive, then it is decremented by one and the barrier is
-successfully acquired by returning immediately with a successful return
-code.
+This directive waits at the barrier specified by ``id``.  The timeout
+parameter specifies the maximum interval the calling task is willing to be
+blocked waiting for the barrier.  If it is set to ``RTEMS_NO_TIMEOUT``,
+then the calling task will wait forever.  If the barrier is available or
+the ``RTEMS_NO_WAIT`` option component is set, then timeout is ignored.
 
 Conceptually, the calling task should always be thought of as blocking when
 it makes this call and being unblocked when the barrier is released.  If
@@ -372,24 +368,7 @@ DESCRIPTION:
 callers will block except for the one which is the Nth task which trips the
 automatic release condition.
 
-The timeout parameter specifies the maximum interval the calling task is
-willing to be blocked waiting for the barrier.  If it is set to
-``RTEMS_NO_TIMEOUT``, then the calling task will wait forever.  If the
-barrier is available or the ``RTEMS_NO_WAIT`` option component is set, then
-timeout is ignored.
-
 NOTES:
-
-The following barrier acquisition option constants are defined by RTEMS:
-
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_WAIT``
-   - task will wait for barrier (default)
- * - ``RTEMS_NO_WAIT``
-   - task should not wait
-
 A clock tick is required to support the timeout functionality of this
 directive.
 
@@ -399,7 +378,6 @@ NOTES:
 
 .. _rtems_barrier_release:
 
-.. index:: wait at a barrier
 .. index:: release a barrier
 .. index:: rtems_barrier_release
 
@@ -425,9 +403,7 @@ DIRECTIVE STATUS CODES:
 
 DESCRIPTION:
 This directive releases the barrier specified by id.  All tasks waiting at
-the barrier will be unblocked.  If the running task's preemption mode is
-enabled and one of the unblocked tasks has a higher priority than the
-running task.
+the barrier will be unblocked.
 
 NOTES:
 The calling task may be preempted if it causes a higher priority task to be
-- 
2.11.0

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

[PATCH 2/2] barrier: Remove unfinished sentence

2019-09-04 Thread Martin Erik Werner

Remove the unfinished sentence
"Since a barrier is, by definition, never immediately [...]"
and jump directly to
"The task may wait [forever or for a timeout]"
instead.

I cannot figure out what the unfinished sentence is supposed to be -
"released"? "passed"?
---
 c-user/barrier_manager.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst
index e5d69b0..9a57645 100644
--- a/c-user/barrier_manager.rst
+++ b/c-user/barrier_manager.rst
@@ -119,10 +119,9 @@ Waiting at a Barrier
 
 
 The ``rtems_barrier_wait`` directive is used to wait at
-the specified barrier.  Since a barrier is, by definition, never immediately,
-the task may wait forever for the barrier to be released or it may
-specify a timeout.  Specifying a timeout limits the interval the task will
-wait before returning with an error status code.
+the specified barrier.  The task may wait forever for the barrier to be
+released or it may specify a timeout.  Specifying a timeout limits the interval
+the task will wait before returning with an error status code.
 
 If the barrier is configured as automatic and there are already one less then
 the maximum number of waiters, then the call will unblock all tasks waiting at
-- 
2.11.0

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

[PATCH 1/2] barrier: Remove leftover semaphore remnants

2019-09-04 Thread Martin Erik Werner

Remove various incorrect references to "lock" and "obtain" and to an
option set which is not part of the barrier interface.

It looks like the barrier documentation was started based on a copy of
the semaphore documentation and these things are surviving remnants.

Also remove an unfinished sentence in the barrier wait description,
since the intended information is already provided in the under the NOTE
label.
---
 c-user/barrier_manager.rst | 38 +++---
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/c-user/barrier_manager.rst b/c-user/barrier_manager.rst
index b0bf3bf..e5d69b0 100644
--- a/c-user/barrier_manager.rst
+++ b/c-user/barrier_manager.rst
@@ -324,8 +324,7 @@ NOTES:
 
 .. _rtems_barrier_wait:
 
-.. index:: obtain a barrier
-.. index:: lock a barrier
+.. index:: wait at a barrier
 .. index:: rtems_barrier_wait
 
 BARRIER_WAIT - Wait at a barrier
@@ -356,14 +355,11 @@ DIRECTIVE STATUS CODES:
 
 DESCRIPTION:
 
-This directive acquires the barrier specified by ``id``.  The
-``RTEMS_WAIT`` and ``RTEMS_NO_WAIT`` components of the options parameter
-indicate whether the calling task wants to wait for the barrier to become
-available or return immediately if the barrier is not currently available.
-With either ``RTEMS_WAIT`` or ``RTEMS_NO_WAIT``, if the current barrier
-count is positive, then it is decremented by one and the barrier is
-successfully acquired by returning immediately with a successful return
-code.
+This directive waits at the barrier specified by ``id``.  The timeout
+parameter specifies the maximum interval the calling task is willing to be
+blocked waiting for the barrier.  If it is set to ``RTEMS_NO_TIMEOUT``,
+then the calling task will wait forever.  If the barrier is available or
+the ``RTEMS_NO_WAIT`` option component is set, then timeout is ignored.
 
 Conceptually, the calling task should always be thought of as blocking when
 it makes this call and being unblocked when the barrier is released.  If
@@ -372,24 +368,7 @@ DESCRIPTION:
 callers will block except for the one which is the Nth task which trips the
 automatic release condition.
 
-The timeout parameter specifies the maximum interval the calling task is
-willing to be blocked waiting for the barrier.  If it is set to
-``RTEMS_NO_TIMEOUT``, then the calling task will wait forever.  If the
-barrier is available or the ``RTEMS_NO_WAIT`` option component is set, then
-timeout is ignored.
-
 NOTES:
-
-The following barrier acquisition option constants are defined by RTEMS:
-
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_WAIT``
-   - task will wait for barrier (default)
- * - ``RTEMS_NO_WAIT``
-   - task should not wait
-
 A clock tick is required to support the timeout functionality of this
 directive.
 
@@ -399,7 +378,6 @@ NOTES:
 
 .. _rtems_barrier_release:
 
-.. index:: wait at a barrier
 .. index:: release a barrier
 .. index:: rtems_barrier_release
 
@@ -425,9 +403,7 @@ DIRECTIVE STATUS CODES:
 
 DESCRIPTION:
 This directive releases the barrier specified by id.  All tasks waiting at
-the barrier will be unblocked.  If the running task's preemption mode is
-enabled and one of the unblocked tasks has a higher priority than the
-running task.
+the barrier will be unblocked.
 
 NOTES:
 The calling task may be preempted if it causes a higher priority task to be
-- 
2.11.0

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

Re: [PATCH] Address several issues from compiling examples

2019-09-02 Thread Martin Erik Werner

On Tue, 2019-09-03 at 01:48 +0200, Martin Erik Werner wrote:
> Compiling the code from examples "code-block:: c" along with public
> includes and a bsp exposed a few issues amongst a lot of false
> positives. Address some of these:
(...)

As per the sent patch, I've had some "fun" trying to run through code
examples in the documentation and looking at compile warnings.

Amongst the large amount of false positives there were quite a few more
or less significant fixes that came out of it, hopefully.

I used a *very rough* bash+awk script to do filtering and compilation,
I've attached it below if anyone dares to look.

I wonder if it might be interesting to mark a select few (or even
majority?) of the documentation examples as explicitly compilable in
isolation and adding the required include statements to them? It might
make compile-validation significantly easier in the future...

As a side effect of this I've also noticed some things which I'm really
unsure about:

The filesystem section seems very out of date, especially the
filesystem implementation part, where it seems to match the current
rtems state very poorly, I've skipped doing any updates in this section
since there seemed like major changes in both text and examples would
be needed.

With reference to ticket #3254, commit 3f575da2f2 - "Remove obsolete
network header files" removed cpukit/libnetworking/include/net/if.h.
This removed, amongst other things, the definitions for "struct ifreq"
and "struct ifaliasreq". These two are referenced and used both in
rtems-docs and in current code in rtems.

I'm wondering if I'm missing something here? Are they provided through
some other means? Are these supposed to be completely removed and all
use of them removed eventually? Do they need to be re-added for the
current code to work as it should?

-- 
Martin Erik Werner 

compile-examples
Description: Perl program
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Address several issues from compiling examples

2019-09-02 Thread Martin Erik Werner

Compiling the code from examples "code-block:: c" along with public
includes and a bsp exposed a few issues amongst a lot of false
positives. Address some of these:

* Terminate struct declarations with ';'. Mainly for pedantic
  correctness.

* Show ptrdiff_t instead of size_t for the sbrk() prototype, matching
  the current argument type in rtems.

* Replace some occurrences of unsigned16 with uint16_t.

* Fix odd type declaration, "uint8_t char*" -> "char*".

* Use appropriate helper to get chain head instead of invalid access to
  nonexistent struct member.

* Remove several excess '\' escapes.

* Use RTEMS_SELF instead of undefined SELF.

* Use rtems_task instead of void for task functions.

* Add missing stack size parameter in task creation.

* Use rtems_interrupt_level instead of undefined rtems_interrupt.

* Correct return value format for rtems_object_id_get_api()
  rtems_object_id_get_index() (enum and uint16_t) and also fix
  corresponding print formatting.

* Correct return value documentation for rtems_object_id_get_class(),
  rtems_object_id_get_node() and rtems_object_id_get_index()
  int -> uint32_t.

* Use RTEMS_SUCCESSFUL instead of undefined RTEMS_STATUS_SUCCESSFUL and
  fix return value variable name in rate monotonic examples.

* Use RTEMS_TIMEOUT instead of undefined TIMEOUT and RTEMS_PERIOD_STATUS
  instead of undefined STATUS.

* Add missing fields to ftpd configuration.

* Correct parameter types in ftpd hook prototype,
  unsigned char * -> void *.

* Fix various code-block:: attributes, c -> makefile and c -> shell.

* Add missing parenthesis in socket buffer memory calculation example.

* Remove typedef in declaration of mq_attr since it is defiend without
  typedef in reality.

* Update siginfo_t declaration to match current reality.

* Update shell user command definition example to include mode, uid and
  gid.
---
 bsp-howto/console.rst |  2 +-
 bsp-howto/miscellanous_support.rst|  2 +-
 bsp-howto/real_time_clock.rst |  4 ++--
 c-user/chains.rst |  4 ++--
 c-user/configuring_a_system.rst   |  2 +-
 c-user/constant_bandwidth_server.rst  |  6 +++---
 c-user/fatal_error.rst|  7 ---
 c-user/interrupt_manager.rst  |  8 
 c-user/key_concepts.rst   |  4 ++--
 c-user/object_services.rst| 19 ++-
 c-user/rate_monotonic_manager.rst | 19 +--
 c-user/task_manager.rst   |  2 +-
 networking/network_servers.rst| 10 --
 networking/networking_driver.rst  |  4 ++--
 networking/using_networking_rtems_app.rst |  6 +++---
 posix-users/message_passing.rst   |  2 +-
 posix-users/signal.rst| 16 
 shell/configuration_and_init.rst  | 15 +--
 shell/file_and_directory.rst  |  6 +++---
 shell/general_commands.rst|  2 +-
 20 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index 83b10b4..aef13a8 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -168,7 +168,7 @@ The handler table for the polled mode should look like the 
following.
   .set_attributes = my_driver_set_attributes,
   .ioctl = my_driver_ioctl, /* optional, may be NULL */
   .mode = TERMIOS_POLLED
-}
+};
 
 The :c:func:`my_driver_poll_write()` routine is responsible for writing ``n``
 characters from ``buf`` to the serial device specified by ``base``.
diff --git a/bsp-howto/miscellanous_support.rst 
b/bsp-howto/miscellanous_support.rst
index cea744d..77b7194 100644
--- a/bsp-howto/miscellanous_support.rst
+++ b/bsp-howto/miscellanous_support.rst
@@ -138,7 +138,7 @@ prototype for this routine:
 
 .. code-block:: c
 
-void * sbrk(size_t increment)
+void * sbrk(ptrdiff_t increment)
 
 The ``increment`` amount is based upon the ``sbrk_amount`` parameter passed to
 the ``bsp_libc_init`` during system initialization.
diff --git a/bsp-howto/real_time_clock.rst b/bsp-howto/real_time_clock.rst
index ee40a6c..62ec09e 100644
--- a/bsp-howto/real_time_clock.rst
+++ b/bsp-howto/real_time_clock.rst
@@ -67,8 +67,8 @@ table is below:
 
 bool dmv177_icm7170_probe(int minor)
 {
-  volatile unsigned16 *card_resource_reg;
-  card_resource_reg = (volatile unsigned16 *) DMV170_CARD_RESORCE_REG;
+  volatile uint16_t *card_resource_reg;
+  card_resource_reg = (volatile uint16_t *) DMV170_CARD_RESORCE_REG;
   if ( (*card_resource_reg & DMV170_RTC_INST_MASK) == DMV170_RTC_INSTALLED 
)
 return TRUE;
   return FALSE;
diff --git a/c-user/chains.rst b/c-user/chains.rst
index c47d318..0dce1d9 100644
--- a/c-user/chains.rst
+++ b/c-user/chains.rst
@@ -149,7 +149,7 @@ to the control. Consider a user structure and chain control:
 typedef struct foo
 {
 rtems_chain_node node;
-uint8_t char*

Re: [PATCH 2/6] or1k/shared/cache/cache.c: Remove unused methods

2018-10-09 Thread Martin Erik Werner

On Mon, 2018-10-08 at 17:33 -0500, Joel Sherrill wrote:
> 
> 
> On Mon, Oct 8, 2018 at 9:37 AM Martin Erik Werner 
>  wrote:
> > On Mon, 2018-10-08 at 15:28 +0200, Sebastian Huber wrote:
> > > Are the intentionally unused or is there some bug and the generic cache 
> > > manager doesn't use them accidentally?
> > 
> > I think that when I added the range support to the or1k cache helpers I
> > left the 1-line functions there since I was unaware that they would be
> > completely non-visible to upper layers (right?). As far as I can tell
> > they can be removed.
> 
> I'm not pushing this change unless you are happy with it.  
> 
> So I am waiting for a clear yes/no. I was just fixing an obvious warning.

Yes, do push it.

-- 
Martin Erik Werner 
ÅAC Microtec AB | Clyde Space Ltd.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/6] or1k/shared/cache/cache.c: Remove unused methods

2018-10-08 Thread Martin Erik Werner

On Mon, 2018-10-08 at 15:28 +0200, Sebastian Huber wrote:
> Are the intentionally unused or is there some bug and the generic cache 
> manager doesn't use them accidentally?

I think that when I added the range support to the or1k cache helpers I
left the 1-line functions there since I was unaware that they would be
completely non-visible to upper layers (right?). As far as I can tell
they can be removed.

Whilst looking, I saw that something like this is also present in
bsps/arm/shared/cache/cache-cp15.c, but
CPU_CACHE_SUPPORT_PROVIDES_RANGE_FUNCTIONS is set via indirection
there, so it might be a special case?

-- 
Martin Erik Werner 
ÅAC Microtec AB | Clyde Space Ltd.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Future of or1k RTEMS support?

2018-08-24 Thread Martin Erik Werner

Hi,

Regarding or1k, we (ÅAC Microtec/Clyde Space) are currently using it,
together with RTEMS, in some of our products[0], and are thus quite
interested in its continued life as a part of RTEMS, at least in the
foreseeable future (i.e. RTEMS 5).

With regards to the upstreaming of GCC, there are still ongoing work on
this for or1k at https://github.com/stffrdhrn/gcc .

[0]
http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriusobc/
http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriustcm/

-- 
Martin Erik Werner 
ÅAC Microtec AB | Clyde Space Ltd.

On Thu, 2018-07-26 at 10:01 +0100, Hesham Almatary wrote:
> Hi Sebastian,
> 
> Yes, I agree with you. Furthermore, most of the or1k hardware and software 
> folks are moving to riscv now.
> 
> Should we make it obsolete?
> 
> Cheers,
> Hesham
> 
> On Thu, 26 Jul 2018 at 7:10 am, Sebastian Huber 
>  wrote:
> > Hello,
> > 
> > the or1k ecosystem has a major problem with their non-FSF GCC from my 
> > point of view which is maintained here:
> > 
> > https://github.com/openrisc/or1k-gcc
> > 
> > The last commit was in 2016.  It looks like a dead project to me.
> > 
> > Given the momentum RISC-V has currently why would someone still want to 
> > use or1k? All RISC-V tools are upstream and well maintained. It is the 
> > target with the most helpful and responsive maintainers that I worked 
> > with so far.
> > 
> > ___
> > 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 0/1] posixtimer01 test questions and patch

2018-05-28 Thread Martin Erik Werner

Hi,

(Re-ping regarding previous mail.)

Does anyone have an idea regarding if the psxtimer01 test can be
expected to report a time difference as described below, or if this is
something that is not expected and should be treated as a valid test
failure?

(Please also see related patch.)

-- 
Martin Erik Werner <martinerikwerner@gmail.com>
ÅAC Microtec AB | Clyde Space Ltd.

On Tue, 2018-05-15 at 11:21 +0200, Martin Erik Werner wrote:
> When running the testsuites/psxtests/psxtimer01/ tests on our or1k
> board, I've noticed a common 10ms (one clock tick) time difference when
> measuring the re-armed time value in task A and C, which causes the
> posixtimer01 test to report failure:
> 
> (...)
> if (sigwait(,_sig) == -1) {
>   perror ("Error in sigwait\n");
> }
> if (timer_gettime(timer_id, ) == -1) {
>   perror ("Error in timer_gettime\n");
>   rtems_test_exit(0);
> }
> if (! _Timespec_Equal_to( _value, _period )){
>   perror ("Error in Task A timer_gettime\n");
> }
> (...)
> 
> Given that this time value check is disabled in task B:
> 
> #if 0
>  /*
>   *  It is not an error if they are not equal.  A clock tick could occur
>   *  and thus they are close but not equal.  Can we test for this?
>   */
>  if ( !_Timespec_Equal_to( _value, _period) ){
>printf( "NOT EQUAL %d:%d != %d:%d\n",
>   timerdata.it_value.tv_sec,
>   timerdata.it_value.tv_nsec,
>   my_period.tv_sec,
>   my_period.tv_nsec
>);
>rtems_test_exit(0);
>  }
> #endif
> 
> does this check still belong as a certain failure in task A and C?
> 
> I've made a modification to the failure printout in order to avoid using unset
> errno, and to provide information about the time difference, which might be
> interesting, if these checks are still valid as certain failures:
> 
> Martin Erik Werner (1):
>   Fix and extend error message in posix timer test
> 
>  testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/1] posixtimer01 test questions and patch

2018-05-15 Thread Martin Erik Werner

When running the testsuites/psxtests/psxtimer01/ tests on our or1k
board, I've noticed a common 10ms (one clock tick) time difference when
measuring the re-armed time value in task A and C, which causes the
posixtimer01 test to report failure:

(...)
if (sigwait(,_sig) == -1) {
  perror ("Error in sigwait\n");
}
if (timer_gettime(timer_id, ) == -1) {
  perror ("Error in timer_gettime\n");
  rtems_test_exit(0);
}
if (! _Timespec_Equal_to( _value, _period )){
  perror ("Error in Task A timer_gettime\n");
}
(...)

Given that this time value check is disabled in task B:

#if 0
 /*
  *  It is not an error if they are not equal.  A clock tick could occur
  *  and thus they are close but not equal.  Can we test for this?
  */
 if ( !_Timespec_Equal_to( _value, _period) ){
   printf( "NOT EQUAL %d:%d != %d:%d\n",
  timerdata.it_value.tv_sec,
  timerdata.it_value.tv_nsec,
  my_period.tv_sec,
  my_period.tv_nsec
   );
   rtems_test_exit(0);
 }
#endif

does this check still belong as a certain failure in task A and C?

I've made a modification to the failure printout in order to avoid using unset
errno, and to provide information about the time difference, which might be
interesting, if these checks are still valid as certain failures:

Martin Erik Werner (1):
  Fix and extend error message in posix timer test

 testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

-- 
2.11.0

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

[PATCH 1/1] Fix and extend error message in posix timer test

2018-05-15 Thread Martin Erik Werner

_Timespec_Equal_to() does not set errno, hence avoid using perror(),
instead use fprintf() to stderr, and extend the error message to provide
information about what the error is (measured timer value after
re-arming is not equal to the configured interval), and how large of a
difference was measured.

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/testsuites/psxtests/psxtimer01/psxtimer.c 
b/testsuites/psxtests/psxtimer01/psxtimer.c
index 032e9f8e6c..6ec049ac54 100644
--- a/testsuites/psxtests/psxtimer01/psxtimer.c
+++ b/testsuites/psxtests/psxtimer01/psxtimer.c
@@ -143,7 +143,12 @@ void * task_a (void *arg)
rtems_test_exit(0);
  }
  if (! _Timespec_Equal_to( _value, _period )){
-   perror ("Error in Task A timer_gettime\n");
+   fprintf(
+   stderr, "Error in Task A timer_gettime:\n"
+   "  re-armed timer: %" PRIdtime_t ":%ld does not match interval: %" 
PRIdtime_t ":%ld\n",
+   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
+   my_period.tv_sec, my_period.tv_nsec
+  );
  }
  clock = time(NULL);
  printf("Executing task A with count = %2i %s", params->count, 
ctime());
@@ -291,7 +296,12 @@ void * task_c (void *arg)
rtems_test_exit(0);
  }
  if (! _Timespec_Equal_to( _value, _period) ){
-   perror ("Error in Task C timer_gettime\n");
+   fprintf(
+   stderr, "Error in Task A timer_gettime:\n"
+   "  re-armed timer: %" PRIdtime_t ":%ld does not match interval: %" 
PRIdtime_t ":%ld\n",
+   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
+   my_period.tv_sec, my_period.tv_nsec
+   );
  }
  pthread_mutex_lock ();
  while (data.updated == FALSE) {
-- 
2.11.0

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

[PATCH] rtems/inttypes: Clarify hexadecimal in comments

2017-11-29 Thread Martin Erik Werner

Update comments to reflect that PRIxblksize_t PRIxblkcnt_t is
hexadecimal, not decimal.

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 cpukit/include/rtems/inttypes.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/inttypes.h b/cpukit/include/rtems/inttypes.h
index cc8538df19..a8e725dcbf 100644
--- a/cpukit/include/rtems/inttypes.h
+++ b/cpukit/include/rtems/inttypes.h
@@ -70,7 +70,7 @@ extern "C" {
 #error "PRIdtime_t: unsupported size of time_t"
 #endif
 
-/** Helper macro to print "blksize_t" in decimal */
+/** Helper macro to print "blksize_t" in hexadecimal */
 #if __RTEMS_SIZEOF_BLKSIZE_T__ == 8
 #define PRIxblksize_t PRIx64
 #elif __RTEMS_SIZEOF_BLKSIZE_T__ == 4
@@ -81,7 +81,7 @@ extern "C" {
 #define PRIxblksize_t "lx"
 #endif
 
-/** Helper macro to print "blkcnt_t" in decimal */
+/** Helper macro to print "blkcnt_t" in hexadecimal */
 #if __RTEMS_SIZEOF_BLKCNT_T__ == 8
 #define PRIxblkcnt_t PRIx64
 #elif __RTEMS_SIZEOF_BLKCNT_T__ == 4
-- 
2.11.0

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

[PATCH] Fix comments for object lookup err. -> status map

2017-11-20 Thread Martin Erik Werner

Based on correlation with the enum for object lookup errors in
cpukit/score/include/rtems/score/objectimpl.h:

typedef enum {
 OBJECTS_NAME_OR_ID_LOOKUP_SUCCESSFUL,
 OBJECTS_INVALID_NAME,
 OBJECTS_INVALID_ADDRESS,
 OBJECTS_INVALID_ID,
 OBJECTS_INVALID_NODE
} Objects_Name_or_id_lookup_errors;

update the comments regarding the object lookup error to status map to
match.

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 cpukit/rtems/src/status.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cpukit/rtems/src/status.c b/cpukit/rtems/src/status.c
index 810c0e18de..3eadea59f0 100644
--- a/cpukit/rtems/src/status.c
+++ b/cpukit/rtems/src/status.c
@@ -17,13 +17,13 @@
 #include 
 
 const rtems_status_code _Status_Object_name_errors_to_status[] = {
-  /** This maps OBJECTS_SUCCESSFUL to RTEMS_SUCCESSFUL. */
+  /** This maps OBJECTS_NAME_OR_ID_LOOKUP_SUCCESSFUL to RTEMS_SUCCESSFUL. */
   RTEMS_SUCCESSFUL,
   /** This maps OBJECTS_INVALID_NAME to RTEMS_INVALID_NAME. */
   RTEMS_INVALID_NAME,
-  /** This maps OBJECTS_INVALID_ADDRESS to RTEMS_INVALID_NAME. */
+  /** This maps OBJECTS_INVALID_ADDRESS to RTEMS_INVALID_ADDRESS. */
   RTEMS_INVALID_ADDRESS,
-  /** This maps OBJECTS_INVALID_ID to RTEMS_INVALID_ADDRESS. */
+  /** This maps OBJECTS_INVALID_ID to RTEMS_INVALID_ID. */
   RTEMS_INVALID_ID,
   /** This maps OBJECTS_INVALID_NODE to RTEMS_INVALID_NODE. */
   RTEMS_INVALID_NODE
-- 
2.11.0

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

[PATCH] bsp-howto/console: Move misplaced var. in example

2017-11-15 Thread Martin Erik Werner

Signed-off-by: Martin Erik Werner <martinerikwer...@gmail.com>
---
 bsp-howto/console.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp-howto/console.rst b/bsp-howto/console.rst
index 2bdb3c8..f8ff7ce 100644
--- a/bsp-howto/console.rst
+++ b/bsp-howto/console.rst
@@ -184,6 +184,7 @@ characters from ``buf`` to the serial device specified by 
``base``.
 )
 {
   my_driver_context *ctx;
+  size_ti;
 
   ctx = (my_driver_context *) base;
 
@@ -201,7 +202,6 @@ available, then the routine should immediately return minus 
one.
 static int my_driver_poll_read( rtems_termios_device_context *base )
 {
   my_driver_context *ctx;
-  size_t i;
 
   ctx = (my_driver_context *) base;
 
-- 
2.11.0

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

[PATCH] Fix bashism in vc-key.sh

2017-11-12 Thread Martin Erik Werner

Change "==" to "=", since "==" for comparison is not available in POSIX
sh.

Signed-off-by: Martin Erik Werner <martinerikwer...@gmail.com>
---
 cpukit/sapi/vc-key.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/sapi/vc-key.sh b/cpukit/sapi/vc-key.sh
index c628a1e26d..3c8f446d3f 100755
--- a/cpukit/sapi/vc-key.sh
+++ b/cpukit/sapi/vc-key.sh
@@ -15,7 +15,7 @@ if test $# -ge 1; then
   cd $repo
   if test -n ${git}; then
git rev-parse --git-dir > /dev/null 2>&1
-   if test $? == 0; then
+   if test $? = 0; then
 git status > /dev/null 2>&1
 if git diff-index --quiet HEAD --; then
  modified=""
@@ -24,7 +24,7 @@ if test $# -ge 1; then
 fi
 vc_ident="$(git rev-parse --verify HEAD)${modified}"
 if test $# -ge 1; then
- if test "${vc_ident}" == "$1"; then
+ if test "${vc_ident}" = "$1"; then
   vc_ident="matches"
  fi
 fi
-- 
2.11.0

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

[PATCH 3/3] rtems: Provide nonzero argc required by gtest init

2017-09-30 Thread Martin Erik Werner

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 rtems/gtest-main.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/rtems/gtest-main.h b/rtems/gtest-main.h
index 81ec91e..797d12e 100644
--- a/rtems/gtest-main.h
+++ b/rtems/gtest-main.h
@@ -39,8 +39,9 @@
 extern "C" {
   void *POSIX_Init(void *)
   {
-int argc = 0;
-char **argv = NULL;
+/* gtest requires nonzero arg count */
+int argc = 1;
+char *argv[] = { "dummy" };
 testing::InitGoogleTest(, argv);
 
 int exit_status = RUN_ALL_TESTS();
-- 
2.11.0

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

[PATCH 2/3] rtems: Make prefix configurable

2017-09-30 Thread Martin Erik Werner

If the toolchain has been relocated, the configured-with-prefix will not
match the desired install path. Hence enable setting prefix manually in
the install-target.sh script.

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 rtems/install-target.sh | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/rtems/install-target.sh b/rtems/install-target.sh
index f6d89f6..df2e5d1 100755
--- a/rtems/install-target.sh
+++ b/rtems/install-target.sh
@@ -3,9 +3,26 @@
 target="$1"
 
 CXX="$target-g++"
-if which "$CXX" ; then
-   prefix=`"$CXX" --verbose 2>&1 | grep 'Configured with' | sed 
's/.*prefix=//' | sed 's/ .*//'`
 
+case $# in
+   1)
+   if ! which "$CXX" ; then
+   exit 1
+   fi
+   prefix=`"$CXX" --verbose 2>&1 | grep 'Configured with' | sed 
's/.*prefix=//' | sed 's/ .*//'`
+   ;;
+
+   2)
+   prefix="$2"
+   ;;
+
+   *)
+   echo "usage install-target.sh  []"
+   exit 1
+   ;;
+esac
+
+if which "$CXX" ; then
for i in `"$CXX" --print-multi-lib` ; do
multilibdir=`echo $i | sed 's/;.*//'`
CFLAGS=`echo $i | sed 's/.*;//' | sed 's/@/ -/g'`
-- 
2.11.0

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

[PATCH 1/3] rtems: Handle multi-level multilib directories

2017-09-30 Thread Martin Erik Werner

Sometimes, multilib directories have multiple levels, for example
no-delay/soft-float, make sure to handle this by creating directories
before installing.

Signed-off-by: Martin Erik Werner <martin.wer...@aacmicrotec.com>
---
 rtems/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rtems/Makefile b/rtems/Makefile
index 52a82df..4852d60 100644
--- a/rtems/Makefile
+++ b/rtems/Makefile
@@ -43,6 +43,7 @@ $(BUILDDIR)/%.o: $(SRCDIR)/%.cc
$(CXX) $(CPPFLAGS) $(CFLAGS) $(DEPFLAGS) $(WARNFLAGS) -c $< -o $@
 
 install: all
+   mkdir -p $(PREFIX)/$(TARGET)/lib/$(MULTILIBDIR)
install -m 644 -t $(PREFIX)/$(TARGET)/lib/$(MULTILIBDIR) $(LIB)
 
 RTEMS_HEADERS =
-- 
2.11.0

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

[PATCH 0/3] Some fixes for Google Test on RTEMS

2017-09-30 Thread Martin Erik Werner

Based on some experimentation with Google Test on RTEMS, here are some
patches that fell out of that process, which might be interesting?

Martin Erik Werner (3):
  rtems: Handle multi-level multilib directories
  rtems: Make prefix configurable
  rtems: Provide nonzero argc required by gtest init

 rtems/Makefile  |  1 +
 rtems/gtest-main.h  |  5 +++--
 rtems/install-target.sh | 21 +++--
 3 files changed, 23 insertions(+), 4 deletions(-)

I have tested this on a non-virtual or1k target, and gotten it working
with the precompiled and installed gtest.a and gtest-main.h.

Some details that might be worth noting is that:
* -std=gnu++11 appears to be needed for fdopen() and other posix
  non-ansi friends.
* -lgtest must be linked after the test suite object.

-- 
2.11.0

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

Re: [PATCH 0/5] or1k: Optimisation and implementation of cache manager functions

2016-11-30 Thread Martin Erik Werner

On Mon, 2016-11-28 at 07:32 +0100, Sebastian Huber wrote:
> Thanks, I check in all patches to the master. If you need a back port
> to 4.11, then please open a ticket. 

Thank you.

We are carrying quite a lot of other patches on top of 4.11 (as
noted/submitted in
https://lists.rtems.org/pipermail/devel/2016-February/013637.html), of
which the cache changes are only a subset. I'm thinking we'll hold off
requesting backports until we've managed to clean up and submit the
majority of those to master.

--
Martin Erik Werner <martin.wer...@aacmicrotec.com>
ÅAC Microtec AB

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

[PATCH 1/5] or1k: Add functions for entire cache operations

2016-11-25 Thread Martin Erik Werner

Add functions for flushing and invalidating whole cache.

Since we don't have system calls that can operate on anything more than
a single cache line, these simply retrieves the cache size and iterates
over the full size, invalidating each line.

The current implementation assumes that there's only one level of cache.

These changes were contributed by Antmicro under contract by ÅAC
Microtec AB.

Close #2602
---
 c/src/lib/libcpu/or1k/shared/cache/cache.c | 45 --
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache.c 
b/c/src/lib/libcpu/or1k/shared/cache/cache.c
index 54728e1..88cda1a 100644
--- a/c/src/lib/libcpu/or1k/shared/cache/cache.c
+++ b/c/src/lib/libcpu/or1k/shared/cache/cache.c
@@ -1,4 +1,8 @@
 /*
+ * COPYRIGHT (c) 2014 ÅAC Microtec AB 
+ * Contributor(s):
+ *  Karol Gugala 
+ *
  * COPYRIGHT (c) 2014 Hesham ALMatary 
  *
  * COPYRIGHT (c) 1989-2006
@@ -14,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline void _CPU_OR1K_Cache_enable_data(void)
 {
@@ -206,17 +211,51 @@ void _CPU_cache_unfreeze_instruction(void)
 
 void _CPU_cache_flush_entire_data(void)
 {
-
+  int addr;
+
+  /* We have only 0 level cache so we do not need to invalidate others */
+  for (
+  addr = _CPU_cache_get_data_cache_size(0);
+  addr > 0;
+  addr -= CPU_DATA_CACHE_ALIGNMENT
+  ) {
+_CPU_OR1K_Cache_data_block_flush((uintptr_t) addr);
+  }
 }
 
 void _CPU_cache_invalidate_entire_data(void)
 {
-
+  int addr;
+
+  /* We have only 0 level cache so we do not need to invalidate others */
+  for (
+  addr = _CPU_cache_get_data_cache_size(0);
+  addr > 0;
+  addr -= CPU_DATA_CACHE_ALIGNMENT
+  ) {
+_CPU_cache_invalidate_1_data_line((uintptr_t) addr);
+  }
 }
 
 void _CPU_cache_invalidate_entire_instruction(void)
 {
-
+  int addr;
+
+  /* We have only 0 level cache so we do not need to invalidate others */
+  for (
+  addr = _CPU_cache_get_instruction_cache_size(0);
+  addr > 0;
+  addr -= CPU_INSTRUCTION_CACHE_ALIGNMENT
+  ) {
+_CPU_cache_invalidate_1_instruction_line((uintptr_t) addr);
+  }
+
+  /* Flush instructions out of instruction buffer */
+  __asm__ volatile("l.nop");
+  __asm__ volatile("l.nop");
+  __asm__ volatile("l.nop");
+  __asm__ volatile("l.nop");
+  __asm__ volatile("l.nop");
 }
 
 void _CPU_cache_enable_data(void)
-- 
2.1.4

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

[PATCH 0/5] or1k: Optimisation and implementation of cache manager functions

2016-11-25 Thread Martin Erik Werner

These patches are mainly optimisation changes to the or1k cache manager
functions. They were made for use on our custom boards, but should be applicable
to or1k in general.

We have used and tested these patches as part of a larger set of changes for
our boards on the 4.11 branch on top of rtems commit 5807328.

No testing except compilation has been performed on the rebased patch set on
master.

Martin Erik Werner (5):
  or1k: Add functions for entire cache operations
  or1k: Indent & comment fix in cache.c
  or1k: Avoid excessive ISR toggle in cache manager
  or1k: Remove secondary functions in cache manager
  or1k: Avoid multiple iterations over cache

 c/src/lib/libcpu/or1k/shared/cache/cache.c  | 316 +++-
 c/src/lib/libcpu/or1k/shared/cache/cache_.h |   6 +
 2 files changed, 228 insertions(+), 94 deletions(-)

-- 
2.1.4

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

[PATCH 3/5] or1k: Avoid excessive ISR toggle in cache manager

2016-11-25 Thread Martin Erik Werner

Previously _ISR_Local_{disable,enable}() was executed twice for each
cache line operation, and since operations over the entire cache were
implemented by calling the single-line operations in a loop, this made
those operations rather costly.

Fix the double-toggle by calling _OR1K_mtspr() directly, and removing
the now-unused corresponding _CPU_OR1K_Cache_* functions.

Fix the entire-operations by moving the ISR toggle outside of the
loop, and by calling _OR1K_mtspr() directly instead of the single-line
operations.

Also implement range functions, since otherwise the cache manager falls
back on looping over the single-line operations.
---
 c/src/lib/libcpu/or1k/shared/cache/cache.c  | 161 
 c/src/lib/libcpu/or1k/shared/cache/cache_.h |   6 ++
 2 files changed, 123 insertions(+), 44 deletions(-)

diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache.c 
b/c/src/lib/libcpu/or1k/shared/cache/cache.c
index 5d7053f..e1b2b1d 100644
--- a/c/src/lib/libcpu/or1k/shared/cache/cache.c
+++ b/c/src/lib/libcpu/or1k/shared/cache/cache.c
@@ -1,7 +1,8 @@
 /*
- * COPYRIGHT (c) 2014 ÅAC Microtec AB 
+ * COPYRIGHT (c) 2014, 2016 ÅAC Microtec AB 
  * Contributor(s):
  *  Karol Gugala 
+ *  Martin Werner 
  *
  * COPYRIGHT (c) 2014 Hesham ALMatary 
  *
@@ -83,28 +84,6 @@ static inline void _CPU_OR1K_Cache_data_block_prefetch(const 
void *d_addr)
   _ISR_Local_enable(level);
 }
 
-static inline void _CPU_OR1K_Cache_data_block_flush(const void *d_addr)
-{
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  _OR1K_mtspr(CPU_OR1K_SPR_DCBFR, (uintptr_t) d_addr);
-
-  _ISR_Local_enable(level);
-}
-
-static inline void _CPU_OR1K_Cache_data_block_invalidate(const void *d_addr)
-{
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  _OR1K_mtspr(CPU_OR1K_SPR_DCBIR, (uintptr_t) d_addr);
-
-  _ISR_Local_enable(level);
-}
-
 static inline void _CPU_OR1K_Cache_data_block_writeback(const void *d_addr)
 {
   ISR_Level level;
@@ -139,18 +118,6 @@ static inline void 
_CPU_OR1K_Cache_instruction_block_prefetch
   _ISR_Local_enable(level);
 }
 
-static inline void _CPU_OR1K_Cache_instruction_block_invalidate
-(const void *d_addr)
-{
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  _OR1K_mtspr(CPU_OR1K_SPR_ICBIR, (uintptr_t) d_addr);
-
-  _ISR_Local_enable(level);
-}
-
 static inline void _CPU_OR1K_Cache_instruction_block_lock
 (const void *d_addr)
 {
@@ -171,7 +138,7 @@ void _CPU_cache_flush_1_data_line(const void *d_addr)
 
   _ISR_Local_disable (level);
 
-  _CPU_OR1K_Cache_data_block_flush(d_addr);
+  _OR1K_mtspr(CPU_OR1K_SPR_DCBFR, (uintptr_t) d_addr);
 
   //__asm__ volatile("l.csync");
 
@@ -184,7 +151,7 @@ void _CPU_cache_invalidate_1_data_line(const void *d_addr)
 
   _ISR_Local_disable (level);
 
-  _CPU_OR1K_Cache_data_block_invalidate(d_addr);
+  _OR1K_mtspr(CPU_OR1K_SPR_DCBIR, (uintptr_t) d_addr);
 
   _ISR_Local_enable(level);
 }
@@ -205,7 +172,7 @@ void _CPU_cache_invalidate_1_instruction_line(const void 
*d_addr)
 
   _ISR_Local_disable (level);
 
-  _CPU_OR1K_Cache_instruction_block_invalidate(d_addr);
+  _OR1K_mtspr(CPU_OR1K_SPR_ICBIR, (uintptr_t) d_addr);
 
   _ISR_Local_enable(level);
 }
@@ -222,7 +189,10 @@ void _CPU_cache_unfreeze_instruction(void)
 
 void _CPU_cache_flush_entire_data(void)
 {
-  int addr;
+  size_t addr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
 
   /* We have only 0 level cache so we do not need to invalidate others */
   for (
@@ -230,13 +200,18 @@ void _CPU_cache_flush_entire_data(void)
   addr > 0;
   addr -= CPU_DATA_CACHE_ALIGNMENT
   ) {
-_CPU_OR1K_Cache_data_block_flush((uintptr_t) addr);
+_OR1K_mtspr(CPU_OR1K_SPR_DCBFR, (uintptr_t) addr);
   }
+
+  _ISR_Local_enable (level);
 }
 
 void _CPU_cache_invalidate_entire_data(void)
 {
-  int addr;
+  size_t addr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
 
   /* We have only 0 level cache so we do not need to invalidate others */
   for (
@@ -244,13 +219,18 @@ void _CPU_cache_invalidate_entire_data(void)
   addr > 0;
   addr -= CPU_DATA_CACHE_ALIGNMENT
   ) {
-_CPU_cache_invalidate_1_data_line((uintptr_t) addr);
+_OR1K_mtspr(CPU_OR1K_SPR_DCBIR, (uintptr_t) addr);
   }
+
+  _ISR_Local_enable (level);
 }
 
 void _CPU_cache_invalidate_entire_instruction(void)
 {
-  int addr;
+  size_t addr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
 
   /* We have only 0 level cache so we do not need to invalidate others */
   for (
@@ -258,7 +238,7 @@ void _CPU_cache_invalidate_entire_instruction(void)
   addr > 0;
   addr -= CPU_INSTRUCTION_CACHE_ALIGNMENT
   ) {
-_CPU_cache_invalidate_1_instruction_line((uintptr_t) addr);
+_OR1K_mtspr(CPU_OR1K_SPR_ICBIR, (uintptr_t) addr);
   }
 
   /* Flush instructions out of instruction buffer */
@@ -267,6 +247,99 @@ void _CPU_cache_invalidate_entire_instruction(void)
   __asm__ volatile("l.nop");
   __asm__ volatile("l.nop");

[PATCH 5/5] or1k: Avoid multiple iterations over cache

2016-11-25 Thread Martin Erik Werner

Previously, if the cache range operations were called with a range that
was larger than the cache size, this would lead to multiple iterations
over the cache, which is unnecessary.

Limit this so that if the range is larger than the cache size, the
operations will only iterate over the whole cache once.
---
 c/src/lib/libcpu/or1k/shared/cache/cache.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache.c 
b/c/src/lib/libcpu/or1k/shared/cache/cache.c
index 6c1f9d9..47bc8f8 100644
--- a/c/src/lib/libcpu/or1k/shared/cache/cache.c
+++ b/c/src/lib/libcpu/or1k/shared/cache/cache.c
@@ -224,6 +224,15 @@ void _CPU_cache_flush_data_range(const void *d_addr, 
size_t n_bytes)
   final_address = (void *)((size_t)d_addr + n_bytes - 1);
   d_addr = (void *)((size_t)d_addr & ~(CPU_DATA_CACHE_ALIGNMENT - 1));
 
+  if( final_address - d_addr > _CPU_cache_get_data_cache_size(0) ) {
+/*
+ * Avoid iterating over the whole cache multiple times if the range is
+ * larger than the cache size.
+ */
+_CPU_cache_flush_entire_data();
+return;
+  }
+
   _ISR_Local_disable (level);
 
   while( d_addr <= final_address )  {
@@ -252,6 +261,15 @@ void _CPU_cache_invalidate_data_range(const void *d_addr, 
size_t n_bytes)
   final_address = (void *)((size_t)d_addr + n_bytes - 1);
   d_addr = (void *)((size_t)d_addr & ~(CPU_DATA_CACHE_ALIGNMENT - 1));
 
+  if( final_address - d_addr > _CPU_cache_get_data_cache_size(0) ) {
+/*
+ * Avoid iterating over the whole cache multiple times if the range is
+ * larger than the cache size.
+ */
+_CPU_cache_invalidate_entire_data();
+return;
+  }
+
   _ISR_Local_disable (level);
 
   while( d_addr <= final_address )  {
@@ -280,6 +298,15 @@ void _CPU_cache_invalidate_instruction_range(const void 
*i_addr, size_t n_bytes)
   final_address = (void *)((size_t)i_addr + n_bytes - 1);
   i_addr = (void *)((size_t)i_addr & ~(CPU_INSTRUCTION_CACHE_ALIGNMENT - 1));
 
+  if( final_address - i_addr > _CPU_cache_get_data_cache_size(0) ) {
+/*
+ * Avoid iterating over the whole cache multiple times if the range is
+ * larger than the cache size.
+ */
+_CPU_cache_invalidate_entire_instruction();
+return;
+  }
+
   _ISR_Local_disable (level);
 
   while( i_addr <= final_address )  {
-- 
2.1.4

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

[PATCH 4/5] or1k: Remove secondary functions in cache manager

2016-11-25 Thread Martin Erik Werner

Move the code of the _CPU_OR1K_Cache_{enable,disable}_* functions into the
equivalent exported _CPU_cache_{enable,disable}_* functions instead, and
then delete them, in order to reduce the code indirection and aid
readability.

This does not touch the currently unused prefetch, writeback, and lock
functions.
---
 c/src/lib/libcpu/or1k/shared/cache/cache.c | 90 +++---
 1 file changed, 34 insertions(+), 56 deletions(-)

diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache.c 
b/c/src/lib/libcpu/or1k/shared/cache/cache.c
index e1b2b1d..6c1f9d9 100644
--- a/c/src/lib/libcpu/or1k/shared/cache/cache.c
+++ b/c/src/lib/libcpu/or1k/shared/cache/cache.c
@@ -21,58 +21,6 @@
 #include 
 #include 
 
-static inline void _CPU_OR1K_Cache_enable_data(void)
-{
-  uint32_t sr;
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
-  _OR1K_mtspr(CPU_OR1K_SPR_SR, sr | CPU_OR1K_SPR_SR_DCE);
-
-  _ISR_Local_enable(level);
-}
-
-static inline void _CPU_OR1K_Cache_disable_data(void)
-{
-  uint32_t sr;
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
-  _OR1K_mtspr(CPU_OR1K_SPR_SR, (sr & ~CPU_OR1K_SPR_SR_DCE));
-
-  _ISR_Local_enable(level);
-}
-
-static inline void _CPU_OR1K_Cache_enable_instruction(void)
-{
-  uint32_t sr;
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
-  _OR1K_mtspr(CPU_OR1K_SPR_SR, sr | CPU_OR1K_SPR_SR_ICE);
-
-  _ISR_Local_enable(level);
-}
-
-static inline void _CPU_OR1K_Cache_disable_instruction(void)
-{
-  uint32_t sr;
-  ISR_Level level;
-
-  _ISR_Local_disable (level);
-
-  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
-  _OR1K_mtspr(CPU_OR1K_SPR_SR, (sr & ~CPU_OR1K_SPR_SR_ICE));
-
-  _ISR_Local_enable(level);
-}
-
 static inline void _CPU_OR1K_Cache_data_block_prefetch(const void *d_addr)
 {
   ISR_Level level;
@@ -344,22 +292,52 @@ void _CPU_cache_invalidate_instruction_range(const void 
*i_addr, size_t n_bytes)
 
 void _CPU_cache_enable_data(void)
 {
-  _CPU_OR1K_Cache_enable_data();
+  uint32_t sr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
+
+  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
+  _OR1K_mtspr(CPU_OR1K_SPR_SR, sr | CPU_OR1K_SPR_SR_DCE);
+
+  _ISR_Local_enable(level);
 }
 
 void _CPU_cache_disable_data(void)
 {
-  _CPU_OR1K_Cache_disable_data();
+  uint32_t sr;
+  ISR_Level level;
 
+  _ISR_Local_disable (level);
+
+  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
+  _OR1K_mtspr(CPU_OR1K_SPR_SR, (sr & ~CPU_OR1K_SPR_SR_DCE));
+
+  _ISR_Local_enable(level);
 }
 
 void _CPU_cache_enable_instruction(void)
 {
+  uint32_t sr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
+
+  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
+  _OR1K_mtspr(CPU_OR1K_SPR_SR, sr | CPU_OR1K_SPR_SR_ICE);
 
-  _CPU_OR1K_Cache_enable_instruction();
+  _ISR_Local_enable(level);
 }
 
 void _CPU_cache_disable_instruction(void)
 {
-  _CPU_OR1K_Cache_disable_instruction();
+  uint32_t sr;
+  ISR_Level level;
+
+  _ISR_Local_disable (level);
+
+  sr = _OR1K_mfspr(CPU_OR1K_SPR_SR);
+  _OR1K_mtspr(CPU_OR1K_SPR_SR, (sr & ~CPU_OR1K_SPR_SR_ICE));
+
+  _ISR_Local_enable(level);
 }
-- 
2.1.4

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

[PATCH 1/2] Add option to limit bootstrap to a single arch

2016-02-19 Thread Martin Erik Werner

Using the -o|--only  option, it is now possible to limit the
bootstrapping operation of arch-specific libbsp, libcpu and cpukit paths
to a single arch, for example:

  $ bootstrap -p -o or1k

and

  $ bootstrap -o or1k

This is a somewhat ugly implementation, but may be sufficient for the
intended usage.

* The cleaning operation is not currently able to selectively clean
  archs
* It is currently not possible to specify more than one arch at a time

This reduces bootstrap time to around a third compared to a full run.
---
 bootstrap | 60 
 1 file changed, 60 insertions(+)

diff --git a/bootstrap b/bootstrap
index e9cb851..3434e51 100755
--- a/bootstrap
+++ b/bootstrap
@@ -17,6 +17,7 @@ verbose=""
 quiet="false"
 mode="autoreconf"
 force=0
+bsp_to_build=
 
 usage()
 {
@@ -27,6 +28,7 @@ usage()
   echo "   -c .. clean, remove all aclocal/autoconf/automake generated 
files"
   echo "   -h .. display this message and exit"
   echo "   -p .. regenerate preinstall.am files"
+  echo "   -o  .. only generate for given "
   echo "   -q .. quiet, don't display directories"
   echo "   -v .. verbose, pass -v to autotools"
   echo
@@ -94,6 +96,11 @@ case $1 in
 -g|--ge|--gen|--gene|--gener|--genera|--generat|--generate)
   mode="generate"
   shift;;
+-o|--on|--onl|--only)
+  test $# -gt 1 || usage
+  bsp_to_build=$2
+  shift
+  shift;;
 -*) echo "unknown option $1"
   usage ;;
 *) echo "invalid parameter $1"
@@ -105,6 +112,27 @@ case $mode in
 preinstall)
   confs=`find . -name Makefile.am -exec grep -l 'include .*/preinstall\.am' {} 
\;`
   for i in $confs; do
+if test -n "$bsp_to_build"; then
+  case $i in
+   ./c/src/lib/libbsp/$bsp_to_build/*)
+ ;;
+   ./c/src/lib/libbsp/*)
+ continue; # skip this file
+ ;;
+   ./c/src/lib/libcpu/$bsp_to_build/*)
+ ;;
+   ./c/src/lib/libcpu/*)
+ continue #skip this file
+ ;;
+   ./cpukit/score/cpu/$bsp_to_build/*)
+ ;;
+   ./cpukit/score/cpu/*)
+ continue #skip this file
+ ;;
+   *)
+ ;;
+  esac
+fi
 dir=$(dirname $i)
 test "$quite" = "true" || echo "Generating $dir/preinstall.am"
 ${top_srcdir}/ampolish3 "$dir/Makefile.am" > "$dir/preinstall.am"
@@ -145,6 +173,22 @@ generate)
 
   confs=`find . \( -name 'configure.in' -o -name 'configure.ac' \) -print`
   for i in $confs; do
+  if test -n "$bsp_to_build"; then
+case $i in
+  ./c/src/lib/libbsp/$bsp_to_build/*)
+   ;;
+  ./c/src/lib/libbsp/*)
+   continue # skip this file
+   ;;
+  ./c/src/lib/libcpu/$bsp_to_build/*)
+   ;;
+  ./c/src/lib/libcpu/*)
+   continue #skip this file
+   ;;
+  *)
+   ;;
+esac
+  fi
   dir=`dirname $i`
   configure=`basename $i`
   ( test "$quiet" = "true" || echo "$dir"
@@ -177,6 +221,22 @@ autoreconf)
 
   confs=`find . -name 'configure.ac' -print`
   for i in $confs; do
+  if test -n "$bsp_to_build"; then
+case $i in
+  ./c/src/lib/libbsp/$bsp_to_build/*)
+   ;;
+  ./c/src/lib/libbsp/*)
+   continue # skip this file
+   ;;
+  ./c/src/lib/libcpu/$bsp_to_build/*)
+   ;;
+  ./c/src/lib/libcpu/*)
+   continue #skip this file
+   ;;
+  *)
+   ;;
+esac
+  fi
   dir=`dirname $i`
   configure=`basename $i`
   ( test "$quiet" = "true" || echo "$dir"
-- 
1.9.1

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

48 matches

Mail list logo