Re: New API directives to enable/disable interrupt vectors
On 18/06/2021 03:30, Chris Johns wrote: The list does not capture things like rtems_interrupt_mask which is a typedef. The rtems_interrupt_mask is a constant object: /** * @ingroup RTEMSAPIClassicModes * * @brief This task mode constant has the same value as #RTEMS_INTERRUPT_MASK. * * @par Notes * This task mode constant is used by bindings from languages other than C and * C++. */ extern const uint32_t rtems_interrupt_mask; My concern is: rtems_interrupt_disable rtems_interrupt_enable The two macros above are a legacy interface available only in uniprocessor configurations. rtems_interrupt_local_disable rtems_interrupt_local_enable and then we add: rtems_interrupt_vector_disable rtems_interrupt_vector_enable So basically we have to compare these two variants. I think the names which include "local" and "vector" are clear enough from my point of view. The primary use case for the vector enable/disable is probably test code. How do each of these enable/disable pairs interact with the other parts of the API? This also seems to pull back to Sebastian's initial comment about the enable/disable being occupied and I wonder if that concern highlights the need for some cleaning in the API? It is does it may take a release or 2 to migrate users but it may be worth it in the long run if the API is made clearer. I will send a patch set in the next days with a proposal for some new directives. I would not change what we have. -- 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: New API directives to enable/disable interrupt vectors
On 18/6/21 1:28 am, Gedare Bloom wrote:
> On Wed, Jun 16, 2021 at 11:40 PM Sebastian Huber
> wrote:
>>
>> On 16/06/2021 20:36, Gedare Bloom wrote:
>>> Looks like the existing irq-extension.h uses 'vector', so
>>> rtems_interrupt_disable_vector() is a possibility, or else
>>> rtems_interrupt_controller_disable_vector() is more wordy but if we
>>> want to treat 'interrupt controller' as its own category of API
>>> separate from 'interrupt'.
>>
>> Yes, mixing "vector" into the name a good idea. What about
>> rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()?
>>
>> I am not that fond of using "interrupt controller" since I don't want to
>> change the existing API and it would result in very long directive names.
>>
> I'm fine with the rtems_interrupt_vector_* to distinguish between the
> score/cpu level support, and the bsp/irq controllers. We already use
> this for example as "bsp_interrupt_vector_enable()". I think it will
> be great to lift this "bsp" interface up to the "rtems" level.
I have no objection to any of this but it raised my interest in what is the
whole rtems_interrupt_* API and how consistent it is ...
I have managed to filter the cpukit headers [1] to get:
rtems_interrupt_catch
rtems_interrupt_cause
rtems_interrupt_clear
rtems_interrupt_disable
rtems_interrupt_enable
rtems_interrupt_flash
rtems_interrupt_is_in_progress
rtems_interrupt_level_body
rtems_interrupt_local_disable
rtems_interrupt_local_enable
rtems_interrupt_handler_install
rtems_interrupt_handler_iterate
rtems_interrupt_handler_remove
rtems_interrupt_get_affinity
rtems_interrupt_set_affinity
rtems_interrupt_lock_acquire
rtems_interrupt_lock_acquire_isr
rtems_interrupt_lock_destroy
rtems_interrupt_lock_initialize
rtems_interrupt_lock_interrupt_disable
rtems_interrupt_lock_release
rtems_interrupt_lock_release_isr
rtems_interrupt_server_action_prepend
rtems_interrupt_server_create
rtems_interrupt_server_delete
rtems_interrupt_server_entry_destroy
rtems_interrupt_server_entry_initialize
rtems_interrupt_server_entry_move
rtems_interrupt_server_entry_submit
rtems_interrupt_server_handler_install
rtems_interrupt_server_handler_iterate
rtems_interrupt_server_handler_remove
rtems_interrupt_server_initialize
rtems_interrupt_server_move
rtems_interrupt_server_request_destroy
rtems_interrupt_server_request_initialize
rtems_interrupt_server_request_set_vector
rtems_interrupt_server_request_submit
rtems_interrupt_server_resume
rtems_interrupt_server_set_affinity
rtems_interrupt_server_suspend
The list does not capture things like rtems_interrupt_mask which is a typedef.
My concern is:
rtems_interrupt_disable
rtems_interrupt_enable
rtems_interrupt_local_disable
rtems_interrupt_local_enable
and then we add:
rtems_interrupt_vector_disable
rtems_interrupt_vector_enable
How do each of these enable/disable pairs interact with the other parts of the
API?
This also seems to pull back to Sebastian's initial comment about the
enable/disable being occupied and I wonder if that concern highlights the need
for some cleaning in the API? It is does it may take a release or 2 to migrate
users but it may be worth it in the long run if the API is made clearer.
I am not across enough of the detail to comment specifically about this and I am
happy to see what others think and follow their lead.
Chris
[1] egrep -r 'rtems_interrupt_.*\(' cpukit/include | sed -e 's/.*
\(rtems_interrupt_.*\).*/\1/' | sed -e 's/(.*//' | grep '^rtems' | sort | uniq
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] covoar/CoverageMapBase: Use reference for iteration in validAddress
Ok
On 18/6/21 7:13 am, Alex White wrote:
> ---
> tester/covoar/CoverageMapBase.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tester/covoar/CoverageMapBase.cc
> b/tester/covoar/CoverageMapBase.cc
> index 6ca5cf7..f0b5890 100644
> --- a/tester/covoar/CoverageMapBase.cc
> +++ b/tester/covoar/CoverageMapBase.cc
> @@ -121,7 +121,7 @@ namespace Coverage {
>
>bool CoverageMapBase::validAddress( const uint32_t address ) const
>{
> -for ( auto r : Ranges )
> +for ( auto& r : Ranges )
>if (r.inside( address ))
> return true;
> return false;
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] covoar/CoverageMapBase: Use reference for iteration in validAddress
---
tester/covoar/CoverageMapBase.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tester/covoar/CoverageMapBase.cc b/tester/covoar/CoverageMapBase.cc
index 6ca5cf7..f0b5890 100644
--- a/tester/covoar/CoverageMapBase.cc
+++ b/tester/covoar/CoverageMapBase.cc
@@ -121,7 +121,7 @@ namespace Coverage {
bool CoverageMapBase::validAddress( const uint32_t address ) const
{
-for ( auto r : Ranges )
+for ( auto& r : Ranges )
if (r.inside( address ))
return true;
return false;
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libc: Added sig2str/str2sig prototypes
> On 17-Jun-2021, at 1:14 PM, Matthew Joyce wrote: > > Hi Eshan, > > Thanks very much for this...It's really helpful! > > Question on workflow: > So for this example, I just apply the patch to RSB. Do I understand correctly > that we need to rebuild the tool chain each and every time I make any > change? Yupp that’s one of the reasons it takes time to work on a patch. > (Step 7 in > Vaibhav's Blog) This didn't compile, apparently because of the double > restricts. Do I need > to make a change, rebuild the tool chain (around 1.33 hours), and test > again? Hopefully > there are shortcuts around that! You can check for symbols that’s the only way we had No shortcuts If it builds for newlib you have to build the complete tool chain to see it doesn’t break the RSB. Also you have to build the complete rtems Kernel That’s the only way you can build the test and run on the kernel Thanks - Eshan > > Thanks again for your help. > > Sincerely, > > Matt > >> On Wed, Jun 16, 2021 at 10:40 PM Eshan Dhawan >> wrote: >> >> Hi Matt, >> Since you are making changes only to a header file you don’t need to run >> autoreconf. >> You can directly apply the patch to RSB and it should work >> You need to run autoreconf when u make changes in makefile >> That is when u add a .c file >> On 17-Jun-2021, at 1:53 AM, Matt Joyce wrote: >>> >>> ***As Requested: For Review Only. Does Not Compile*** >>> >>> Added definition of SIG2STR_MAX and function prototypes for sig2str >>> and str2sig in sys/signal.h in order to improve POSIX compliance. >>> --- >>> newlib/libc/include/sys/signal.h | 12 >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/newlib/libc/include/sys/signal.h >>> b/newlib/libc/include/sys/signal.h >>> index 45cc0366c..fd2b3c672 100644 >>> --- a/newlib/libc/include/sys/signal.h >>> +++ b/newlib/libc/include/sys/signal.h >>> @@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval); >>> >>> #endif /* __POSIX_VISIBLE >= 199309 */ >>> >>> +#if __GNU_VISIBLE >>> + >>> +/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX, p. 332 adds sig2str() >>> + and str2sig(). */ >>> + >>> +#define SIG2STR_MAX 4294967295 >>> + >>> +int sig2str(int, char *); >>> +int str2sig(const char *restrict, int *restrict); >>> + >>> +#endif /* __GNU_VISIBLE */ >>> + >>> #if defined(___AM29K__) >>> /* These all need to be defined for ANSI C, but I don't think they are >>> meaningful. */ >>> -- >>> 2.31.1 >>> >>> ___ >>> 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: New API directives to enable/disable interrupt vectors
On Wed, Jun 16, 2021 at 11:40 PM Sebastian Huber wrote: > > On 16/06/2021 20:36, Gedare Bloom wrote: > > Looks like the existing irq-extension.h uses 'vector', so > > rtems_interrupt_disable_vector() is a possibility, or else > > rtems_interrupt_controller_disable_vector() is more wordy but if we > > want to treat 'interrupt controller' as its own category of API > > separate from 'interrupt'. > > Yes, mixing "vector" into the name a good idea. What about > rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()? > > I am not that fond of using "interrupt controller" since I don't want to > change the existing API and it would result in very long directive names. > I'm fine with the rtems_interrupt_vector_* to distinguish between the score/cpu level support, and the bsp/irq controllers. We already use this for example as "bsp_interrupt_vector_enable()". I think it will be great to lift this "bsp" interface up to the "rtems" level. > -- > 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: New API directives to enable/disable interrupt vectors
On Thu, Jun 17, 2021 at 12:40 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 16/06/2021 20:36, Gedare Bloom wrote: > > Looks like the existing irq-extension.h uses 'vector', so > > rtems_interrupt_disable_vector() is a possibility, or else > > rtems_interrupt_controller_disable_vector() is more wordy but if we > > want to treat 'interrupt controller' as its own category of API > > separate from 'interrupt'. > > Yes, mixing "vector" into the name a good idea. What about > rtems_interrupt_vector_enable() and rtems_interrupt_vector_disable()? > I like this. Interrupt vector refers to the source not the hardware being manipulated. > > I am not that fond of using "interrupt controller" since I don't want to > change the existing API and it would result in very long directive names. > I know they are usually called interrupt controllers but you are right, it is longer and implies a technology. --joel > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/irq: Change license to BSD-2-Clause
ok On Thu, Jun 17, 2021 at 8:14 AM Sebastian Huber wrote: > > Change license to BSD-2-Clause according to file history and > re-licensing agreement. > > Update #3053. > --- > bsps/include/bsp/irq-default.h| 6 ++-- > bsps/include/bsp/irq-generic.h| 42 ++- > bsps/include/bsp/irq-info.h | 35 +++--- > bsps/shared/irq/irq-default-handler.c | 40 +++-- > bsps/shared/irq/irq-default.c | 12 +--- > bsps/shared/irq/irq-generic.c | 36 +++ > bsps/shared/irq/irq-info.c| 35 +++--- > bsps/shared/irq/irq-legacy.c | 35 +++--- > bsps/shared/irq/irq-lock.c| 36 +++ > bsps/shared/irq/irq-server.c | 27 ++--- > bsps/shared/irq/irq-shell.c | 35 +++--- > 11 files changed, 242 insertions(+), 97 deletions(-) > > diff --git a/bsps/include/bsp/irq-default.h b/bsps/include/bsp/irq-default.h > index a94e045e0d..4d7beb189b 100644 > --- a/bsps/include/bsp/irq-default.h > +++ b/bsps/include/bsp/irq-default.h > @@ -1,3 +1,5 @@ > +/* SPDX-License-Identifier: BSD-2-Clause */ > + > /** > * @file > * > @@ -5,9 +7,7 @@ > */ > > /* > - * SPDX-License-Identifier: BSD-2-Clause > - * > - * Copyright (C) 2019 embedded brains GmbH > + * Copyright (C) 2019 embedded brains GmbH (http://www.embedded-brains.de) > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h > index 31835d07ba..4135aa518c 100644 > --- a/bsps/include/bsp/irq-generic.h > +++ b/bsps/include/bsp/irq-generic.h > @@ -1,27 +1,43 @@ > +/* SPDX-License-Identifier: BSD-2-Clause */ > + > /** > * @file > * > * @ingroup bsp_interrupt > * > - * @brief Generic BSP interrupt support API. > + * @brief This header file provides interfaces of the generic interrupt > + * controller support. > */ > > /* > - * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette. > - * > - * Copyright (c) 2008, 2017 embedded brains GmbH. > + * Copyright (C) 2016 Chris Johns > * > - * embedded brains GmbH > - * Dornierstr. 4 > - * 82178 Puchheim > - * Germany > - * > + * Copyright (C) 2008, 2017 embedded brains GmbH > (http://www.embedded-brains.de) > * > - * Copyright (c) 2016 Chris Johns > + * 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. > * > - * The license and distribution terms for this file may be > - * found in the file LICENSE in this distribution or at > - * http://www.rtems.org/license/LICENSE. > + * 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. > + */ > + > +/* > + * The API is based on concepts of Pavel Pisa, Till Straumann and Eric > Valette. > */ > > #ifndef LIBBSP_SHARED_IRQ_GENERIC_H > diff --git a/bsps/include/bsp/irq-info.h b/bsps/include/bsp/irq-info.h > index ea6d629e76..25f05a9f69 100644 > --- a/bsps/include/bsp/irq-info.h > +++ b/bsps/include/bsp/irq-info.h > @@ -1,22 +1,37 @@ > +/* SPDX-License-Identifier: BSD-2-Clause */ > + > /** > * @file > * > * @ingroup bsp_interrupt > * > - * @brief Generic BSP interrupt information API. > + * @brief This header file provides interfaces of the generic interrupt > + * controller support for the RTEMS Shell. > */ > > /* > - * Copyright (c) 2008, 2009 > - * embedded brains GmbH > - * Obere Lagerstr. 30 > - * D-82178 Puchheim > - * Germany > - * > + * Copyright (C) 2008, 2009 embedded brains GmbH > (http://www.embedded-brains.de) > + * > + * Redistribution and use in source and binary forms, with or without > + *
[PATCH] bsps/irq: Change license to BSD-2-Clause
Change license to BSD-2-Clause according to file history and re-licensing agreement. Update #3053. --- bsps/include/bsp/irq-default.h| 6 ++-- bsps/include/bsp/irq-generic.h| 42 ++- bsps/include/bsp/irq-info.h | 35 +++--- bsps/shared/irq/irq-default-handler.c | 40 +++-- bsps/shared/irq/irq-default.c | 12 +--- bsps/shared/irq/irq-generic.c | 36 +++ bsps/shared/irq/irq-info.c| 35 +++--- bsps/shared/irq/irq-legacy.c | 35 +++--- bsps/shared/irq/irq-lock.c| 36 +++ bsps/shared/irq/irq-server.c | 27 ++--- bsps/shared/irq/irq-shell.c | 35 +++--- 11 files changed, 242 insertions(+), 97 deletions(-) diff --git a/bsps/include/bsp/irq-default.h b/bsps/include/bsp/irq-default.h index a94e045e0d..4d7beb189b 100644 --- a/bsps/include/bsp/irq-default.h +++ b/bsps/include/bsp/irq-default.h @@ -1,3 +1,5 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + /** * @file * @@ -5,9 +7,7 @@ */ /* - * SPDX-License-Identifier: BSD-2-Clause - * - * Copyright (C) 2019 embedded brains GmbH + * Copyright (C) 2019 embedded brains GmbH (http://www.embedded-brains.de) * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h index 31835d07ba..4135aa518c 100644 --- a/bsps/include/bsp/irq-generic.h +++ b/bsps/include/bsp/irq-generic.h @@ -1,27 +1,43 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + /** * @file * * @ingroup bsp_interrupt * - * @brief Generic BSP interrupt support API. + * @brief This header file provides interfaces of the generic interrupt + * controller support. */ /* - * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette. - * - * Copyright (c) 2008, 2017 embedded brains GmbH. + * Copyright (C) 2016 Chris Johns * - * embedded brains GmbH - * Dornierstr. 4 - * 82178 Puchheim - * Germany - * + * Copyright (C) 2008, 2017 embedded brains GmbH (http://www.embedded-brains.de) * - * Copyright (c) 2016 Chris Johns + * 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. * - * The license and distribution terms for this file may be - * found in the file LICENSE in this distribution or at - * http://www.rtems.org/license/LICENSE. + * 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. + */ + +/* + * The API is based on concepts of Pavel Pisa, Till Straumann and Eric Valette. */ #ifndef LIBBSP_SHARED_IRQ_GENERIC_H diff --git a/bsps/include/bsp/irq-info.h b/bsps/include/bsp/irq-info.h index ea6d629e76..25f05a9f69 100644 --- a/bsps/include/bsp/irq-info.h +++ b/bsps/include/bsp/irq-info.h @@ -1,22 +1,37 @@ +/* SPDX-License-Identifier: BSD-2-Clause */ + /** * @file * * @ingroup bsp_interrupt * - * @brief Generic BSP interrupt information API. + * @brief This header file provides interfaces of the generic interrupt + * controller support for the RTEMS Shell. */ /* - * Copyright (c) 2008, 2009 - * embedded brains GmbH - * Obere Lagerstr. 30 - * D-82178 Puchheim - * Germany - * + * Copyright (C) 2008, 2009 embedded brains GmbH (http://www.embedded-brains.de) + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of
RE: [PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more accurate
Thanks, I prepared tickets for master and 5.
I will make sure that the link in the commit message fits the right ticket of
the corresponding branch.
My plan is to push that on Monday, when I am back in the office
Best regards,
Jan
From: Joel Sherrill
Sent: Wednesday, June 16, 2021 8:06 PM
To: Gedare Bloom
Cc: Sommer, Jan ; devel@rtems.org
Subject: Re: [PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more
accurate
Me too. Just needs separate tickets for 5 and 6 so the release notes are
generated correctly.
On Wed, Jun 16, 2021 at 12:51 PM Gedare Bloom
mailto:ged...@rtems.org>> wrote:
I'm good with it for master and 5.
On Wed, Jun 16, 2021 at 4:18 AM Jan Sommer
mailto:jan.som...@dlr.de>> wrote:
>
> Closes #4455
> ---
> bsps/i386/pc386/clock/ckinit.c | 71 ++
> 1 file changed, 38 insertions(+), 33 deletions(-)
>
> diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
> index 09afe73cde..2df1818dd3 100644
> --- a/bsps/i386/pc386/clock/ckinit.c
> +++ b/bsps/i386/pc386/clock/ckinit.c
> @@ -104,48 +104,60 @@ static uint32_t pc386_get_timecount_i8254(struct
> timecounter *tc)
>
> /*
> * Calibrate CPU cycles per tick. Interrupts should be disabled.
> + * Will also set the PIT, so call this before registering the
> + * periodic timer for rtems tick generation
> */
> static void calibrate_tsc(void)
> {
>uint64_t begin_time;
> - uint8_t then_lsb, then_msb, now_lsb, now_msb;
> - uint32_t i;
> -
> - /*
> - * We just reset the timer, so we know we're at the beginning of a tick.
> - */
> -
> - /*
> - * Count cycles. Watching the timer introduces a several microsecond
> - * uncertaintity, so let it cook for a while and divide by the number of
> - * ticks actually executed.
> - */
> + uint8_t lsb, msb;
> + uint32_t max_timer_value;
> + uint32_t last_tick, cur_tick;
> + int32_t diff, remaining;
> +
> + /* Set the timer to free running mode */
> + outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_INTTC);
> + /* Reset the 16 timer reload value, first LSB, then MSB */
> + outport_byte(TIMER_CNTR0, 0);
> + outport_byte(TIMER_CNTR0, 0);
> + /* We use the full 16 bit */
> + max_timer_value = 0x;
> + /* Calibrate for 1s, i.e. TIMER_TICK PIT ticks */
> + remaining = TIMER_TICK;
>
>begin_time = rdtsc();
> -
> - for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> - i != 0; --i ) {
> -/* We know we've just completed a tick when timer goes from low to high
> */
> -then_lsb = then_msb = 0xff;
> -do {
> - READ_8254(now_lsb, now_msb);
> - if ((then_msb < now_msb) ||
> - ((then_msb == now_msb) && (then_lsb < now_lsb)))
> -break;
> - then_lsb = now_lsb;
> - then_msb = now_msb;
> -} while (1);
> + READ_8254(lsb, msb);
> + last_tick = (msb << 8) | lsb;
> + while(remaining > 0) {
> +READ_8254(lsb, msb);
> +cur_tick = (msb << 8) | lsb;
> +/* PIT counts down, so subtract cur from last */
> +diff = last_tick - cur_tick;
> +last_tick = cur_tick;
> +if (diff < 0) {
> +diff += max_timer_value;
> +}
> +remaining -= diff;
>}
>
>pc586_tsc_frequency = rdtsc() - begin_time;
>
> #if 0
> - printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency /
> 100));
> + printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
> #endif
> }
>
> static void clockOn(void)
> {
> +
> + /*
> + * First calibrate the TSC. Do this every time we
> + * turn the clock on in case the CPU clock speed has changed.
> + */
> + if ( x86_has_tsc() ) {
> +calibrate_tsc();
> + }
> +
>rtems_interrupt_lock_context lock_context;
>pc386_isrs_per_tick= 1;
>pc386_microseconds_per_isr =
> rtems_configuration_get_microseconds_per_tick();
> @@ -171,13 +183,6 @@ static void clockOn(void)
>rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
>
>bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> -
> - /*
> - * Now calibrate cycles per tick. Do this every time we
> - * turn the clock on in case the CPU clock speed has changed.
> - */
> - if ( x86_has_tsc() )
> -calibrate_tsc();
> }
>
> bool Clock_isr_enabled = false;
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libc: Added sig2str/str2sig prototypes
Hi Eshan, Thanks very much for this...It's really helpful! Question on workflow: So for this example, I just apply the patch to RSB. Do I understand correctly that we need to rebuild the tool chain each and every time I make any change? (Step 7 in Vaibhav's Blog) This didn't compile, apparently because of the double restricts. Do I need to make a change, rebuild the tool chain (around 1.33 hours), and test again? Hopefully there are shortcuts around that! Thanks again for your help. Sincerely, Matt On Wed, Jun 16, 2021 at 10:40 PM Eshan Dhawan wrote: > > Hi Matt, > Since you are making changes only to a header file you don’t need to run > autoreconf. > You can directly apply the patch to RSB and it should work > You need to run autoreconf when u make changes in makefile > That is when u add a .c file > > > On 17-Jun-2021, at 1:53 AM, Matt Joyce wrote: > > > > ***As Requested: For Review Only. Does Not Compile*** > > > > Added definition of SIG2STR_MAX and function prototypes for sig2str > > and str2sig in sys/signal.h in order to improve POSIX compliance. > > --- > > newlib/libc/include/sys/signal.h | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/newlib/libc/include/sys/signal.h > > b/newlib/libc/include/sys/signal.h > > index 45cc0366c..fd2b3c672 100644 > > --- a/newlib/libc/include/sys/signal.h > > +++ b/newlib/libc/include/sys/signal.h > > @@ -238,6 +238,18 @@ int sigqueue (pid_t, int, const union sigval); > > > > #endif /* __POSIX_VISIBLE >= 199309 */ > > > > +#if __GNU_VISIBLE > > + > > +/* 202x_d2-POSIX-Issue-8, p. 327 adds SIG2STR_MAX, p. 332 adds sig2str() > > + and str2sig(). */ > > + > > +#define SIG2STR_MAX 4294967295 > > + > > +int sig2str(int, char *); > > +int str2sig(const char *restrict, int *restrict); > > + > > +#endif /* __GNU_VISIBLE */ > > + > > #if defined(___AM29K__) > > /* These all need to be defined for ANSI C, but I don't think they are > >meaningful. */ > > -- > > 2.31.1 > > > > ___ > > 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 v2] covoar: Store address-to-line info outside of DWARF
On 17/6/21 1:01 pm, Alex White wrote: > So is this ok to push now that it is known to have an insignificant > performance > impact or is a different approach still warranted? OK to push. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
