Re: [PATCH 01/23] raspberrypi: Use shared bspreset.c
On Wed, Sep 3, 2014 at 11:25 AM, Joel Sherrill
wrote:
> ---
> c/src/lib/libbsp/arm/csb337/startup/bspreset.c | 1 +
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 2 +-
> .../lib/libbsp/arm/raspberrypi/startup/bspreset.c | 35
> testsuites/sptests/spintr_err01/init.c | 65
> +++---
> 4 files changed, 34 insertions(+), 69 deletions(-)
> delete mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>
> diff --git a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
> b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
> index 1167d92..940ff7f 100644
> --- a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
> +++ b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
> @@ -17,6 +17,7 @@ void bsp_reset(void)
> {
>rtems_interrupt_level level;
>
> + (void) level;
>rtems_interrupt_disable(level);
Is it ok to put (void) level; and then use level?
>
>/* Enable the watchdog timer, then wait for the world to end. */
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> index a8d98b4..cda8510 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> @@ -92,7 +92,7 @@ libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
> libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
>
> # Startup
> -libbsp_a_SOURCES += startup/bspreset.c
> +libbsp_a_SOURCES += ../../shared/bspreset_loop.c
> libbsp_a_SOURCES += startup/bspstart.c
>
> # IRQ
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
> b/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
> deleted file mode 100644
> index 4b3c732..000
> --- a/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/**
> - * @file
> - *
> - * @ingroup arm_start
> - *
> - * @brief Raspberry Pi reset code.
> - */
> -
> -/*
> - * Copyright (c) 2013 by Alan Cudmore
> - * Based on work by:
> - * Copyright (c) 2009
> - * embedded brains GmbH
> - * Obere Lagerstr. 30
> - * D-82178 Puchheim
> - * Germany
> - *
> - *
> - * 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
> - *
> - */
> -
> -#include
> -
> -#include
> -
> -void bsp_reset( void)
> -{
> - while (true) {
> -/* Do nothing */
> - }
> -}
> diff --git a/testsuites/sptests/spintr_err01/init.c
> b/testsuites/sptests/spintr_err01/init.c
> index 84ebfdb..490a0e6 100644
> --- a/testsuites/sptests/spintr_err01/init.c
> +++ b/testsuites/sptests/spintr_err01/init.c
> @@ -20,11 +20,8 @@ rtems_task Init(
>rtems_task_argument argument
> )
> {
> - rtems_status_code status;
> -
>TEST_BEGIN();
> - #if ((CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE) || \
> - defined(_C3x) || defined(_C4x))
> + #if (CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE)
> puts(
>"TA1 - rtems_interrupt_catch - "
>"bad handler RTEMS_INVALID_ADDRESS -- SKIPPED"
> @@ -32,36 +29,38 @@ rtems_task Init(
> puts(
>"TA1 - rtems_interrupt_catch - "
>"old isr RTEMS_INVALID_ADDRESS - SKIPPED" );
> -#else
> - rtems_isr_entry old_service_routine;
> -status = rtems_interrupt_catch(
> - Service_routine,
> - CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER + 1,
> - &old_service_routine
> -);
> -fatal_directive_status(
> - status,
> - RTEMS_INVALID_NUMBER,
> - "rtems_interrupt_catch with invalid vector"
> -);
> -puts( "TA1 - rtems_interrupt_catch - RTEMS_INVALID_NUMBER" );
> + #else
> +rtems_status_code status;
>
> -status = rtems_interrupt_catch( NULL, 3, &old_service_routine );
> -fatal_directive_status(
> - status,
> - RTEMS_INVALID_ADDRESS,
> - "rtems_interrupt_catch with invalid handler"
> -);
> -puts( "TA1 - rtems_interrupt_catch - bad handler RTEMS_INVALID_ADDRESS"
> );
> +rtems_isr_entry old_service_routine;
> + status = rtems_interrupt_catch(
> +Service_routine,
> +CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER + 1,
> +&old_service_routine
> + );
> + fatal_directive_status(
> +status,
> +RTEMS_INVALID_NUMBER,
> +"rtems_interrupt_catch with invalid vector"
> + );
> + puts( "TA1 - rtems_interrupt_catch - RTEMS_INVALID_NUMBER" );
> +
> + status = rtems_interrupt_catch( NULL, 3, &old_service_routine );
> + fatal_directive_status(
> +status,
> +RTEMS_INVALID_ADDRESS,
> +"rtems_interrupt_catch with invalid handler"
> + );
> + puts( "TA1 - rtems_interrupt_catch - bad handler
> RTEMS_INVALID_ADDRESS" );
> +
> + status = rtems_interrupt_catch( Service_routine, 3, NULL );
> + fatal_directive_status(
> +status,
> +RTEMS_INVALID_ADDRESS,
> +"rtems_interrupt_catch with invalid old isr pointer"
> + );
> + puts( "TA1 - rtems_interrupt_catch - old isr RTE
Re: [PATCH 01/23] raspberrypi: Use shared bspreset.c
On Thu, Sep 4, 2014 at 12:16 PM, Gedare Bloom wrote:
> On Wed, Sep 3, 2014 at 11:25 AM, Joel Sherrill
> wrote:
>> ---
>> c/src/lib/libbsp/arm/csb337/startup/bspreset.c | 1 +
>> c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 2 +-
>> .../lib/libbsp/arm/raspberrypi/startup/bspreset.c | 35
>> testsuites/sptests/spintr_err01/init.c | 65
>> +++---
>> 4 files changed, 34 insertions(+), 69 deletions(-)
>> delete mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>>
>> diff --git a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>> b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>> index 1167d92..940ff7f 100644
>> --- a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>> +++ b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>> @@ -17,6 +17,7 @@ void bsp_reset(void)
>> {
>>rtems_interrupt_level level;
>>
>> + (void) level;
>>rtems_interrupt_disable(level);
> Is it ok to put (void) level; and then use level?
Nevermind I see this is to eliminate a different warning. Also,
http://stackoverflow.com/questions/8071579/hide-gcc-warning-set-but-not-used
>
>>
>>/* Enable the watchdog timer, then wait for the world to end. */
>> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
>> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
>> index a8d98b4..cda8510 100644
>> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
>> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
>> @@ -92,7 +92,7 @@ libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
>> libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
>>
>> # Startup
>> -libbsp_a_SOURCES += startup/bspreset.c
>> +libbsp_a_SOURCES += ../../shared/bspreset_loop.c
>> libbsp_a_SOURCES += startup/bspstart.c
>>
>> # IRQ
>> diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>> b/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>> deleted file mode 100644
>> index 4b3c732..000
>> --- a/c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>> +++ /dev/null
>> @@ -1,35 +0,0 @@
>> -/**
>> - * @file
>> - *
>> - * @ingroup arm_start
>> - *
>> - * @brief Raspberry Pi reset code.
>> - */
>> -
>> -/*
>> - * Copyright (c) 2013 by Alan Cudmore
>> - * Based on work by:
>> - * Copyright (c) 2009
>> - * embedded brains GmbH
>> - * Obere Lagerstr. 30
>> - * D-82178 Puchheim
>> - * Germany
>> - *
>> - *
>> - * 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
>> - *
>> - */
>> -
>> -#include
>> -
>> -#include
>> -
>> -void bsp_reset( void)
>> -{
>> - while (true) {
>> -/* Do nothing */
>> - }
>> -}
>> diff --git a/testsuites/sptests/spintr_err01/init.c
>> b/testsuites/sptests/spintr_err01/init.c
>> index 84ebfdb..490a0e6 100644
>> --- a/testsuites/sptests/spintr_err01/init.c
>> +++ b/testsuites/sptests/spintr_err01/init.c
>> @@ -20,11 +20,8 @@ rtems_task Init(
>>rtems_task_argument argument
>> )
>> {
>> - rtems_status_code status;
>> -
>>TEST_BEGIN();
>> - #if ((CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE) || \
>> - defined(_C3x) || defined(_C4x))
>> + #if (CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE)
>> puts(
>>"TA1 - rtems_interrupt_catch - "
>>"bad handler RTEMS_INVALID_ADDRESS -- SKIPPED"
>> @@ -32,36 +29,38 @@ rtems_task Init(
>> puts(
>>"TA1 - rtems_interrupt_catch - "
>>"old isr RTEMS_INVALID_ADDRESS - SKIPPED" );
>> -#else
>> - rtems_isr_entry old_service_routine;
>> -status = rtems_interrupt_catch(
>> - Service_routine,
>> - CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER + 1,
>> - &old_service_routine
>> -);
>> -fatal_directive_status(
>> - status,
>> - RTEMS_INVALID_NUMBER,
>> - "rtems_interrupt_catch with invalid vector"
>> -);
>> -puts( "TA1 - rtems_interrupt_catch - RTEMS_INVALID_NUMBER" );
>> + #else
>> +rtems_status_code status;
>>
>> -status = rtems_interrupt_catch( NULL, 3, &old_service_routine );
>> -fatal_directive_status(
>> - status,
>> - RTEMS_INVALID_ADDRESS,
>> - "rtems_interrupt_catch with invalid handler"
>> -);
>> -puts( "TA1 - rtems_interrupt_catch - bad handler RTEMS_INVALID_ADDRESS"
>> );
>> +rtems_isr_entry old_service_routine;
>> + status = rtems_interrupt_catch(
>> +Service_routine,
>> +CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER + 1,
>> +&old_service_routine
>> + );
>> + fatal_directive_status(
>> +status,
>> +RTEMS_INVALID_NUMBER,
>> +"rtems_interrupt_catch with invalid vector"
>> + );
>> + puts( "TA1 - rtems_interrupt_catch - RTEMS_INVALID_NUMBER" );
>> +
>> + status = rtems_interrupt_catch( NULL, 3, &old_service_routine );
>> + fatal_directive_status(
>> +status,
>> +RTEMS_INVALID_ADDRESS,
>> +"rtems_interrupt_catch with invalid handler"
>> + );
>> + puts( "TA1 - rtems_inte
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill wrote: > --- > cpukit/posix/src/mprotect.c | 23 ++- > 1 file changed, 14 insertions(+), 9 deletions(-) > > diff --git a/cpukit/posix/src/mprotect.c b/cpukit/posix/src/mprotect.c > index f2f8af6..51b565e 100644 > --- a/cpukit/posix/src/mprotect.c > +++ b/cpukit/posix/src/mprotect.c > @@ -3,10 +3,19 @@ > * > * @brief Change Memory Protection > * @ingroup POSIXAPI > + * > + * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. > + * > + * This is not a functional version of mprotect() but the SPARC backend > + * for at least gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to > + * be there and return 0. > + * > + * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a > + * way to call this for RTEMS anymore but it doesn't hurt to leave it. > */ > > /* > - * COPYRIGHT (c) 1989-2007. > + * COPYRIGHT (c) 1989-2014. > * On-Line Applications Research Corporation (OAR). > * > * The license and distribution terms for this file may be > @@ -21,16 +30,12 @@ > #include > > /* > - * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. > - * > - * This is not a functional version but the SPARC backend for at least > - * gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to be there and > - * return 0. > - * > - * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a > - * way to call this for RTEMS anymore but it doesn't hurt to leave it. > + * RTEMS does not have so we need a prototype here to > + * avoid warnings. > */ > > +int mprotect( const void *, size_t, int ); > + I don't like (despise) adding prototypes to C files just to get rid of this warning. The prototype should be coming from whatever header provides the function, or the function should be declared static. > int mprotect( >const void *addr __attribute__((unused)), >size_t len __attribute__((unused)), > -- > 1.9.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
Re: [PATCH 19/23] rtems-rfs-buffer.c: Correct printf() format specifiers to eliminate warnings
On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill
wrote:
> ---
> cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
> b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
> index 3d89f5f..4192b21 100644
> --- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
> +++ b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
> @@ -52,13 +52,12 @@ rtems_rfs_scan_chain (rtems_chain_control* chain,
> buffer = (rtems_rfs_buffer*) node;
>
> if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
> - printf ("%" PRIuPTR " ", ((intptr_t) buffer->user));
> + printf ("%p ", buffer->user);
>
> if (((rtems_rfs_buffer_block) ((intptr_t)(buffer->user))) == block)
> {
>if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
> -printf (": found block=%" PRIuPTR "\n",
> -((intptr_t)(buffer->user)));
> +printf (": found block=%p\n", buffer->user);
What is the warning this fixed? The "PRIuPTR" should be the right way
to print an (unsigned) pointer. Perhaps changing the cast to
(uintptr_t) would fix the warning?
>
>(*count)--;
>rtems_chain_extract_unprotected (node);
> --
> 1.9.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
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
On 9/4/2014 11:19 AM, Gedare Bloom wrote: On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill wrote: --- cpukit/posix/src/mprotect.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/cpukit/posix/src/mprotect.c b/cpukit/posix/src/mprotect.c index f2f8af6..51b565e 100644 --- a/cpukit/posix/src/mprotect.c +++ b/cpukit/posix/src/mprotect.c @@ -3,10 +3,19 @@ * * @brief Change Memory Protection * @ingroup POSIXAPI + * + * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. + * + * This is not a functional version of mprotect() but the SPARC backend + * for at least gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to + * be there and return 0. + * + * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a + * way to call this for RTEMS anymore but it doesn't hurt to leave it. */ /* - * COPYRIGHT (c) 1989-2007. + * COPYRIGHT (c) 1989-2014. * On-Line Applications Research Corporation (OAR). * * The license and distribution terms for this file may be @@ -21,16 +30,12 @@ #include /* - * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. - * - * This is not a functional version but the SPARC backend for at least - * gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to be there and - * return 0. - * - * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a - * way to call this for RTEMS anymore but it doesn't hurt to leave it. + * RTEMS does not have so we need a prototype here to + * avoid warnings. */ +int mprotect( const void *, size_t, int ); + I don't like (despise) adding prototypes to C files just to get rid of this warning. The prototype should be coming from whatever header provides the function, or the function should be declared static. We can't make it static as it doesn't solve the problem of providing a public symbol to satisfy linking. As the comments indicate, this was added to let gcc produced SPARC executables actually link. Also I didn't see adding when we don't support any of it. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/mman.h.html However, that doesn't mean that adding and a bunch of stubs that return ENOSYS isn't an acceptable option. I just don't want to invest the effort now. int mprotect( const void *addr __attribute__((unused)), size_t len __attribute__((unused)), -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 19/23] rtems-rfs-buffer.c: Correct printf() format specifiers to eliminate warnings
On 9/4/2014 11:21 AM, Gedare Bloom wrote:
> On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill
> wrote:
>> ---
>> cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> index 3d89f5f..4192b21 100644
>> --- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> +++ b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> @@ -52,13 +52,12 @@ rtems_rfs_scan_chain (rtems_chain_control* chain,
>> buffer = (rtems_rfs_buffer*) node;
>>
>> if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
>> - printf ("%" PRIuPTR " ", ((intptr_t) buffer->user));
>> + printf ("%p ", buffer->user);
>>
>> if (((rtems_rfs_buffer_block) ((intptr_t)(buffer->user))) == block)
>> {
>>if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
>> -printf (": found block=%" PRIuPTR "\n",
>> -((intptr_t)(buffer->user)));
>> +printf (": found block=%p\n", buffer->user);
> What is the warning this fixed? The "PRIuPTR" should be the right way
> to print an (unsigned) pointer. Perhaps changing the cast to
> (uintptr_t) would fix the warning?
Give me a few hours. I am not sure which architecture/BSP tripped this. I
reverted the patch locally but will need to build all to find it again.
>>(*count)--;
>>rtems_chain_extract_unprotected (node);
>> --
>> 1.9.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Regenerate preinstall.am for score/cpu/or1k
This patch regenerates preinstall.am file after Chris fixup regarding preinstall.am files gerenration from bootstrap -p command. --- cpukit/score/cpu/or1k/preinstall.am | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cpukit/score/cpu/or1k/preinstall.am b/cpukit/score/cpu/or1k/preinstall.am index 01cd68f..f4d7153 100644 --- a/cpukit/score/cpu/or1k/preinstall.am +++ b/cpukit/score/cpu/or1k/preinstall.am @@ -5,14 +5,14 @@ $(srcdir)/preinstall.am: Makefile.am $(AMPOLISH3) $(srcdir)/Makefile.am > $(srcdir)/preinstall.am endif +PREINSTALL_DIRS = +DISTCLEANFILES += $(PREINSTALL_DIRS) + all-am: $(PREINSTALL_FILES) PREINSTALL_FILES = CLEANFILES += $(PREINSTALL_FILES) -PREINSTALL_DIRS = -DISTCLEANFILES += $(PREINSTALL_DIRS) - $(PROJECT_INCLUDE)/rtems/$(dirstamp): @$(MKDIR_P) $(PROJECT_INCLUDE)/rtems @: > $(PROJECT_INCLUDE)/rtems/$(dirstamp) -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Capture Engine - Addition of capture task information to the capture buffer
Chris suggested the following approach: >Another approach could involve adding the task data to the trace buffer when >the first reference > to the task is added to the trace buffer. You would add the task data tagging > it with some sort of "id". > When added events related to the task the "id" is used. The trace buffer > decoder extracts the task data > building a suitable table to decode the following "id" references. There is a > small extra bump filling the > trace buffer with the task details but this is the cost of tracing in > software. This approach helps solves > the problem of off board streaming of the trace data. Using this approach are there any suggestions for how the capture control information currently accessed through the capture task would be handled? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Capture Engine - Addition of capture task information to the capture buffer
On 9/4/2014 12:57 PM, Jennifer Averett wrote: > > Chris suggested the following approach: > > > > >Another approach could involve adding the task data to the trace > buffer when the first reference > > > to the task is added to the trace buffer. You would add the task > data tagging it with some sort of "id". > > > When added events related to the task the "id" is used. The trace > buffer decoder extracts the task data > > > building a suitable table to decode the following "id" references. > There is a small extra bump filling the > > > trace buffer with the task details but this is the cost of tracing > in software. This approach helps solves > > > the problem of off board streaming of the trace data. > > > > Using this approach are there any suggestions for how the capture > control information currently > > accessed through the capture task would be handled? > > > Piling on... most of the information in the capture engine's task control blocks can be logged statically on task create. BUT... there is also trigger information in there. Where should that be now? Jennifer is plowing ahead logging variable length records and eliminating fields in the capture task control but we don't see how to get rid of all of it. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Regenerate preinstall.am for score/cpu/or1k
Committed. Thanks. --joel On 9/4/2014 12:55 PM, Hesham ALMatary wrote: > This patch regenerates preinstall.am file after Chris fixup regarding > preinstall.am files gerenration from bootstrap -p command. > --- > cpukit/score/cpu/or1k/preinstall.am | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/cpukit/score/cpu/or1k/preinstall.am > b/cpukit/score/cpu/or1k/preinstall.am > index 01cd68f..f4d7153 100644 > --- a/cpukit/score/cpu/or1k/preinstall.am > +++ b/cpukit/score/cpu/or1k/preinstall.am > @@ -5,14 +5,14 @@ $(srcdir)/preinstall.am: Makefile.am > $(AMPOLISH3) $(srcdir)/Makefile.am > $(srcdir)/preinstall.am > endif > > +PREINSTALL_DIRS = > +DISTCLEANFILES += $(PREINSTALL_DIRS) > + > all-am: $(PREINSTALL_FILES) > > PREINSTALL_FILES = > CLEANFILES += $(PREINSTALL_FILES) > > -PREINSTALL_DIRS = > -DISTCLEANFILES += $(PREINSTALL_DIRS) > - > $(PROJECT_INCLUDE)/rtems/$(dirstamp): > @$(MKDIR_P) $(PROJECT_INCLUDE)/rtems > @: > $(PROJECT_INCLUDE)/rtems/$(dirstamp) -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
On Thu, Sep 4, 2014 at 1:10 PM, Joel Sherrill wrote: > On 9/4/2014 11:19 AM, Gedare Bloom wrote: >> >> On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill >> wrote: >>> >>> --- >>> cpukit/posix/src/mprotect.c | 23 ++- >>> 1 file changed, 14 insertions(+), 9 deletions(-) >>> >>> diff --git a/cpukit/posix/src/mprotect.c b/cpukit/posix/src/mprotect.c >>> index f2f8af6..51b565e 100644 >>> --- a/cpukit/posix/src/mprotect.c >>> +++ b/cpukit/posix/src/mprotect.c >>> @@ -3,10 +3,19 @@ >>>* >>>* @brief Change Memory Protection >>>* @ingroup POSIXAPI >>> + * >>> + * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. >>> + * >>> + * This is not a functional version of mprotect() but the SPARC backend >>> + * for at least gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to >>> + * be there and return 0. >>> + * >>> + * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a >>> + * way to call this for RTEMS anymore but it doesn't hurt to leave it. >>>*/ >>> >>> /* >>> - * COPYRIGHT (c) 1989-2007. >>> + * COPYRIGHT (c) 1989-2014. >>>* On-Line Applications Research Corporation (OAR). >>>* >>>* The license and distribution terms for this file may be >>> @@ -21,16 +30,12 @@ >>> #include >>> >>> /* >>> - * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. >>> - * >>> - * This is not a functional version but the SPARC backend for at least >>> - * gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to be there and >>> - * return 0. >>> - * >>> - * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a >>> - * way to call this for RTEMS anymore but it doesn't hurt to leave it. >>> + * RTEMS does not have so we need a prototype here to >>> + * avoid warnings. >>>*/ >>> >>> +int mprotect( const void *, size_t, int ); >>> + >> >> I don't like (despise) adding prototypes to C files just to get rid of >> this warning. The prototype should be coming from whatever header >> provides the function, or the function should be declared static. > > We can't make it static as it doesn't solve the problem of providing a > public > symbol to satisfy linking. As the comments indicate, this was added to let > gcc produced SPARC executables actually link. > > Also I didn't see adding when we don't support any of it. > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/mman.h.html > > However, that doesn't mean that adding and a bunch of > stubs that return ENOSYS isn't an acceptable option. I just don't want to > invest the effort now. > Make a note to that effect. -gedare > >>> int mprotect( >>> const void *addr __attribute__((unused)), >>> size_t len __attribute__((unused)), >>> -- >>> 1.9.3 >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
On 9/4/2014 2:06 PM, Gedare Bloom wrote: > On Thu, Sep 4, 2014 at 1:10 PM, Joel Sherrill > wrote: >> On 9/4/2014 11:19 AM, Gedare Bloom wrote: >>> On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill >>> wrote: --- cpukit/posix/src/mprotect.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/cpukit/posix/src/mprotect.c b/cpukit/posix/src/mprotect.c index f2f8af6..51b565e 100644 --- a/cpukit/posix/src/mprotect.c +++ b/cpukit/posix/src/mprotect.c @@ -3,10 +3,19 @@ * * @brief Change Memory Protection * @ingroup POSIXAPI + * + * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. + * + * This is not a functional version of mprotect() but the SPARC backend + * for at least gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to + * be there and return 0. + * + * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a + * way to call this for RTEMS anymore but it doesn't hurt to leave it. */ /* - * COPYRIGHT (c) 1989-2007. + * COPYRIGHT (c) 1989-2014. * On-Line Applications Research Corporation (OAR). * * The license and distribution terms for this file may be @@ -21,16 +30,12 @@ #include /* - * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. - * - * This is not a functional version but the SPARC backend for at least - * gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to be there and - * return 0. - * - * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a - * way to call this for RTEMS anymore but it doesn't hurt to leave it. + * RTEMS does not have so we need a prototype here to + * avoid warnings. */ +int mprotect( const void *, size_t, int ); + >>> I don't like (despise) adding prototypes to C files just to get rid of >>> this warning. The prototype should be coming from whatever header >>> provides the function, or the function should be declared static. >> We can't make it static as it doesn't solve the problem of providing a >> public >> symbol to satisfy linking. As the comments indicate, this was added to let >> gcc produced SPARC executables actually link. >> >> Also I didn't see adding when we don't support any of it. >> >> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/mman.h.html >> >> However, that doesn't mean that adding and a bunch of >> stubs that return ENOSYS isn't an acceptable option. I just don't want to >> invest the effort now. >> > Make a note to that effect. PR? Note in code? Where? I can assign the PR to you. :) > -gedare int mprotect( const void *addr __attribute__((unused)), size_t len __attribute__((unused)), -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 19/23] rtems-rfs-buffer.c: Correct printf() format specifiers to eliminate warnings
On 9/4/2014 11:21 AM, Gedare Bloom wrote:
> On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill
> wrote:
>> ---
>> cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> index 3d89f5f..4192b21 100644
>> --- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> +++ b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
>> @@ -52,13 +52,12 @@ rtems_rfs_scan_chain (rtems_chain_control* chain,
>> buffer = (rtems_rfs_buffer*) node;
>>
>> if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
>> - printf ("%" PRIuPTR " ", ((intptr_t) buffer->user));
>> + printf ("%p ", buffer->user);
>>
>> if (((rtems_rfs_buffer_block) ((intptr_t)(buffer->user))) == block)
>> {
>>if (rtems_rfs_trace (RTEMS_RFS_TRACE_BUFFER_CHAINS))
>> -printf (": found block=%" PRIuPTR "\n",
>> -((intptr_t)(buffer->user)));
>> +printf (": found block=%p\n", buffer->user);
> What is the warning this fixed? The "PRIuPTR" should be the right way
> to print an (unsigned) pointer. Perhaps changing the cast to
> (uintptr_t) would fix the warning?
log/moxie-moxiesim.log:../../../../../../rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-buffer.c:55:7:
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long int' [-Wformat=]
log/moxie-moxiesim.log:../../../../../../rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-buffer.c:55:7:
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long int' [-Wformat=]
log/moxie-moxiesim.log:../../../../../../rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-buffer.c:61:17:
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long int' [-Wformat=]
log/moxie-moxiesim.log:../../../../../../rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-buffer.c:61:17:
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long int' [-Wformat=]
This seems to have happened on bfin, h8300, i386, m32r, m68k and moxie.
Casting it to a uintptr_t on moxie change it to this:
../../../../../../rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-buffer.c:55:7:
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long unsigned int' [-Wformat=]
printf ("%" PRIuPTR " ", ((uintptr_t) buffer->user));
Checking the preprocessor output, I see:
typedef long int __intptr_t;
typedef long unsigned int __uintptr_t;
inttypes.h has this:
#if PTRDIFF_MAX <= __INTTYPES_EXP(INT_MAX)
# define __PRIPTR(x) __STRINGIFY(x)
# define __SCNPTR(x) __STRINGIFY(x)
#elif PTRDIFF_MAX <= __INTTYPES_EXP(LONG_MAX) || !defined(__have_longlong64)
...
I checked PTRDIFF_MAX and INT_MAX and they are equal. They
are also equal on arm-rtems4.11-gcc which does not produce this
warning.
I changed that to a < (not <=), the format became "%lu",
and the warning went away.
Checking Linux on Centos, it is lu if 32 bit and llu if 64 bit.
The RTEMS inttypes.h is unique to us. I am wondering if
changing the <= on both those checks is desirable.
This could just be a bug in inttypes.h
Any thoughts?
>>(*count)--;
>>rtems_chain_extract_unprotected (node);
>> --
>> 1.9.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
On 5/09/2014 3:10 am, Joel Sherrill wrote: Also I didn't see adding when we don't support any of it. There is code here but it needs some tests and moving to libcsupport. :) http://git.rtems.org/chrisj/rtl.git/tree/sys/mman.h http://git.rtems.org/chrisj/rtl.git/tree/mmap.c http://git.rtems.org/chrisj/rtl.git/tree/munmap.c http://git.rtems.org/chrisj/rtl.git/tree/mmap-internal.h Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 14/23] mprotect.c: Remove warning for no prototype
PR, I think it should go to Chris since he has a WIP on it. On Thu, Sep 4, 2014 at 3:38 PM, Joel Sherrill wrote: > > On 9/4/2014 2:06 PM, Gedare Bloom wrote: >> On Thu, Sep 4, 2014 at 1:10 PM, Joel Sherrill >> wrote: >>> On 9/4/2014 11:19 AM, Gedare Bloom wrote: On Wed, Sep 3, 2014 at 11:26 AM, Joel Sherrill wrote: > --- > cpukit/posix/src/mprotect.c | 23 ++- > 1 file changed, 14 insertions(+), 9 deletions(-) > > diff --git a/cpukit/posix/src/mprotect.c b/cpukit/posix/src/mprotect.c > index f2f8af6..51b565e 100644 > --- a/cpukit/posix/src/mprotect.c > +++ b/cpukit/posix/src/mprotect.c > @@ -3,10 +3,19 @@ >* >* @brief Change Memory Protection >* @ingroup POSIXAPI > + * > + * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. > + * > + * This is not a functional version of mprotect() but the SPARC backend > + * for at least gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to > + * be there and return 0. > + * > + * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a > + * way to call this for RTEMS anymore but it doesn't hurt to leave it. >*/ > > /* > - * COPYRIGHT (c) 1989-2007. > + * COPYRIGHT (c) 1989-2014. >* On-Line Applications Research Corporation (OAR). >* >* The license and distribution terms for this file may be > @@ -21,16 +30,12 @@ > #include > > /* > - * 12.2.3 Change Memory Protection, P1003.1b-1996, p. 277. > - * > - * This is not a functional version but the SPARC backend for at least > - * gcc 2.8.1 plus gnat 3.13p and gcc 3.0.1 require it to be there and > - * return 0. > - * > - * As of gcc 4.2.2, the gcc SPARC backend doesn't appear to have a > - * way to call this for RTEMS anymore but it doesn't hurt to leave it. > + * RTEMS does not have so we need a prototype here to > + * avoid warnings. >*/ > > +int mprotect( const void *, size_t, int ); > + I don't like (despise) adding prototypes to C files just to get rid of this warning. The prototype should be coming from whatever header provides the function, or the function should be declared static. >>> We can't make it static as it doesn't solve the problem of providing a >>> public >>> symbol to satisfy linking. As the comments indicate, this was added to let >>> gcc produced SPARC executables actually link. >>> >>> Also I didn't see adding when we don't support any of it. >>> >>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/mman.h.html >>> >>> However, that doesn't mean that adding and a bunch of >>> stubs that return ENOSYS isn't an acceptable option. I just don't want to >>> invest the effort now. >>> >> Make a note to that effect. > PR? Note in code? Where? > > I can assign the PR to you. :) >> -gedare > int mprotect( > const void *addr __attribute__((unused)), > size_t len __attribute__((unused)), > -- > 1.9.3 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >>> >>> >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.comOn-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available(256) 722-9985 >>> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Capture Engine - Addition of capture task information to the capture buffer
On 5/09/2014 4:00 am, Joel Sherrill wrote: Piling on... most of the information in the capture engine's task control blocks can be logged statically on task create. This should be done when the first reference to the task is logged. The task may already exist. BUT... there is also trigger information in there. Where should that be now? The current trigger information is design around the "task" because the events are per task. We think we may need a different trigger mechanism for a "function" based trace systems. Are you intending to run the "user extension" and "function" tracing at the same time ? Jennifer is plowing ahead logging variable length records and eliminating fields in the capture task control but we don't see how to get rid of all of it. I feel we may need some data in the TCB yet I do not think we need all the fields in current code. In the first pass of "function" tracing I think a single bit per task for any function called in the task's context to raise the trigger. This means a global table of bits for all functions to control the function specific trace and trigger control and then a bit per task for any function triggered or traced (once triggered) to allow filtering by task. We might get away with a single 32bit value (actually a sizeof(void*)) in the TCB. If the need for more memory grows the TCB value could be changed to a pointer that reference a buffer taken from a private capture engine pool of buffers created when it starts based on a user specified size. In this case lack of buffers would simply log the error and user would need to adjust the value. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 01/23] raspberrypi: Use shared bspreset.c
On 04/09/14 18:16, Gedare Bloom wrote:
On Wed, Sep 3, 2014 at 11:25 AM, Joel Sherrill
wrote:
>---
> c/src/lib/libbsp/arm/csb337/startup/bspreset.c | 1 +
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 2 +-
> .../lib/libbsp/arm/raspberrypi/startup/bspreset.c | 35
> testsuites/sptests/spintr_err01/init.c | 65
+++---
> 4 files changed, 34 insertions(+), 69 deletions(-)
> delete mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspreset.c
>
>diff --git a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>index 1167d92..940ff7f 100644
>--- a/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>+++ b/c/src/lib/libbsp/arm/csb337/startup/bspreset.c
>@@ -17,6 +17,7 @@ void bsp_reset(void)
> {
>rtems_interrupt_level level;
>
>+ (void) level;
>rtems_interrupt_disable(level);
Is it ok to put (void) level; and then use level?
Logically it makes more sense to use
rtems_interrupt_disable(level);
(void) level;
since rtems_interrupt_disable() sets the level, but we are only interested in
the side-effects of rtems_interrupt_disable() and not the level itself.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] smptests/smpcache01: Disable SMP cache manager test when not applicable
On 01/09/14 13:15, Daniel Cederman wrote: --- testsuites/smptests/smpcache01/init.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/testsuites/smptests/smpcache01/init.c b/testsuites/smptests/smpcache01/init.c index dd2f9f1..48154d4 100644 --- a/testsuites/smptests/smpcache01/init.c +++ b/testsuites/smptests/smpcache01/init.c @@ -20,6 +20,8 @@ const char rtems_test_name[] = "SMPCACHE 1"; +char test_is_applicable = 1; + Why is this not a bool, and why is this not static? #define CPU_COUNT 32 #define WORKER_PRIORITY 100 @@ -33,7 +35,19 @@ _Cache_manager_Send_smp_msg( Cache_manager_Function_ptr func, const void * addr, size_t size - ); + ) __attribute__((weak)); Before we start to use weak functions in the testsuite, we should add an attribute macro to basedefs.h and generally agree, that weak functions are acceptable for RTEMS in general. An alternative solution to this hack would be to turn the cache manager message operations into general purpose message operations for SMP so that it can be used for other things and not just the cache manager. Basically you created a means to execute a function on all processors of a set and wait for completion on all processors of a set. [...] -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
