[PATCH] Avoid StopIteration exception for non-rtems .pc
_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
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
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
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
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
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
--- 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
--- 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
--- 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
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
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
(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. "
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
_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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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