Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
>The CAN bus changes have warnings ...
>
>In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
>from ../../../cpukit/dev/can/can.c:45:
>../../../cpukit/dev/can/can.c: In function 'can_bus_read':
>../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects
argument of
>type 'unsigned int', but argument 2 has type 'long unsigned int'
[-Wformat=]
> 213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
>can_msg) = %u\n",
> |
>^~
> 214 | sizeof(struct can_msg));
> | ~~
> | |
> | long unsigned int
>../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
>
>etc etc etc
>
>Can these please be fixed? Use #4662.
Yes, I will typecast the value returned by sizeof().
Regards
Prashanth S
On Fri, 2 Dec 2022 at 09:09, Chris Johns wrote:
> The CAN bus changes have warnings ...
>
> In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
> from ../../../cpukit/dev/can/can.c:45:
> ../../../cpukit/dev/can/can.c: In function 'can_bus_read':
> ../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects
> argument of
> type 'unsigned int', but argument 2 has type 'long unsigned int'
> [-Wformat=]
> 213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
> can_msg) = %u\n",
> |
> ^~
> 214 | sizeof(struct can_msg));
> | ~~
> | |
> | long unsigned int
> ../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
>
> etc etc etc
>
> Can these please be fixed? Use #4662.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hands up, do you use the Mini Robomind BSP (MRM332)?
Hi all, The Mini Robomind is a board that was available through the Seattle Robotics Society that used the Motorola MC68332 processor. The BSP is called MRM332. I was wondering if anybody uses this BSP, either for a Mini Robomind or as a basis for some other MC68332 board? Why? I was talking with Joel and Chris during the RTEMS6.1 ticket review and asked if they knew if anybody used MRM332 anymore. I have not seen any discussion of this BSP or the ‘332 for years and figured that it may be time to sunset the BSP rather than continue to keep it up to date if nobody is using it. I’m putting together an email to the Seattle Robotics Society to see if they have any interest, but please speak up if you use this BSP. Thanks, Andrei Chichak (from The Great White North (where it is going down to -33C tonight)) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Hands up, do you use the Mini Robomind BSP (MRM332)?
Hi all,The Mini Robomind is a board that was available through the Seattle Robotics Society that used the Motorola MC68332 processor. The BSP is called MRM332.I was wondering if anybody uses this BSP, either for a Mini Robomind or as a basis for some other MC68332 board?Why? I was talking with Joel and Chris during the RTEMS6.1 ticket review and asked if they knew if anybody used MRM332 anymore. I have not seen any discussion of this BSP or the ‘332 for years and figured that it may be time to sunset the BSP rather than continue to keep it up to date if nobody is using it.I’m putting together an email to the Seattle Robotics Society to see if they have any interest, but please speak up if you use this BSP.Thanks,Andrei Chichak (from The Great White North (where it is going down to -33C tonight))___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Moving ticket milestones to a different RTEMS version
Hi, Joel and I have been cleaning up the 6 tickets and some have been moved to 7 (thanks) which may be appropriate however I am wondering about open ended tickets for a specific set of work and release notes. These tickets are really great for collecting commits for a specific change. The release notes are based on the tickets for a release and milestone. An open ended ticket for a specific task when part of release collects the related commits however moving that ticket to the next release moves the commits to that release's release notes and the current release does not see the commits in its release notes? Should the ticket be cloned (without comments?) to the next release and the one on the current release closed. It seems to make sense to me. The work is continuing however it is closed for the branch being release? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
On 2/12/2022 2:38 pm, Chris Johns wrote:
> The CAN bus changes have warnings ...
>
> In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
> from ../../../cpukit/dev/can/can.c:45:
> ../../../cpukit/dev/can/can.c: In function 'can_bus_read':
> ../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
> type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
> 213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
> can_msg) = %u\n",
> |
> ^~
> 214 | sizeof(struct can_msg));
> | ~~
> | |
> | long unsigned int
> ../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
>
> etc etc etc
>
> Can these please be fixed? Use #4662.
I should add I used the aarch64/xilinx_zynqmp_lp64_zu3eg BSP so it looks like
these are 64bit related. I hope that helps. I do not see them with 32bit builds.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
The CAN bus changes have warnings ...
In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
from ../../../cpukit/dev/can/can.c:45:
../../../cpukit/dev/can/can.c: In function 'can_bus_read':
../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
can_msg) = %u\n",
|
^~
214 | sizeof(struct can_msg));
| ~~
| |
| long unsigned int
../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
etc etc etc
Can these please be fixed? Use #4662.
Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New RISC-V BSP variant (Kendryte K210)
On Thu, Dec 1, 2022 at 6:06 PM Joel Sherrill wrote: > > I'm going to say enthusiastically yes. > > I suspect that other boards will be very similar so this is likely a good > basis to go from. > > If you have links where it is actually for sale and not just described, that > would be great. Seeed Studio: https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html?queryID=86b62e47589a0b56236a5c29ab704818=4047=bazaar_retailer_products They have a number of other boards and modules, but most have not been in stock for a while. I'm not sure if it's a supply chain problem like the Raspberry Pi, or they are no longer available. Also here: https://www.dfrobot.com/product-1985.html https://www.dfrobot.com/product-1972.html Boards and modules are also available on Aliexpress. > > Chris would likely encourage you to post rtems-tester results. :) I have been using the Rednode.io test framework. I'm currently running a dozen tests, but I would like to try using rtems-tester. > > And perhaps we can reach out and let them know RTEMS is available on their > hardware. Chris might enjoy poking that bear. lol I'm sure they would not mind. There are ports of rt-thread, nuttx, and no-mmu linux to the SoC. Kendrtye offers a bare metal SDK with the Apache 2.0 license: https://github.com/kendryte/kendryte-standalone-sdk They did have a FreeRTOS SDK, but it is no longer maintained: https://github.com/kendryte/kendryte-freertos-sdk I don't think there are any binary blobs needed, and an RTEMS image can just be flashed to the boards using a "kflash.py" utility that is available through pip, so getting started is easy: Just build RTEMS images and either run on renode or flash via USB cable. Alan > > On Thu, Dec 1, 2022, 1:46 PM Alan Cudmore wrote: >> >> Hi, >> I have been working on a basic BSP for the Kendryte K210 RISC-V CPU, >> and I was wondering if the community members would like me to submit >> it. >> The Kendryte K210 is a dual core 64 bit RISC-V processor with a wealth >> of peripheral I/O, a built-in AI NPU, and 8 Megabytes of on-chip SRAM. >> I like it because it is one of the lowest cost RISC-V CPUs available, >> and it appears to run RTEMS well. >> In addition, my BSP works on the K210 model on the renode.io >> simulator. I believe it would work on QEMU, but it is very close to >> the rv64imafdc_medany riscv BSP variant. >> The changes consist of: >> - A new riscv/riscv variant and associated build option files >> - A new DTB header, since the DTB is included in the BSP similar to >> the polarfire BSP >> - Some code to detect the frequency in bspstart.c >> - A new header file for the k210 >> Because the console uses the same sifive uart as the frdme310arty BSP, >> I factored that out so the Sifive UART can be used in multiple BSP >> variants. It is able to use the existing timer and interrupt code. >> >> In addition to the renode.io simulator, I have run it on the following >> boards: >> - Sipeed MAIX Bit >> - Sipeed MAIXduino (arduino form factor board with ESP32) >> - Sipeed Grove AI hat for Raspberry Pi >> >> Potential negatives: >> - I do not have a BSD licensed device tree source, I created the >> device tree binary from the u-boot distribution. Is it OK to just >> include the device tree binary (similar to the microblaze)? >> - The availability of these boards has not been as good for the last >> year or so, but you can still find them at a relatively low cost. The >> Sipeed company seems to be focusing on another low cost RISC-V SoC, >> which is very interesting as well: The Bouffalo Lab BL808 (example >> here: >> https://wiki.pine64.org/wiki/Ox64) >> >> Is this worth submitting? I don't want to clutter up the tree with >> devices that may become obsolete - we could focus on the upcoming >> round of low cost RISC-V SoCs like the BL808. >> I don't have a specific application I am using it for, but I used it >> as a very inexpensive way to learn RISC-V on a real board. It may be >> of some value to integrate additional peripheral support including the >> AI NPU. >> >> If anyone is interested, I can submit the patches or even provide a >> branch on github. >> >> Thanks, >> Alan >> ___ >> 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
Request for Coverity Issue Review
Hi As we approach a release branch, it would be helpful if 1+ persons would kindly volunteer to see if they can kill some of the Coverity reported issues. I admit I haven't looked at them this week. I'm busy killing tickets before 6. :) Help appreciated. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Request for comments on more BSP or architecture port deprecations
Hi As we head toward a release branch, it is time to once again ask if anything else should be deprecated in 6. We currently have sh, sparc64, and v850 marked for deprecation. That means they will be included in 6 but removed from the master soon after branching. Any others living on borrowed time? Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New RISC-V BSP variant (Kendryte K210)
I'm going to say enthusiastically yes. I suspect that other boards will be very similar so this is likely a good basis to go from. If you have links where it is actually for sale and not just described, that would be great. Chris would likely encourage you to post rtems-tester results. :) And perhaps we can reach out and let them know RTEMS is available on their hardware. Chris might enjoy poking that bear. lol On Thu, Dec 1, 2022, 1:46 PM Alan Cudmore wrote: > Hi, > I have been working on a basic BSP for the Kendryte K210 RISC-V CPU, > and I was wondering if the community members would like me to submit > it. > The Kendryte K210 is a dual core 64 bit RISC-V processor with a wealth > of peripheral I/O, a built-in AI NPU, and 8 Megabytes of on-chip SRAM. > I like it because it is one of the lowest cost RISC-V CPUs available, > and it appears to run RTEMS well. > In addition, my BSP works on the K210 model on the renode.io > simulator. I believe it would work on QEMU, but it is very close to > the rv64imafdc_medany riscv BSP variant. > The changes consist of: > - A new riscv/riscv variant and associated build option files > - A new DTB header, since the DTB is included in the BSP similar to > the polarfire BSP > - Some code to detect the frequency in bspstart.c > - A new header file for the k210 > Because the console uses the same sifive uart as the frdme310arty BSP, > I factored that out so the Sifive UART can be used in multiple BSP > variants. It is able to use the existing timer and interrupt code. > > In addition to the renode.io simulator, I have run it on the following > boards: > - Sipeed MAIX Bit > - Sipeed MAIXduino (arduino form factor board with ESP32) > - Sipeed Grove AI hat for Raspberry Pi > > Potential negatives: > - I do not have a BSD licensed device tree source, I created the > device tree binary from the u-boot distribution. Is it OK to just > include the device tree binary (similar to the microblaze)? > - The availability of these boards has not been as good for the last > year or so, but you can still find them at a relatively low cost. The > Sipeed company seems to be focusing on another low cost RISC-V SoC, > which is very interesting as well: The Bouffalo Lab BL808 (example > here: > https://wiki.pine64.org/wiki/Ox64) > > Is this worth submitting? I don't want to clutter up the tree with > devices that may become obsolete - we could focus on the upcoming > round of low cost RISC-V SoCs like the BL808. > I don't have a specific application I am using it for, but I used it > as a very inexpensive way to learn RISC-V on a real board. It may be > of some value to integrate additional peripheral support including the > AI NPU. > > If anyone is interested, I can submit the patches or even provide a > branch on github. > > Thanks, > Alan > ___ > 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/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
Looks good. Thanks Chris On 1/12/2022 11:10 pm, Sebastian Huber wrote: > This enables the tracing of interrupt entry/exit events through an > application configuration option. The interrupt processing can be > viewed with Trace Compass. > > Sebastian Huber (3): > bsps/irq: Rename handler in dispatch table > bsps/irq: Add bsp_interrupt_get_dispatch_table_slot() > config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED > > bsps/include/bsp/irq-generic.h| 79 --- > bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 +- > bsps/riscv/riscv/include/tm27.h | 4 +- > bsps/shared/irq/irq-entry-remove.c| 6 +- > bsps/shared/irq/irq-generic.c | 41 > bsps/shared/irq/irq-handler-iterate.c | 4 +- > bsps/shared/irq/irq-record.c | 97 +++ > cpukit/doxygen/appl-config.h | 23 + > cpukit/include/rtems/confdefs/extensions.h| 8 ++ > cpukit/include/rtems/record.h | 2 + > spec/build/bsps/objirq.yml| 1 + > spec/build/bsps/powerpc/ss555/bspss555.yml| 1 + > .../validation/tc-bsp-interrupt-spurious.c| 4 +- > testsuites/validation/tc-intr-entry-install.c | 4 +- > testsuites/validation/tc-intr-entry-remove.c | 8 +- > .../validation/tc-intr-handler-iterate.c | 4 +- > 16 files changed, 218 insertions(+), 70 deletions(-) > create mode 100644 bsps/shared/irq/irq-record.c > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Document CONFIGURE_RECORD_INTERRUPTS_ENABLED
Looks good.
Thanks
Chris
On 1/12/2022 11:11 pm, Sebastian Huber wrote:
> Close #4769.
> ---
> c-user/config/event-record.rst | 43 +-
> user/tracing/eventrecording.rst | 65 +++--
> 2 files changed, 47 insertions(+), 61 deletions(-)
>
> diff --git a/c-user/config/event-record.rst b/c-user/config/event-record.rst
> index 31a4fa9..f1e7969 100644
> --- a/c-user/config/event-record.rst
> +++ b/c-user/config/event-record.rst
> @@ -1,6 +1,6 @@
> .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2019, 2021 embedded brains GmbH
> (http://www.embedded-brains.de)
> +.. Copyright (C) 2019, 2022 embedded brains GmbH
> (http://www.embedded-brains.de)
>
> .. This file is part of the RTEMS quality process and was automatically
> .. generated. If you find something that needs to be fixed or
> @@ -150,6 +150,47 @@ in a fatal error extension (see :ref:`Terminate`).
> The zlib compression needs about 512KiB of RAM. This extension can be used
> to produce crash dumps.
>
> +.. Generated from spec:/acfg/if/record-interrupts-enabled
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +
> +.. _CONFIGURE_RECORD_INTERRUPTS_ENABLED:
> +
> +CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +---
> +
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_RECORD_INTERRUPTS_ENABLED``
> +
> +.. rubric:: OPTION TYPE:
> +
> +This configuration option is a boolean feature define.
> +
> +.. rubric:: DEFAULT CONFIGURATION:
> +
> +If this configuration option is undefined, then the described feature is not
> +enabled.
> +
> +.. rubric:: DESCRIPTION:
> +
> +In case
> +
> +* this configuration option is defined
> +
> +* and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS` is properly defined,
> +
> +then the interrupt event recording is enabled.
> +
> +.. rubric:: NOTES:
> +
> +The interrupt event recording generates interrupt entry and exit events when
> +interrupt entries are dispatched.
> +
> .. Generated from spec:/acfg/if/record-per-processor-items
>
> .. raw:: latex
> diff --git a/user/tracing/eventrecording.rst b/user/tracing/eventrecording.rst
> index 7130658..b5561cc 100644
> --- a/user/tracing/eventrecording.rst
> +++ b/user/tracing/eventrecording.rst
> @@ -48,8 +48,11 @@ The application enables the event recording support via
> the configuration
> option :c:macro:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS`. The configuration
> option :c:macro:`CONFIGURE_RECORD_EXTENSIONS_ENABLED` enables the generation
> of
> thread create, start, restart, delete, switch, begin, exitted and terminate
> -events. Dumps of the event records in a fatal error handler can be enabled
> by
> -the mutually exclusive :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
> +events. The configuration option
> +:c:macro:`CONFIGURE_RECORD_INTERRUPTS_ENABLED` enables the generation of
> +interrupt entry and exit events. Dumps of the event records in a fatal error
> +handler can be enabled by the mutually exclusive
> +:c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
> :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB` configuration options.
>
> Custom events can be recorded for example with the
> @@ -98,64 +101,6 @@ instrumented functions:
> );
> }
>
> -To generate interrupt handler entry/exit events, the following patch can be
> -used:
> -
> -.. code-block:: diff
> -
> -diff --git a/bsps/arm/shared/clock/clock-armv7m.c
> b/bsps/arm/shared/clock/clock-armv7m.c
> -index 255de1ca42..0d37c63ac6 100644
> ---- a/bsps/arm/shared/clock/clock-armv7m.c
> -+++ b/bsps/arm/shared/clock/clock-armv7m.c
> -@@ -29,6 +29,7 @@
> - #include
> -
> - #include
> -+#include
> - #include
> -
> - #ifdef ARM_MULTILIB_ARCH_V7M
> -@@ -45,9 +46,11 @@ static uint32_t _ARMV7M_TC_get_timecount(struct
> timecounter *base)
> -
> - void _ARMV7M_Clock_handler(void)
> - {
> -+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY,
> ARMV7M_VECTOR_SYSTICK);
> - _ARMV7M_Interrupt_service_enter();
> - Clock_isr(NULL);
> - _ARMV7M_Interrupt_service_leave();
> -+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_EXIT,
> ARMV7M_VECTOR_SYSTICK);
> - }
> -
> - static void _ARMV7M_Clock_handler_install(void)
> -diff --git a/bsps/include/bsp/irq-generic.h
> b/bsps/include/bsp/irq-generic.h
> -index 31835d07ba..2ab2f78b65 100644
> ---- a/bsps/include/bsp/irq-generic.h
> -+++ b/bsps/include/bsp/irq-generic.h
> -@@ -30,6 +30,7 @@
> - #include
> -
> - #include
> -+#include
> - #include
> -
> - #ifdef RTEMS_SMP
> -@@ -258,6 +259,7 @@ void
> bsp_interrupt_vector_disable(rtems_vector_number vector);
> - */
> - static inline void bsp_interrupt_handler_dispatch(rtems_vector_number
> vector)
> - {
> -+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, vector);
> - if (bsp_interrupt_is_valid_vector(vector)) {
> -
New RISC-V BSP variant (Kendryte K210)
Hi, I have been working on a basic BSP for the Kendryte K210 RISC-V CPU, and I was wondering if the community members would like me to submit it. The Kendryte K210 is a dual core 64 bit RISC-V processor with a wealth of peripheral I/O, a built-in AI NPU, and 8 Megabytes of on-chip SRAM. I like it because it is one of the lowest cost RISC-V CPUs available, and it appears to run RTEMS well. In addition, my BSP works on the K210 model on the renode.io simulator. I believe it would work on QEMU, but it is very close to the rv64imafdc_medany riscv BSP variant. The changes consist of: - A new riscv/riscv variant and associated build option files - A new DTB header, since the DTB is included in the BSP similar to the polarfire BSP - Some code to detect the frequency in bspstart.c - A new header file for the k210 Because the console uses the same sifive uart as the frdme310arty BSP, I factored that out so the Sifive UART can be used in multiple BSP variants. It is able to use the existing timer and interrupt code. In addition to the renode.io simulator, I have run it on the following boards: - Sipeed MAIX Bit - Sipeed MAIXduino (arduino form factor board with ESP32) - Sipeed Grove AI hat for Raspberry Pi Potential negatives: - I do not have a BSD licensed device tree source, I created the device tree binary from the u-boot distribution. Is it OK to just include the device tree binary (similar to the microblaze)? - The availability of these boards has not been as good for the last year or so, but you can still find them at a relatively low cost. The Sipeed company seems to be focusing on another low cost RISC-V SoC, which is very interesting as well: The Bouffalo Lab BL808 (example here: https://wiki.pine64.org/wiki/Ox64) Is this worth submitting? I don't want to clutter up the tree with devices that may become obsolete - we could focus on the upcoming round of low cost RISC-V SoCs like the BL808. I don't have a specific application I am using it for, but I used it as a very inexpensive way to learn RISC-V on a real board. It may be of some value to integrate additional peripheral support including the AI NPU. If anyone is interested, I can submit the patches or even provide a branch on github. Thanks, Alan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-docs] c-user: Add Local vs Global to Key Concepts Chapter
Add multiple new index entries and cite them where RTEMS_LOCAL and RTEMS_GLOBAL are cited. Closes #4453. --- c-user/key_concepts.rst | 78 - c-user/message/directives.rst | 5 +++ c-user/partition/directives.rst | 5 +++ c-user/semaphore/directives.rst | 5 +++ c-user/task/directives.rst | 5 +++ 5 files changed, 89 insertions(+), 9 deletions(-) diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst index e3f4811..f7f62e3 100644 --- a/c-user/key_concepts.rst +++ b/c-user/key_concepts.rst @@ -82,21 +82,78 @@ name: char buffer[10]; /* name assumed to be 10 characters or less */ char *result; result = rtems_object_get_name( id, sizeof(buffer), buffer ); -printk( "ID=0x%08x name=%s\n", id, ((result) ? result : "no name") ); +printk( "id=0x%08x name=%s\n", id, ((result) ? result : "no name") ); } -.. index:: object ID -.. index:: object ID composition +.. index:: object id +.. index:: object id composition .. index:: rtems_id -Object IDs +Object Ids -- -An object ID is a unique 32-bit unsigned integer value which uniquely -identifies an object instance. Object IDs are passed as arguments to many -directives in RTEMS and RTEMS translates the ID to an internal object pointer. -The efficient manipulation of object IDs is critical to the performance of some -RTEMS services. +an object id is a unique 32-bit unsigned integer value which uniquely +identifies an object instance. object ids are passed as arguments to many +directives in rtems and rtems translates the id to an internal object pointer. +the efficient manipulation of object ids is critical to the performance of some +rtems services. + +.. index:: rtems_extension_ident() +.. index:: rtems_barrier_ident() +.. index:: rtems_port_ident() +.. index:: rtems_message_queue_ident() +.. index:: rtems_partition_ident() +.. index:: rtems_region_ident() +.. index:: rtems_semaphore_ident() +.. index:: rtems_task_ident() +.. index:: rtems_timer_ident() + +There are multiple directives with names of the form +``rtems_@CLASS@_ident`` that take a name as argument and return the associated +id if the name is found. The following is the set of name to id services: +which can look up an object + +* ``rtems_extension_ident()`` +* ``rtems_barrier_ident()`` +* ``rtems_port_ident()`` +* ``rtems_message_queue_ident()`` +* ``rtems_partition_ident()`` +* ``rtems_region_ident()`` +* ``rtems_semaphore_ident()`` +* ``rtems_task_ident()`` +* ``rtems_timer_ident()`` + +Local and Global Scope +-- + +.. index:: uniprocesor +.. index:: multiprocessing +.. index:: distributed multiprocessing +.. index:: symmetric multiprocessing (SMP) +.. index:: local scope +.. index:: global scope +.. index:: RTEMS_GLOBAL +.. index:: RTEMS_LOCAL +.. index:: RTEMS_GLOBAL + +RTEMS supports uniprocessing, distributed multiprocessing, and Symmetric +Multiprocessing (SMP) configurations. A uniprocessor system includes only +a single processor in a single node. Distributed multiprocessor systems +include multiple nodes, each of which is a single processor and is usually +referred to as just multiprocessor mode for historical reasons. SMP +systems consist of multiple processors cores in a single node. + +In distributed multiprocessing configurations, there are multiple nodes in +the system and object instances may be visible on just the creating node +or to all nodes. If visible only to the creating node, this is referred to +as **local scope** and corresponds to the RTEMS_LOCAL attribute setting +which is the default. If RTEMS GLOBAL is specified as part of the object +attributes, then the object instance has **global scope** and the object +id can be used anywhere in the system to identify that object instance. + +In uniprocessing and SMP configurations, there is only one node in +the system and object instances are locally scoped to that node. Any +attempt to create with the RTEMS_GLOBAL attribute is an error. Object ID Format @@ -122,6 +179,9 @@ sixteen bits form an identifier within a particular object type. This identifier, called the object index, ranges in value from 1 to the maximum number of objects configured for this object type. +None of the fields in an object id may be zero except for the special +case of RTEMS_SELF to indicate the currently running thread. + Object ID Description - diff --git a/c-user/message/directives.rst b/c-user/message/directives.rst index 9cb88e2..b71cdc6 100644 --- a/c-user/message/directives.rst +++ b/c-user/message/directives.rst @@ -99,6 +99,11 @@ effect. Default attributes can be selected by using the * the task wait queue discipline used by the message queue: :c:macro:`RTEMS_FIFO` (default) or :c:macro:`RTEMS_PRIORITY`. +.. index:: local scope +.. index:: global scope +.. index:: RTEMS_GLOBAL +.. index:: RTEMS_LOCAL + The message queue has a local or
RTEMS Open Class (virtual) January 23-27, 2023
Hi There will be an RTEMS Open Class held virtually the week of January 23-27. Times each day will be based on the US Central time zone (Chicago). Adjustments may be considered to accommodate the participants. January 23 - Kick Start and Getting Started January 24-27 - Open Class Details and registration forms at http://rtems.com/trainingschedule. If you have questions at all about the class, feel free to email me directly. Thanks. --Joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
On 01.12.22 15:54, Joel Sherrill wrote: Is there anything the BSP has to do to support this? Yes, it should use the generic interrupt controller support (../../objirq). What about the patch (in the docs?) to add records for arm? Is it obsolete? I assume I just haven't noticed a documentation patch for the configure option. See: https://lists.rtems.org/pipermail/devel/2022-December/073904.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
Is there anything the BSP has to do to support this? What about the patch (in the docs?) to add records for arm? Is it obsolete? I assume I just haven't noticed a documentation patch for the configure option. --joel On Thu, Dec 1, 2022 at 6:11 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > This enables the tracing of interrupt entry/exit events through an > application configuration option. The interrupt processing can be > viewed with Trace Compass. > > Sebastian Huber (3): > bsps/irq: Rename handler in dispatch table > bsps/irq: Add bsp_interrupt_get_dispatch_table_slot() > config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED > > bsps/include/bsp/irq-generic.h| 79 --- > bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 +- > bsps/riscv/riscv/include/tm27.h | 4 +- > bsps/shared/irq/irq-entry-remove.c| 6 +- > bsps/shared/irq/irq-generic.c | 41 > bsps/shared/irq/irq-handler-iterate.c | 4 +- > bsps/shared/irq/irq-record.c | 97 +++ > cpukit/doxygen/appl-config.h | 23 + > cpukit/include/rtems/confdefs/extensions.h| 8 ++ > cpukit/include/rtems/record.h | 2 + > spec/build/bsps/objirq.yml| 1 + > spec/build/bsps/powerpc/ss555/bspss555.yml| 1 + > .../validation/tc-bsp-interrupt-spurious.c| 4 +- > testsuites/validation/tc-intr-entry-install.c | 4 +- > testsuites/validation/tc-intr-entry-remove.c | 8 +- > .../validation/tc-intr-handler-iterate.c | 4 +- > 16 files changed, 218 insertions(+), 70 deletions(-) > create mode 100644 bsps/shared/irq/irq-record.c > > -- > 2.35.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Document CONFIGURE_RECORD_INTERRUPTS_ENABLED
Close #4769.
---
c-user/config/event-record.rst | 43 +-
user/tracing/eventrecording.rst | 65 +++--
2 files changed, 47 insertions(+), 61 deletions(-)
diff --git a/c-user/config/event-record.rst b/c-user/config/event-record.rst
index 31a4fa9..f1e7969 100644
--- a/c-user/config/event-record.rst
+++ b/c-user/config/event-record.rst
@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
-.. Copyright (C) 2019, 2021 embedded brains GmbH
(http://www.embedded-brains.de)
+.. Copyright (C) 2019, 2022 embedded brains GmbH
(http://www.embedded-brains.de)
.. This file is part of the RTEMS quality process and was automatically
.. generated. If you find something that needs to be fixed or
@@ -150,6 +150,47 @@ in a fatal error extension (see :ref:`Terminate`).
The zlib compression needs about 512KiB of RAM. This extension can be used
to produce crash dumps.
+.. Generated from spec:/acfg/if/record-interrupts-enabled
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: CONFIGURE_RECORD_INTERRUPTS_ENABLED
+
+.. _CONFIGURE_RECORD_INTERRUPTS_ENABLED:
+
+CONFIGURE_RECORD_INTERRUPTS_ENABLED
+---
+
+.. rubric:: CONSTANT:
+
+``CONFIGURE_RECORD_INTERRUPTS_ENABLED``
+
+.. rubric:: OPTION TYPE:
+
+This configuration option is a boolean feature define.
+
+.. rubric:: DEFAULT CONFIGURATION:
+
+If this configuration option is undefined, then the described feature is not
+enabled.
+
+.. rubric:: DESCRIPTION:
+
+In case
+
+* this configuration option is defined
+
+* and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS` is properly defined,
+
+then the interrupt event recording is enabled.
+
+.. rubric:: NOTES:
+
+The interrupt event recording generates interrupt entry and exit events when
+interrupt entries are dispatched.
+
.. Generated from spec:/acfg/if/record-per-processor-items
.. raw:: latex
diff --git a/user/tracing/eventrecording.rst b/user/tracing/eventrecording.rst
index 7130658..b5561cc 100644
--- a/user/tracing/eventrecording.rst
+++ b/user/tracing/eventrecording.rst
@@ -48,8 +48,11 @@ The application enables the event recording support via the
configuration
option :c:macro:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS`. The configuration
option :c:macro:`CONFIGURE_RECORD_EXTENSIONS_ENABLED` enables the generation of
thread create, start, restart, delete, switch, begin, exitted and terminate
-events. Dumps of the event records in a fatal error handler can be enabled by
-the mutually exclusive :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
+events. The configuration option
+:c:macro:`CONFIGURE_RECORD_INTERRUPTS_ENABLED` enables the generation of
+interrupt entry and exit events. Dumps of the event records in a fatal error
+handler can be enabled by the mutually exclusive
+:c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
:c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB` configuration options.
Custom events can be recorded for example with the
@@ -98,64 +101,6 @@ instrumented functions:
);
}
-To generate interrupt handler entry/exit events, the following patch can be
-used:
-
-.. code-block:: diff
-
-diff --git a/bsps/arm/shared/clock/clock-armv7m.c
b/bsps/arm/shared/clock/clock-armv7m.c
-index 255de1ca42..0d37c63ac6 100644
---- a/bsps/arm/shared/clock/clock-armv7m.c
-+++ b/bsps/arm/shared/clock/clock-armv7m.c
-@@ -29,6 +29,7 @@
- #include
-
- #include
-+#include
- #include
-
- #ifdef ARM_MULTILIB_ARCH_V7M
-@@ -45,9 +46,11 @@ static uint32_t _ARMV7M_TC_get_timecount(struct
timecounter *base)
-
- void _ARMV7M_Clock_handler(void)
- {
-+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY,
ARMV7M_VECTOR_SYSTICK);
- _ARMV7M_Interrupt_service_enter();
- Clock_isr(NULL);
- _ARMV7M_Interrupt_service_leave();
-+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_EXIT,
ARMV7M_VECTOR_SYSTICK);
- }
-
- static void _ARMV7M_Clock_handler_install(void)
-diff --git a/bsps/include/bsp/irq-generic.h
b/bsps/include/bsp/irq-generic.h
-index 31835d07ba..2ab2f78b65 100644
---- a/bsps/include/bsp/irq-generic.h
-+++ b/bsps/include/bsp/irq-generic.h
-@@ -30,6 +30,7 @@
- #include
-
- #include
-+#include
- #include
-
- #ifdef RTEMS_SMP
-@@ -258,6 +259,7 @@ void bsp_interrupt_vector_disable(rtems_vector_number
vector);
- */
- static inline void bsp_interrupt_handler_dispatch(rtems_vector_number
vector)
- {
-+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, vector);
- if (bsp_interrupt_is_valid_vector(vector)) {
- const bsp_interrupt_handler_entry *e =
- _interrupt_handler_table [bsp_interrupt_handler_index(vector)];
-@@ -276,6 +278,7 @@ static inline void
bsp_interrupt_handler_dispatch(rtems_vector_number vector)
- } else {
- bsp_interrupt_handler_default(vector);
- }
-+ rtems_record_produce(RTEMS_RECORD_INTERRUPT_EXIT, vector);
[PATCH 2/3] bsps/irq: Add bsp_interrupt_get_dispatch_table_slot()
Update #4769.
---
bsps/include/bsp/irq-generic.h| 11 +++
bsps/shared/irq/irq-entry-remove.c| 2 +-
bsps/shared/irq/irq-generic.c | 19 +--
bsps/shared/irq/irq-handler-iterate.c | 2 +-
4 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 4a3dd75e7d..1ff84ee7cd 100644
--- a/bsps/include/bsp/irq-generic.h
+++ b/bsps/include/bsp/irq-generic.h
@@ -663,6 +663,17 @@ static inline bool bsp_interrupt_is_initialized( void )
return bsp_interrupt_is_handler_unique( BSP_INTERRUPT_DISPATCH_TABLE_SIZE );
}
+/**
+ * @brief Gets a reference to the interrupt handler table slot associated with
+ * the index.
+ *
+ * @return Returns a reference to the interrupt handler table slot associated
+ * with the index.
+ */
+rtems_interrupt_entry **bsp_interrupt_get_dispatch_table_slot(
+ rtems_vector_number index
+);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
diff --git a/bsps/shared/irq/irq-entry-remove.c
b/bsps/shared/irq/irq-entry-remove.c
index e970b80455..6b43134a0c 100644
--- a/bsps/shared/irq/irq-entry-remove.c
+++ b/bsps/shared/irq/irq-entry-remove.c
@@ -47,7 +47,7 @@ void bsp_interrupt_entry_remove(
rtems_interrupt_entry *entry_next;
index = bsp_interrupt_dispatch_index( vector );
- first = bsp_interrupt_dispatch_table[ index ];
+ first = *bsp_interrupt_get_dispatch_table_slot( index );
entry_next = entry->next;
if ( entry == first && entry_next == NULL ) {
diff --git a/bsps/shared/irq/irq-generic.c b/bsps/shared/irq/irq-generic.c
index ffd820730e..e899731a54 100644
--- a/bsps/shared/irq/irq-generic.c
+++ b/bsps/shared/irq/irq-generic.c
@@ -49,6 +49,13 @@
rtems_interrupt_entry *
bsp_interrupt_dispatch_table[ BSP_INTERRUPT_DISPATCH_TABLE_SIZE ];
+RTEMS_WEAK rtems_interrupt_entry **bsp_interrupt_get_dispatch_table_slot(
+ rtems_vector_number index
+)
+{
+ return _interrupt_dispatch_table[ index ];
+}
+
/* The last entry indicates if everything is initialized */
uint8_t bsp_interrupt_handler_unique_table
[ ( BSP_INTERRUPT_DISPATCH_TABLE_SIZE + 7 + 1 ) / 8 ];
@@ -91,9 +98,9 @@ void bsp_interrupt_spurious( rtems_vector_number vector )
* In order to get the last written pointer value to the first entry, we have
* to carry out an atomic read-modify-write operation.
*/
- ptr = (Atomic_Uintptr *) _interrupt_dispatch_table[
+ ptr = (Atomic_Uintptr *) bsp_interrupt_get_dispatch_table_slot(
bsp_interrupt_dispatch_index( vector )
- ];
+ );
first = (rtems_interrupt_entry *)
_Atomic_Fetch_add_uintptr( ptr, 0, ATOMIC_ORDER_ACQUIRE );
@@ -143,8 +150,8 @@ rtems_interrupt_entry *bsp_interrupt_entry_find(
bsp_interrupt_assert( bsp_interrupt_is_valid_vector( vector ) );
index = bsp_interrupt_dispatch_index( vector );
- *previous_next = _interrupt_dispatch_table[ index ];
- entry = bsp_interrupt_dispatch_table[ index ];
+ *previous_next = bsp_interrupt_get_dispatch_table_slot( index );
+ entry = **previous_next;
while ( entry != NULL ) {
if ( entry->handler == routine && entry->arg == arg ) {
@@ -187,7 +194,7 @@ static rtems_status_code bsp_interrupt_entry_install_first(
bsp_interrupt_dispatch_index_table[ vector ] = index;
#endif
bsp_interrupt_entry_store_release(
-_interrupt_dispatch_table[ index ],
+bsp_interrupt_get_dispatch_table_slot( index ),
entry
);
@@ -220,7 +227,7 @@ static rtems_status_code bsp_interrupt_entry_install(
}
index = bsp_interrupt_dispatch_index( vector );
- first = bsp_interrupt_dispatch_table[ index ];
+ first = *bsp_interrupt_get_dispatch_table_slot( index );
if ( first == NULL ) {
return bsp_interrupt_entry_install_first( vector, options, entry );
diff --git a/bsps/shared/irq/irq-handler-iterate.c
b/bsps/shared/irq/irq-handler-iterate.c
index 0aa890e6fd..7437e8a43e 100644
--- a/bsps/shared/irq/irq-handler-iterate.c
+++ b/bsps/shared/irq/irq-handler-iterate.c
@@ -57,9 +57,9 @@ rtems_status_code rtems_interrupt_handler_iterate(
}
index = bsp_interrupt_dispatch_index( vector );
+ entry = *bsp_interrupt_get_dispatch_table_slot( index );
options = bsp_interrupt_is_handler_unique( index ) ?
RTEMS_INTERRUPT_UNIQUE : RTEMS_INTERRUPT_SHARED;
- entry = bsp_interrupt_dispatch_table[ index ];
while ( entry != NULL ) {
( *routine )( arg, entry->info, options, entry->handler, entry->arg );
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] bsps/irq: Rename handler in dispatch table
The name handler table was a bit misleading after the last rework.
Rename it in distach table. Update the documentation accordingly.
Update #4769.
---
bsps/include/bsp/irq-generic.h| 68 +--
bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 +-
bsps/riscv/riscv/include/tm27.h | 4 +-
bsps/shared/irq/irq-entry-remove.c| 6 +-
bsps/shared/irq/irq-generic.c | 32 -
bsps/shared/irq/irq-handler-iterate.c | 4 +-
.../validation/tc-bsp-interrupt-spurious.c| 4 +-
testsuites/validation/tc-intr-entry-install.c | 4 +-
testsuites/validation/tc-intr-entry-remove.c | 8 +--
.../validation/tc-intr-handler-iterate.c | 4 +-
10 files changed, 67 insertions(+), 69 deletions(-)
diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index f605da9803..4a3dd75e7d 100644
--- a/bsps/include/bsp/irq-generic.h
+++ b/bsps/include/bsp/irq-generic.h
@@ -62,12 +62,12 @@ extern "C" {
#error "BSP_INTERRUPT_VECTOR_COUNT shall be defined"
#endif
-#if defined(BSP_INTERRUPT_USE_INDEX_TABLE) &&
!defined(BSP_INTERRUPT_HANDLER_TABLE_SIZE)
- #error "if you define BSP_INTERRUPT_USE_INDEX_TABLE, you have to define
BSP_INTERRUPT_HANDLER_TABLE_SIZE etc. as well"
+#if defined(BSP_INTERRUPT_USE_INDEX_TABLE) &&
!defined(BSP_INTERRUPT_DISPATCH_TABLE_SIZE)
+ #error "if you define BSP_INTERRUPT_USE_INDEX_TABLE, you have to define
BSP_INTERRUPT_DISPATCH_TABLE_SIZE etc. as well"
#endif
-#ifndef BSP_INTERRUPT_HANDLER_TABLE_SIZE
- #define BSP_INTERRUPT_HANDLER_TABLE_SIZE BSP_INTERRUPT_VECTOR_COUNT
+#ifndef BSP_INTERRUPT_DISPATCH_TABLE_SIZE
+ #define BSP_INTERRUPT_DISPATCH_TABLE_SIZE BSP_INTERRUPT_VECTOR_COUNT
#endif
#define bsp_interrupt_assert(e) _Assert(e)
@@ -76,25 +76,25 @@ extern "C" {
* @brief Each member of this table references the first installed entry at the
* corresponding interrupt vector or is NULL.
*/
-extern rtems_interrupt_entry *bsp_interrupt_handler_table[];
+extern rtems_interrupt_entry *bsp_interrupt_dispatch_table[];
#ifdef BSP_INTERRUPT_USE_INDEX_TABLE
- #if BSP_INTERRUPT_HANDLER_TABLE_SIZE < 0x100
-typedef uint8_t bsp_interrupt_handler_index_type;
- #elif BSP_INTERRUPT_HANDLER_TABLE_SIZE < 0x1
-typedef uint16_t bsp_interrupt_handler_index_type;
+ #if BSP_INTERRUPT_DISPATCH_TABLE_SIZE < 0x100
+typedef uint8_t bsp_interrupt_dispatch_index_type;
+ #elif BSP_INTERRUPT_DISPATCH_TABLE_SIZE < 0x1
+typedef uint16_t bsp_interrupt_dispatch_index_type;
#else
-typedef uint32_t bsp_interrupt_handler_index_type;
+typedef uint32_t bsp_interrupt_dispatch_index_type;
#endif
- extern bsp_interrupt_handler_index_type bsp_interrupt_handler_index_table [];
+ extern bsp_interrupt_dispatch_index_type bsp_interrupt_dispatch_index_table
[];
#endif
-static inline rtems_vector_number bsp_interrupt_handler_index(
+static inline rtems_vector_number bsp_interrupt_dispatch_index(
rtems_vector_number vector
)
{
#ifdef BSP_INTERRUPT_USE_INDEX_TABLE
-return bsp_interrupt_handler_index_table [vector];
+return bsp_interrupt_dispatch_index_table [vector];
#else
return vector;
#endif
@@ -109,23 +109,21 @@ static inline rtems_vector_number
bsp_interrupt_handler_index(
*
* The BSP interrupt support manages a sequence of interrupt vector numbers
* greater than or equal to zero and less than @ref BSP_INTERRUPT_VECTOR_COUNT
- * It provides methods to
- * @ref bsp_interrupt_handler_install() "install",
- * @ref bsp_interrupt_handler_remove() "remove" and
- * @ref bsp_interrupt_handler_dispatch() "dispatch" interrupt handlers for each
+ * It provides methods to install, remove, and @ref
+ * bsp_interrupt_handler_dispatch() "dispatch" interrupt entries for each
* vector number. It implements parts of the RTEMS interrupt manager.
*
- * The entry points to a list of interrupt handlers are stored in a table
- * (= handler table).
+ * The entry points to a list of interrupt entries are stored in a table
+ * (= dispatch table).
*
* You have to configure the BSP interrupt support in the file
* for each BSP. For a minimum configuration you have to provide
* @ref BSP_INTERRUPT_VECTOR_COUNT.
*
* For boards with small memory requirements you can define
- * @ref BSP_INTERRUPT_USE_INDEX_TABLE. With an enabled index table the handler
- * table will be accessed via a small index table. You can define the size of
- * the handler table with @ref BSP_INTERRUPT_HANDLER_TABLE_SIZE.
+ * @ref BSP_INTERRUPT_USE_INDEX_TABLE. With an enabled index table the
+ * dispatch table will be accessed via a small index table. You can define the
+ * size of the dispatch table with @ref BSP_INTERRUPT_DISPATCH_TABLE_SIZE.
*
* You have to provide some special routines in your BSP (follow the links for
* the details):
@@ -180,7 +178,7 @@ void bsp_interrupt_handler_default(rtems_vector_number
vector);
* @brief Initialize BSP interrupt
[PATCH 0/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
This enables the tracing of interrupt entry/exit events through an application configuration option. The interrupt processing can be viewed with Trace Compass. Sebastian Huber (3): bsps/irq: Rename handler in dispatch table bsps/irq: Add bsp_interrupt_get_dispatch_table_slot() config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED bsps/include/bsp/irq-generic.h| 79 --- bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 +- bsps/riscv/riscv/include/tm27.h | 4 +- bsps/shared/irq/irq-entry-remove.c| 6 +- bsps/shared/irq/irq-generic.c | 41 bsps/shared/irq/irq-handler-iterate.c | 4 +- bsps/shared/irq/irq-record.c | 97 +++ cpukit/doxygen/appl-config.h | 23 + cpukit/include/rtems/confdefs/extensions.h| 8 ++ cpukit/include/rtems/record.h | 2 + spec/build/bsps/objirq.yml| 1 + spec/build/bsps/powerpc/ss555/bspss555.yml| 1 + .../validation/tc-bsp-interrupt-spurious.c| 4 +- testsuites/validation/tc-intr-entry-install.c | 4 +- testsuites/validation/tc-intr-entry-remove.c | 8 +- .../validation/tc-intr-handler-iterate.c | 4 +- 16 files changed, 218 insertions(+), 70 deletions(-) create mode 100644 bsps/shared/irq/irq-record.c -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
Update #4769.
---
bsps/shared/irq/irq-record.c | 97 ++
cpukit/doxygen/appl-config.h | 23 +
cpukit/include/rtems/confdefs/extensions.h | 8 ++
cpukit/include/rtems/record.h | 2 +
spec/build/bsps/objirq.yml | 1 +
spec/build/bsps/powerpc/ss555/bspss555.yml | 1 +
6 files changed, 132 insertions(+)
create mode 100644 bsps/shared/irq/irq-record.c
diff --git a/bsps/shared/irq/irq-record.c b/bsps/shared/irq/irq-record.c
new file mode 100644
index 00..9f0a008d84
--- /dev/null
+++ b/bsps/shared/irq/irq-record.c
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup bsp_interrupt
+ *
+ * @brief This source file contains the implementation of the interrupt event
+ * recording support.
+ */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+
+#include
+
+/* The regular interrupt entries are registered in this table */
+static rtems_interrupt_entry *
+_Record_Interrupt_dispatch_table[ BSP_INTERRUPT_DISPATCH_TABLE_SIZE ];
+
+/*
+ * Provide one interrupt entry for the _Record_Interrupt_handler() interrupt
+ * dispatch wrapper for each interrupt vector.
+ */
+static rtems_interrupt_entry
+_Record_Interrupt_entry_table[ BSP_INTERRUPT_DISPATCH_TABLE_SIZE ];
+
+rtems_interrupt_entry **bsp_interrupt_get_dispatch_table_slot(
+ rtems_vector_number index
+)
+{
+ return &_Record_Interrupt_dispatch_table[ index ];
+}
+
+static void _Record_Interrupt_handler( void *arg )
+{
+ uintptr_t vector;
+ rtems_interrupt_entry *entry;
+
+ vector = (uintptr_t) arg;
+ rtems_record_produce( RTEMS_RECORD_INTERRUPT_ENTRY, vector );
+
+ entry = bsp_interrupt_entry_load_acquire(
+&_Record_Interrupt_dispatch_table[ vector ]
+ );
+
+ if ( RTEMS_PREDICT_TRUE( entry != NULL ) ) {
+bsp_interrupt_dispatch_entries( entry );
+ } else {
+#if defined(RTEMS_SMP)
+bsp_interrupt_spurious( vector );
+#else
+bsp_interrupt_handler_default( vector );
+#endif
+ }
+
+ rtems_record_produce( RTEMS_RECORD_INTERRUPT_EXIT, vector );
+}
+
+void _Record_Interrupt_initialize( void )
+{
+ uintptr_t i;
+
+ /*
+ * Let each interrupt dispatch table slot reference the
+ * _Record_Interrupt_handler() interrupt dispatch wrapper.
+ */
+ for ( i = 0; i < BSP_INTERRUPT_DISPATCH_TABLE_SIZE; ++i ) {
+_Record_Interrupt_entry_table[ i ].handler = _Record_Interrupt_handler;
+_Record_Interrupt_entry_table[ i ].arg = (void *) i;
+bsp_interrupt_dispatch_table[ i ] = &_Record_Interrupt_entry_table[ i ];
+ }
+}
diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 88cd03d328..964f8d0616 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -1911,6 +1911,29 @@
*/
#define CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB
+/* Generated from spec:/acfg/if/record-interrupts-enabled */
+
+/**
+ * @brief This configuration option is a boolean feature define.
+ *
+ * In case
+ *
+ * * this configuration option is defined
+ *
+ * * and #CONFIGURE_RECORD_PER_PROCESSOR_ITEMS is properly defined,
+ *
+ * then the interrupt event recording is enabled.
+ *
+ * @par Default Configuration
+ * If this configuration option is undefined, then the described feature is not
+ * enabled.
+ *
+ * @par Notes
+ * The interrupt event recording generates interrupt entry and exit events when
+ * interrupt entries are dispatched.
+ */
+#define CONFIGURE_RECORD_INTERRUPTS_ENABLED
+
/* Generated from spec:/acfg/if/record-per-processor-items */
/**
diff --git a/cpukit/include/rtems/confdefs/extensions.h
b/cpukit/include/rtems/confdefs/extensions.h
index
