Re: [PATCH] libchip/dwmac: Make PHY address user configurable.
Thanks. On 8/22/2014 1:53 AM, Christian Mauderer wrote: > Hi Joel, > > I've changed the name of the structure to a more speaking one and added a few > lines of example-code to the README of the altcycv-BSP. > > Kind regards > > Christian Mauderer > ___ > 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
arm/nds - cache_manager.c build failure
Hi I am guessing some conditional path isn't being covered right to get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could someone please take a look at this and fix it? arm-rtems4.11-gcc --pipe -B../../../../../.././lib/ -B../../../../../.././nds/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include -mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft -mthumb-interwork -O2 -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c -o libbsp_a-cache_manager.o `test -f '../../../libcpu/shared/src/cache_manager.c' || echo '../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c: In function '_invalidate_multiple_instruction_lines_no_range_functions': ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40: error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this function) i_addr = (void *)((size_t)i_addr & ~(CPU_INSTRUCTION_CACHE_ALIGNMENT - 1)); ^ -- 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
nios2_iss cache_manager.c Build Failure
Hi Similar issue to NDS. Could someone please fix this? ../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c: In function '_invalidate_multiple_instruction_lines_no_range_functions': ../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c:458: error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this function) ../../../../../../../rtems/c/src/lib/libcpu/nios2/../shared/src/cache_manager.c:458: error: (Each undeclared identifier is reported only once -- 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: arm/nds - cache_manager.c build failure
Looks like this function needs a guard on #if defined(CPU_INSTRUCTION_CACHE_ALIGNMENT) see rtems_cache_invalidate_multiple_instruction_lines() On Fri, Aug 22, 2014 at 10:30 AM, Joel Sherrill wrote: > Hi > > I am guessing some conditional path isn't being covered right to > get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could > someone please take a look at this and fix it? > > arm-rtems4.11-gcc --pipe -B../../../../../.././lib/ > -B../../../../../.././nds/lib/ -specs bsp_specs -qrtems > -DHAVE_CONFIG_H > -I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include > -mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft > -mthumb-interwork -O2 -Wall -Wmissing-prototypes > -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT > libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c > -o libbsp_a-cache_manager.o `test -f > '../../../libcpu/shared/src/cache_manager.c' || echo > '../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c > ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c: > In function '_invalidate_multiple_instruction_lines_no_range_functions': > ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40: > error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this > function) >i_addr = (void *)((size_t)i_addr & ~(CPU_INSTRUCTION_CACHE_ALIGNMENT > - 1)); > ^ > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: arm/nds - cache_manager.c build failure
On 8/22/2014 9:38 AM, Gedare Bloom wrote: > Looks like this function needs a guard on #if > defined(CPU_INSTRUCTION_CACHE_ALIGNMENT) > > > see rtems_cache_invalidate_multiple_instruction_lines() Or CPU_INSTRUCTION_CACHE_ALIGNMENT needs to be always defined. I did a full build of all tests on all BSPs using the latest RSB tools and only a couple of BSPs failed this way. > On Fri, Aug 22, 2014 at 10:30 AM, Joel Sherrill > wrote: >> Hi >> >> I am guessing some conditional path isn't being covered right to >> get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could >> someone please take a look at this and fix it? >> >> arm-rtems4.11-gcc --pipe -B../../../../../.././lib/ >> -B../../../../../.././nds/lib/ -specs bsp_specs -qrtems >> -DHAVE_CONFIG_H >> -I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include >> -mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft >> -mthumb-interwork -O2 -Wall -Wmissing-prototypes >> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT >> libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c >> -o libbsp_a-cache_manager.o `test -f >> '../../../libcpu/shared/src/cache_manager.c' || echo >> '../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c >> ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c: >> In function '_invalidate_multiple_instruction_lines_no_range_functions': >> ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40: >> error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this >> function) >>i_addr = (void *)((size_t)i_addr & ~(CPU_INSTRUCTION_CACHE_ALIGNMENT >> - 1)); >> ^ >> >> -- >> 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 -- 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: arm/nds - cache_manager.c build failure
On Fri, Aug 22, 2014 at 10:45 AM, Joel Sherrill wrote: > > On 8/22/2014 9:38 AM, Gedare Bloom wrote: >> Looks like this function needs a guard on #if >> defined(CPU_INSTRUCTION_CACHE_ALIGNMENT) >> >> >> see rtems_cache_invalidate_multiple_instruction_lines() > Or CPU_INSTRUCTION_CACHE_ALIGNMENT needs to be always defined. > I did a full build of all tests on all BSPs using the latest RSB tools and > only a couple of BSPs failed this way. > The prevailing solution is to put the guard in the code. Your solution could be proposed, but I'd wait til after release. > >> On Fri, Aug 22, 2014 at 10:30 AM, Joel Sherrill >> wrote: >>> Hi >>> >>> I am guessing some conditional path isn't being covered right to >>> get CPU_INSTRUCTION_CACHE_ALIGNMENT defined. Could >>> someone please take a look at this and fix it? >>> >>> arm-rtems4.11-gcc --pipe -B../../../../../.././lib/ >>> -B../../../../../.././nds/lib/ -specs bsp_specs -qrtems >>> -DHAVE_CONFIG_H >>> -I../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../shared/include >>> -mstructure-size-boundary=8 -mcpu=arm9tdmi -mfpu=vfp -mfloat-abi=soft >>> -mthumb-interwork -O2 -Wall -Wmissing-prototypes >>> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT >>> libbsp_a-cache_manager.o -MD -MP -MF .deps/libbsp_a-cache_manager.Tpo -c >>> -o libbsp_a-cache_manager.o `test -f >>> '../../../libcpu/shared/src/cache_manager.c' || echo >>> '../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/'`../../../libcpu/shared/src/cache_manager.c >>> ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c: >>> In function '_invalidate_multiple_instruction_lines_no_range_functions': >>> ../../../../../../../../rtems/c/src/lib/libbsp/arm/nds/../../../libcpu/shared/src/cache_manager.c:458:40: >>> error: 'CPU_INSTRUCTION_CACHE_ALIGNMENT' undeclared (first use in this >>> function) >>>i_addr = (void *)((size_t)i_addr & ~(CPU_INSTRUCTION_CACHE_ALIGNMENT >>> - 1)); >>> ^ >>> >>> -- >>> 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 > > -- > 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
or1k build issues
Hi Some basic or1ksim BSP issues: (1) I can't build what is committed. gmake[7]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1k_or1ksim-rtems/or1k-rtems4.11/c/or1k_or1ksim/lib/libbsp/or1k' Makefile:731: *** missing separator. Stop. I think this was an issue with the generated preinstall.am. I will be committing an updated version. (2) I built with networking on. I assume the soft float is normal GCC code and thus the format is IEEE 754. I set a conditional to indicate that in xdr_float.c (3) Can we rename or1k_or1ksim to just or1ksim? It seems redundant to have or1k in the name twice. Are you ok if I rename the make/custom file? Does this impact anything else that would need to be updated? (4) Even with NOP addressed, spcache01 doesn't link. It is missing a few symbols from the cache manager. (5) tm27.h is not provided by the BSP so none of the tmtests or psxtmtests will compile. I added the stub version to the Makefile.am so the tests will at least compile EXCEPT for the spcache01 noted above. (6) Is the or1ksim built by RSB now? If so how? (7) Is the simulator really just called sim? If so, that is a WAY too generic name. If that's the case, we need to suggest to Christian that it gets renamed something more or1k specific like or1ksim. (8) How do you debug with the simulator? I think I am close to being able to help investigate but this weekend is the Southern Brewers Festival so I probably shouldn't touch code too much. :) -- 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 2/2] rtems: Add more clock tick functions
Add rtems_clock_ticks_later(), rtems_clock_ticks_later_us() and
rtems_clock_ticks_later_us().
FIXME: Patch is incomplete. Documentation and tests are missing. Just
for API review.
---
cpukit/rtems/include/rtems/rtems/clock.h | 66
1 file changed, 66 insertions(+)
diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
b/cpukit/rtems/include/rtems/rtems/clock.h
index ff71665..cee930e 100644
--- a/cpukit/rtems/include/rtems/rtems/clock.h
+++ b/cpukit/rtems/include/rtems/rtems/clock.h
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include /* struct timeval */
@@ -160,6 +161,71 @@ RTEMS_INLINE_ROUTINE rtems_interval
rtems_clock_get_ticks_since_boot(void)
}
/**
+ * @brief Returns the ticks counter value delta ticks in the future.
+ *
+ * @param[in] delta The ticks delta value.
+ *
+ * @return The tick counter value delta ticks in the future.
+ */
+RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later(
+ rtems_interval delta
+)
+{
+ return _Watchdog_Ticks_since_boot + delta;
+}
+
+/**
+ * @brief Returns the ticks counter value at least delta microseconds in the
+ * future.
+ *
+ * @param[in] delta The delta value in microseconds.
+ *
+ * @return The tick counter value at least delta microseconds in the future.
+ */
+RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later_us(
+ rtems_interval delta
+)
+{
+ rtems_interval us_per_tick = rtems_configuration_get_microseconds_per_tick();
+
+ return _Watchdog_Ticks_since_boot + (delta + us_per_tick - 1) / us_per_tick;
+}
+
+/**
+ * @brief Returns true if the current ticks counter value indicates a time
+ * before the time specified by the ticks value and false otherwise.
+ *
+ * @param[in] ticks The ticks value.
+ *
+ * This can be used to write busy loops with a timeout.
+ *
+ * @code
+ * status busy( void )
+ * {
+ * rtems_interval timeout = rtems_clock_ticks_later_us( 1 );
+ *
+ * do {
+ * if ( ok() ) {
+ * return success;
+ * }
+ * } while ( rtems_clock_ticks_before( timeout ) );
+ *
+ * return timeout;
+ * }
+ * @endcode
+ *
+ * @retval true The current ticks counter value indicates a time before the
+ * time specified by the ticks value.
+ * @retval false Otherwise.
+ */
+RTEMS_INLINE_ROUTINE bool rtems_clock_ticks_before(
+ rtems_interval ticks
+)
+{
+ return ( (int32_t) ticks - (int32_t) _Watchdog_Ticks_since_boot ) > 0;
+}
+
+/**
* @brief Obtain Ticks Per Seconds
*
* This routine implements the rtems_clock_get_ticks_per_second
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] rtems: Inline rtems_clock_get_ticks_since_boot()
Update documentation.
---
cpukit/rtems/Makefile.am| 1 -
cpukit/rtems/include/rtems/rtems/clock.h| 14 +--
cpukit/rtems/src/clockgettickssinceboot.c | 31 -
cpukit/score/include/rtems/score/watchdog.h | 7 ++
cpukit/score/include/rtems/score/watchdogimpl.h | 8 ---
doc/user/clock.t| 31 -
6 files changed, 24 insertions(+), 68 deletions(-)
delete mode 100644 cpukit/rtems/src/clockgettickssinceboot.c
diff --git a/cpukit/rtems/Makefile.am b/cpukit/rtems/Makefile.am
index b00e251..a1fafb1 100644
--- a/cpukit/rtems/Makefile.am
+++ b/cpukit/rtems/Makefile.am
@@ -151,7 +151,6 @@ librtems_a_SOURCES += src/barrierdata.c
librtems_a_SOURCES += src/clockget.c
librtems_a_SOURCES += src/clockgetsecondssinceepoch.c
librtems_a_SOURCES += src/clockgettickspersecond.c
-librtems_a_SOURCES += src/clockgettickssinceboot.c
librtems_a_SOURCES += src/clockgettod.c
librtems_a_SOURCES += src/clockgettodtimeval.c
librtems_a_SOURCES += src/clockgetuptime.c
diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
b/cpukit/rtems/include/rtems/rtems/clock.h
index d80218d..ff71665 100644
--- a/cpukit/rtems/include/rtems/rtems/clock.h
+++ b/cpukit/rtems/include/rtems/rtems/clock.h
@@ -149,15 +149,15 @@ rtems_status_code rtems_clock_get_seconds_since_epoch(
);
/**
- * @brief Obtain Ticks Since Boot
+ * @brief Gets the current ticks counter value.
*
- * This routine implements the rtems_clock_get_ticks_since_boot
- * directive.
- *
- * @retval This method returns the number of ticks since boot. It cannot
- * fail since RTEMS always keeps a running count of ticks since boot.
+ * @return The current tick counter value. With a 1ms clock tick, this counter
+ * overflows after 50 days since boot.
*/
-rtems_interval rtems_clock_get_ticks_since_boot(void);
+RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_get_ticks_since_boot(void)
+{
+ return _Watchdog_Ticks_since_boot;
+}
/**
* @brief Obtain Ticks Per Seconds
diff --git a/cpukit/rtems/src/clockgettickssinceboot.c
b/cpukit/rtems/src/clockgettickssinceboot.c
deleted file mode 100644
index 4aced96..000
--- a/cpukit/rtems/src/clockgettickssinceboot.c
+++ /dev/null
@@ -1,31 +0,0 @@
-/**
- * @file
- *
- * @brief Obtain Ticks Since Boot
- * @ingroup ClassicClock
- */
-
-/*
- * COPYRIGHT (c) 1989-2008.
- * On-Line Applications Research Corporation (OAR).
- *
- * 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.
- */
-
-#if HAVE_CONFIG_H
-#include "config.h"
-#endif
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-rtems_interval rtems_clock_get_ticks_since_boot(void)
-{
- return _Watchdog_Ticks_since_boot;
-}
diff --git a/cpukit/score/include/rtems/score/watchdog.h
b/cpukit/score/include/rtems/score/watchdog.h
index 7327f77..06c87a1 100644
--- a/cpukit/score/include/rtems/score/watchdog.h
+++ b/cpukit/score/include/rtems/score/watchdog.h
@@ -124,6 +124,13 @@ typedef struct {
void *user_data;
} Watchdog_Control;
+/**
+ * @brief The watchdog ticks counter.
+ *
+ * With a 1ms watchdog tick, this counter overflows after 50 days since boot.
+ */
+SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
+
/**@}*/
#ifdef __cplusplus
diff --git a/cpukit/score/include/rtems/score/watchdogimpl.h
b/cpukit/score/include/rtems/score/watchdogimpl.h
index 72b6b3b..d50e279 100644
--- a/cpukit/score/include/rtems/score/watchdogimpl.h
+++ b/cpukit/score/include/rtems/score/watchdogimpl.h
@@ -85,14 +85,6 @@ SCORE_EXTERN volatile uint32_t_Watchdog_Sync_level;
SCORE_EXTERN volatile uint32_t_Watchdog_Sync_count;
/**
- * @brief The number of ticks since the system was booted.
- *
- * This contains the number of ticks since the system was booted.
- */
-
-SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
-
-/**
* @brief Watchdog chain which is managed at ticks.
*
* This is the watchdog chain which is managed at ticks.
diff --git a/doc/user/clock.t b/doc/user/clock.t
index fdbd91d..921d1cb 100644
--- a/doc/user/clock.t
+++ b/doc/user/clock.t
@@ -20,7 +20,7 @@ the clock manager are:
@item @code{@value{DIRPREFIX}clock_get_tod_timeval} - Get date and time in
timeval format
@item @code{@value{DIRPREFIX}clock_get_seconds_since_epoch} - Get seconds
since epoch
@item @code{@value{DIRPREFIX}clock_get_ticks_per_second} - Get ticks per second
-@item @code{@value{DIRPREFIX}clock_get_ticks_since_boot} - Get ticks since boot
+@item @code{@value{DIRPREFIX}clock_get_ticks_since_boot} - Get current ticks
counter value
@item @code{@value{DIRPREFIX}clock_get_uptime} - Get time since boot
@item @code{@value{DIRPREFIX}clock_get_uptime_timeval} - Get time since boot
in timeval format
@item @code{@value{DIRPREFIX}clock_get_uptime_seconds} - Get se
powerpc/gwlcfm does not compile
Hi More from the overnight build. Could someone fix this? powerpc-rtems4.11-gcc --pipe -B../../../../.././lib/ -B../../../../.././gwlcfm/lib/ -specs bsp_specs -qrtems -DPACKAGE_NAME=\"rtems-c-src-lib-libcpu-powerpc\" -DPACKAGE_TARNAME=\"rtems-c-src-lib-libcpu-powerpc\" -DPACKAGE_VERSION=\"4.10.99.0\" -DPACKAGE_STRING=\"rtems-c-src-lib-libcpu-powerpc\ 4.10.99.0\" -DPACKAGE_BUGREPORT=\"http://www.rtems.org/bugzilla\"; -DPACKAGE_URL=\"\" -I. -I../../../../../../../rtems/c/src/lib/libcpu/powerpc -isystem ../../../../.././gwlcfm/lib/include -mcpu=8540 -meabi -msdata=sysv -fno-common -msoft-float -D__ppc_generic -mstrict-align -O2 -g -fno-keep-inline-functions -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT mpc55xx/misc/flash_support.o -MD -MP -MF $depbase.Tpo -c -o mpc55xx/misc/flash_support.o ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c &&\ mv -f $depbase.Tpo $depbase.Po ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c: In function 'mpc55xx_flash_copy_op': ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:482:30: error: 'volatile struct FLASH_tag' has no member named 'BIUCR' flash_biucr_r = FLASH.BIUCR.R; ^ ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:483:14: error: 'volatile struct FLASH_tag' has no member named 'BIUCR' FLASH.BIUCR.B.PFLIM = 0; ^ ../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/misc/flash_support.c:496:9: warning: passing argument 1 of 'rtems_cache_flush_multiple_data_lines' discards 'volatile' qualifier from pointer target type [enabled by default] rtems_cache_flush_multiple_data_lines(flash, sizeof(flash[0])); -- 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
powerpc/mpc5668g does not compile
Hi Another from the build. Could someone please fix this? powerpc-rtems4.11-gcc --pipe -B../../../../../.././lib/ -B../../../../../.././mpc5668g/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -isystem ../../../../../.././mpc5668g/lib/include -mcpu=8540 -meabi -msdata=sysv -fno-common -msoft-float -D__ppc_generic -mstrict-align -O2 -g -fno-keep-inline-functions -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT smsc9218i.o -MD -MP -MF .deps/smsc9218i.Tpo -c -o smsc9218i.o `test -f 'network/smsc9218i.c' || echo '../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/'`network/smsc9218i.c ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c: In function 'smsc9218i_interrupt_init': ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9: error: variable 'direr' has initializer but incomplete type union SIU_DIRER_tag direr = MPC55XX_ZERO_FLAGS; ^ ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9: error: unknown field 'R' specified in initializer ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9: warning: excess elements in union initializer [enabled by default] ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:9: warning: (near initialization for 'direr') [enabled by default] ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/network/smsc9218i.c:1662:23: error: storage size of 'direr' isn't known union SIU_DIRER_tag direr = MPC55XX_ZERO_FLAGS; ^ -- 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 1/2] rtems: Inline rtems_clock_get_ticks_since_boot()
On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
wrote:
> Update documentation.
> ---
> cpukit/rtems/Makefile.am| 1 -
> cpukit/rtems/include/rtems/rtems/clock.h| 14 +--
> cpukit/rtems/src/clockgettickssinceboot.c | 31
> -
> cpukit/score/include/rtems/score/watchdog.h | 7 ++
> cpukit/score/include/rtems/score/watchdogimpl.h | 8 ---
> doc/user/clock.t| 31
> -
> 6 files changed, 24 insertions(+), 68 deletions(-)
> delete mode 100644 cpukit/rtems/src/clockgettickssinceboot.c
>
> diff --git a/cpukit/rtems/Makefile.am b/cpukit/rtems/Makefile.am
> index b00e251..a1fafb1 100644
> --- a/cpukit/rtems/Makefile.am
> +++ b/cpukit/rtems/Makefile.am
> @@ -151,7 +151,6 @@ librtems_a_SOURCES += src/barrierdata.c
> librtems_a_SOURCES += src/clockget.c
> librtems_a_SOURCES += src/clockgetsecondssinceepoch.c
> librtems_a_SOURCES += src/clockgettickspersecond.c
> -librtems_a_SOURCES += src/clockgettickssinceboot.c
> librtems_a_SOURCES += src/clockgettod.c
> librtems_a_SOURCES += src/clockgettodtimeval.c
> librtems_a_SOURCES += src/clockgetuptime.c
> diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
> b/cpukit/rtems/include/rtems/rtems/clock.h
> index d80218d..ff71665 100644
> --- a/cpukit/rtems/include/rtems/rtems/clock.h
> +++ b/cpukit/rtems/include/rtems/rtems/clock.h
> @@ -149,15 +149,15 @@ rtems_status_code rtems_clock_get_seconds_since_epoch(
> );
>
> /**
> - * @brief Obtain Ticks Since Boot
> + * @brief Gets the current ticks counter value.
> *
> - * This routine implements the rtems_clock_get_ticks_since_boot
> - * directive.
> - *
> - * @retval This method returns the number of ticks since boot. It cannot
> - * fail since RTEMS always keeps a running count of ticks since boot.
> + * @return The current tick counter value. With a 1ms clock tick, this
> counter
> + * overflows after 50 days since boot.
> */
> -rtems_interval rtems_clock_get_ticks_since_boot(void);
> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_get_ticks_since_boot(void)
> +{
> + return _Watchdog_Ticks_since_boot;
> +}
This should go to a new file clockimpl.h for consistency.
>
> /**
> * @brief Obtain Ticks Per Seconds
> diff --git a/cpukit/rtems/src/clockgettickssinceboot.c
> b/cpukit/rtems/src/clockgettickssinceboot.c
> deleted file mode 100644
> index 4aced96..000
> --- a/cpukit/rtems/src/clockgettickssinceboot.c
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -/**
> - * @file
> - *
> - * @brief Obtain Ticks Since Boot
> - * @ingroup ClassicClock
> - */
> -
> -/*
> - * COPYRIGHT (c) 1989-2008.
> - * On-Line Applications Research Corporation (OAR).
> - *
> - * 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.
> - */
> -
> -#if HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -rtems_interval rtems_clock_get_ticks_since_boot(void)
> -{
> - return _Watchdog_Ticks_since_boot;
> -}
> diff --git a/cpukit/score/include/rtems/score/watchdog.h
> b/cpukit/score/include/rtems/score/watchdog.h
> index 7327f77..06c87a1 100644
> --- a/cpukit/score/include/rtems/score/watchdog.h
> +++ b/cpukit/score/include/rtems/score/watchdog.h
> @@ -124,6 +124,13 @@ typedef struct {
>void *user_data;
> } Watchdog_Control;
>
> +/**
> + * @brief The watchdog ticks counter.
> + *
> + * With a 1ms watchdog tick, this counter overflows after 50 days since boot.
> + */
> +SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
> +
> /**@}*/
>
> #ifdef __cplusplus
> diff --git a/cpukit/score/include/rtems/score/watchdogimpl.h
> b/cpukit/score/include/rtems/score/watchdogimpl.h
> index 72b6b3b..d50e279 100644
> --- a/cpukit/score/include/rtems/score/watchdogimpl.h
> +++ b/cpukit/score/include/rtems/score/watchdogimpl.h
> @@ -85,14 +85,6 @@ SCORE_EXTERN volatile uint32_t_Watchdog_Sync_level;
> SCORE_EXTERN volatile uint32_t_Watchdog_Sync_count;
>
> /**
> - * @brief The number of ticks since the system was booted.
> - *
> - * This contains the number of ticks since the system was booted.
> - */
> -
> -SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
> -
> -/**
> * @brief Watchdog chain which is managed at ticks.
> *
> * This is the watchdog chain which is managed at ticks.
> diff --git a/doc/user/clock.t b/doc/user/clock.t
> index fdbd91d..921d1cb 100644
> --- a/doc/user/clock.t
> +++ b/doc/user/clock.t
> @@ -20,7 +20,7 @@ the clock manager are:
> @item @code{@value{DIRPREFIX}clock_get_tod_timeval} - Get date and time in
> timeval format
> @item @code{@value{DIRPREFIX}clock_get_seconds_since_epoch} - Get seconds
> since epoch
> @item @code{@value{DIRPREFIX}clock_get_ticks_per_second} - Get ticks per
> second
> -@item @c
powerpc/virtex5 build failure
Hi Looks like the benchmark timer code on the virtex5 is not 100% right. It is missing a symbol. /users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:77: undefined reference to `BSP_Convert_decrementer' ../../../../../virtex5/lib/librtemsbsp.a(timer.rel): In function `Read_long_timer': /users/joel/rtems-4.11-work/rtems-testing/rtems/build-powerpc-virtex5-rtems/powerpc-rtems4.11/c/virtex5/lib/libcpu/powerpc/../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc6xx/timer/timer.c:85: undefined reference to `BSP_Convert_decrementer' collect2: error: ld returned 1 exit status -- 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 2/2] rtems: Add more clock tick functions
These also would go into the clockimpl.h
On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
wrote:
> Add rtems_clock_ticks_later(), rtems_clock_ticks_later_us() and
> rtems_clock_ticks_later_us().
>
> FIXME: Patch is incomplete. Documentation and tests are missing. Just
> for API review.
> ---
> cpukit/rtems/include/rtems/rtems/clock.h | 66
>
> 1 file changed, 66 insertions(+)
>
> diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
> b/cpukit/rtems/include/rtems/rtems/clock.h
> index ff71665..cee930e 100644
> --- a/cpukit/rtems/include/rtems/rtems/clock.h
> +++ b/cpukit/rtems/include/rtems/rtems/clock.h
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include /* struct timeval */
>
> @@ -160,6 +161,71 @@ RTEMS_INLINE_ROUTINE rtems_interval
> rtems_clock_get_ticks_since_boot(void)
> }
>
> /**
> + * @brief Returns the ticks counter value delta ticks in the future.
> + *
> + * @param[in] delta The ticks delta value.
> + *
> + * @return The tick counter value delta ticks in the future.
> + */
> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later(
> + rtems_interval delta
> +)
> +{
> + return _Watchdog_Ticks_since_boot + delta;
> +}
> +
> +/**
> + * @brief Returns the ticks counter value at least delta microseconds in the
> + * future.
> + *
> + * @param[in] delta The delta value in microseconds.
> + *
> + * @return The tick counter value at least delta microseconds in the future.
> + */
> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later_us(
> + rtems_interval delta
> +)
> +{
> + rtems_interval us_per_tick =
> rtems_configuration_get_microseconds_per_tick();
> +
> + return _Watchdog_Ticks_since_boot + (delta + us_per_tick - 1) /
> us_per_tick;
> +}
> +
> +/**
> + * @brief Returns true if the current ticks counter value indicates a time
> + * before the time specified by the ticks value and false otherwise.
> + *
> + * @param[in] ticks The ticks value.
> + *
> + * This can be used to write busy loops with a timeout.
> + *
> + * @code
> + * status busy( void )
> + * {
> + * rtems_interval timeout = rtems_clock_ticks_later_us( 1 );
> + *
> + * do {
> + * if ( ok() ) {
> + * return success;
> + * }
> + * } while ( rtems_clock_ticks_before( timeout ) );
> + *
> + * return timeout;
> + * }
> + * @endcode
> + *
> + * @retval true The current ticks counter value indicates a time before the
> + * time specified by the ticks value.
> + * @retval false Otherwise.
> + */
> +RTEMS_INLINE_ROUTINE bool rtems_clock_ticks_before(
> + rtems_interval ticks
> +)
> +{
> + return ( (int32_t) ticks - (int32_t) _Watchdog_Ticks_since_boot ) > 0;
> +}
> +
> +/**
> * @brief Obtain Ticks Per Seconds
> *
> * This routine implements the rtems_clock_get_ticks_per_second
> --
> 1.8.4.5
>
> ___
> 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] bsp/tms570: implemented and tested initialization of Cortex-R performance counters.
The code is written as BSP specific now but it should work for all
Cortex-A and R based CPUs and can be moved to ARM generic place in future.
StackOverflow suggested sequences of writes to the registers required
to start counters is used.
http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
---
c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c | 88 +--
1 file changed, 84 insertions(+), 4 deletions(-)
diff --git a/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
b/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
index f25380c..3ce2f63 100644
--- a/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
+++ b/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
@@ -3,7 +3,14 @@
*
* @ingroup tms570_clocks
*
- * @brief System clocks.
+ * @brief Cortex-R performace counters
+ *
+ * The counters setup functions are these which has been suggested
+ * on StackOverflow
+ *
+ * Code is probably for use on Cortex-A without modifications as well.
+ *
+ *
http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
*/
/*
@@ -14,9 +21,6 @@
* 166 36 Praha 6
* Czech Republic
*
- * Based on LPC24xx and LPC1768 BSP
- * by embedded brains GmbH and others
- *
* 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.
@@ -27,6 +31,79 @@
#include
#include
+static int cpu_counter_initialized;
+
+
+/**
+ * @brief set mode of Cortex-R performance counters
+ *
+ * Based on example found on http://stackoverflow.com
+ *
+ * @param[in] do_reset if set, values of the counters are reset
+ * @param[in] enable_divider if set, CCNT counts clocks divided by 64
+ * @retval Void
+ */
+static inline void _CPU_Counter_init_perfcounters(
+int32_t do_reset,
+int32_t enable_divider
+)
+{
+ /* in general enable all counters (including cycle counter) */
+ int32_t value = 1;
+
+ /* peform reset */
+ if (do_reset)
+ {
+value |= 2; /* reset all counters to zero */
+value |= 4; /* reset cycle counter to zero */
+ }
+
+ if (enable_divider)
+value |= 8; /* enable "by 64" divider for CCNT */
+
+ value |= 16;
+
+ /* program the performance-counter control-register */
+ asm volatile ("mcr p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
+
+ /* enable all counters */
+ asm volatile ("mcr p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x800f));
+
+ /* clear overflows */
+ asm volatile ("mcr p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x800f));
+}
+
+/**
+ * @brief initialize Cortex-R performance counters subsystem
+ *
+ * Based on example found on http://stackoverflow.com
+ *
+ * @retval Void
+ *
+ */
+static void _CPU_Counter_initialize(void)
+{
+ rtems_interrupt_level level;
+
+ rtems_interrupt_disable(level);
+
+ if ( cpu_counter_initialized ) {
+rtems_interrupt_enable(level);
+return;
+ }
+
+ /* enable user-mode access to the performance counter */
+ asm volatile ("mcr p15, 0, %0, c9, c14, 0\n\t" :: "r"(1));
+
+ /* disable counter overflow interrupts (just in case) */
+ asm volatile ("mcr p15, 0, %0, c9, c14, 2\n\t" :: "r"(0x800f));
+
+ _CPU_Counter_init_perfcounters(false, false);
+
+ cpu_counter_initialized = 1;
+
+ rtems_interrupt_enable(level);
+}
/**
* @brief returns the actual value of Cortex-R cycle counter register
@@ -39,6 +116,9 @@
CPU_Counter_ticks _CPU_Counter_read(void)
{
uint32_t ticks;
+ if ( !cpu_counter_initialized ) {
+_CPU_Counter_initialize();
+ }
asm volatile ("mrc p15, 0, %0, c9, c13, 0\n": "=r" (ticks));
return ticks;
}
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] rtems: Inline rtems_clock_get_ticks_since_boot()
On 8/22/2014 10:18 AM, Gedare Bloom wrote:
> On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
> wrote:
>> Update documentation.
>> ---
>> cpukit/rtems/Makefile.am| 1 -
>> cpukit/rtems/include/rtems/rtems/clock.h| 14 +--
>> cpukit/rtems/src/clockgettickssinceboot.c | 31
>> -
>> cpukit/score/include/rtems/score/watchdog.h | 7 ++
>> cpukit/score/include/rtems/score/watchdogimpl.h | 8 ---
>> doc/user/clock.t| 31
>> -
>> 6 files changed, 24 insertions(+), 68 deletions(-)
>> delete mode 100644 cpukit/rtems/src/clockgettickssinceboot.c
>>
>> diff --git a/cpukit/rtems/Makefile.am b/cpukit/rtems/Makefile.am
>> index b00e251..a1fafb1 100644
>> --- a/cpukit/rtems/Makefile.am
>> +++ b/cpukit/rtems/Makefile.am
>> @@ -151,7 +151,6 @@ librtems_a_SOURCES += src/barrierdata.c
>> librtems_a_SOURCES += src/clockget.c
>> librtems_a_SOURCES += src/clockgetsecondssinceepoch.c
>> librtems_a_SOURCES += src/clockgettickspersecond.c
>> -librtems_a_SOURCES += src/clockgettickssinceboot.c
>> librtems_a_SOURCES += src/clockgettod.c
>> librtems_a_SOURCES += src/clockgettodtimeval.c
>> librtems_a_SOURCES += src/clockgetuptime.c
>> diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
>> b/cpukit/rtems/include/rtems/rtems/clock.h
>> index d80218d..ff71665 100644
>> --- a/cpukit/rtems/include/rtems/rtems/clock.h
>> +++ b/cpukit/rtems/include/rtems/rtems/clock.h
>> @@ -149,15 +149,15 @@ rtems_status_code rtems_clock_get_seconds_since_epoch(
>> );
>>
>> /**
>> - * @brief Obtain Ticks Since Boot
>> + * @brief Gets the current ticks counter value.
>> *
>> - * This routine implements the rtems_clock_get_ticks_since_boot
>> - * directive.
>> - *
>> - * @retval This method returns the number of ticks since boot. It cannot
>> - * fail since RTEMS always keeps a running count of ticks since
>> boot.
>> + * @return The current tick counter value. With a 1ms clock tick, this
>> counter
>> + * overflows after 50 days since boot.
>> */
>> -rtems_interval rtems_clock_get_ticks_since_boot(void);
>> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_get_ticks_since_boot(void)
>> +{
>> + return _Watchdog_Ticks_since_boot;
>> +}
> This should go to a new file clockimpl.h for consistency.
If it part of the public API, then it has to be in clock.h.
>> /**
>> * @brief Obtain Ticks Per Seconds
>> diff --git a/cpukit/rtems/src/clockgettickssinceboot.c
>> b/cpukit/rtems/src/clockgettickssinceboot.c
>> deleted file mode 100644
>> index 4aced96..000
>> --- a/cpukit/rtems/src/clockgettickssinceboot.c
>> +++ /dev/null
>> @@ -1,31 +0,0 @@
>> -/**
>> - * @file
>> - *
>> - * @brief Obtain Ticks Since Boot
>> - * @ingroup ClassicClock
>> - */
>> -
>> -/*
>> - * COPYRIGHT (c) 1989-2008.
>> - * On-Line Applications Research Corporation (OAR).
>> - *
>> - * 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.
>> - */
>> -
>> -#if HAVE_CONFIG_H
>> -#include "config.h"
>> -#endif
>> -
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -rtems_interval rtems_clock_get_ticks_since_boot(void)
>> -{
>> - return _Watchdog_Ticks_since_boot;
>> -}
>> diff --git a/cpukit/score/include/rtems/score/watchdog.h
>> b/cpukit/score/include/rtems/score/watchdog.h
>> index 7327f77..06c87a1 100644
>> --- a/cpukit/score/include/rtems/score/watchdog.h
>> +++ b/cpukit/score/include/rtems/score/watchdog.h
>> @@ -124,6 +124,13 @@ typedef struct {
>>void *user_data;
>> } Watchdog_Control;
>>
>> +/**
>> + * @brief The watchdog ticks counter.
>> + *
>> + * With a 1ms watchdog tick, this counter overflows after 50 days since
>> boot.
>> + */
>> +SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
>> +
>> /**@}*/
>>
>> #ifdef __cplusplus
>> diff --git a/cpukit/score/include/rtems/score/watchdogimpl.h
>> b/cpukit/score/include/rtems/score/watchdogimpl.h
>> index 72b6b3b..d50e279 100644
>> --- a/cpukit/score/include/rtems/score/watchdogimpl.h
>> +++ b/cpukit/score/include/rtems/score/watchdogimpl.h
>> @@ -85,14 +85,6 @@ SCORE_EXTERN volatile uint32_t_Watchdog_Sync_level;
>> SCORE_EXTERN volatile uint32_t_Watchdog_Sync_count;
>>
>> /**
>> - * @brief The number of ticks since the system was booted.
>> - *
>> - * This contains the number of ticks since the system was booted.
>> - */
>> -
>> -SCORE_EXTERN volatile Watchdog_Interval _Watchdog_Ticks_since_boot;
>> -
>> -/**
>> * @brief Watchdog chain which is managed at ticks.
>> *
>> * This is the watchdog chain which is managed at ticks.
>> diff --git a/doc/user/clock.t b/doc/user/clock.t
>> index fdbd91d..921d1cb 100644
>> --- a/doc/user/clock.t
>> +++ b/doc/user/clock.t
>> @@ -20,7 +20,7 @@ the clock manager are:
>> @item @code{@value{DIRPREFIX}cl
Re: [PATCH 2/2] rtems: Add more clock tick functions
On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
wrote:
> Add rtems_clock_ticks_later(), rtems_clock_ticks_later_us() and
> rtems_clock_ticks_later_us().
>
> FIXME: Patch is incomplete. Documentation and tests are missing. Just
> for API review.
> ---
> cpukit/rtems/include/rtems/rtems/clock.h | 66
>
> 1 file changed, 66 insertions(+)
>
> diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
> b/cpukit/rtems/include/rtems/rtems/clock.h
> index ff71665..cee930e 100644
> --- a/cpukit/rtems/include/rtems/rtems/clock.h
> +++ b/cpukit/rtems/include/rtems/rtems/clock.h
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include /* struct timeval */
>
> @@ -160,6 +161,71 @@ RTEMS_INLINE_ROUTINE rtems_interval
> rtems_clock_get_ticks_since_boot(void)
> }
>
> /**
> + * @brief Returns the ticks counter value delta ticks in the future.
> + *
> + * @param[in] delta The ticks delta value.
> + *
> + * @return The tick counter value delta ticks in the future.
> + */
> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later(
> + rtems_interval delta
> +)
> +{
> + return _Watchdog_Ticks_since_boot + delta;
> +}
> +
> +/**
> + * @brief Returns the ticks counter value at least delta microseconds in the
> + * future.
> + *
> + * @param[in] delta The delta value in microseconds.
> + *
> + * @return The tick counter value at least delta microseconds in the future.
> + */
> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later_us(
> + rtems_interval delta
> +)
> +{
> + rtems_interval us_per_tick =
> rtems_configuration_get_microseconds_per_tick();
> +
> + return _Watchdog_Ticks_since_boot + (delta + us_per_tick - 1) /
> us_per_tick;
> +}
> +
> +/**
> + * @brief Returns true if the current ticks counter value indicates a time
> + * before the time specified by the ticks value and false otherwise.
> + *
> + * @param[in] ticks The ticks value.
> + *
> + * This can be used to write busy loops with a timeout.
> + *
> + * @code
> + * status busy( void )
> + * {
> + * rtems_interval timeout = rtems_clock_ticks_later_us( 1 );
> + *
> + * do {
> + * if ( ok() ) {
> + * return success;
> + * }
> + * } while ( rtems_clock_ticks_before( timeout ) );
> + *
> + * return timeout;
> + * }
> + * @endcode
> + *
> + * @retval true The current ticks counter value indicates a time before the
> + * time specified by the ticks value.
> + * @retval false Otherwise.
> + */
> +RTEMS_INLINE_ROUTINE bool rtems_clock_ticks_before(
> + rtems_interval ticks
> +)
> +{
> + return ( (int32_t) ticks - (int32_t) _Watchdog_Ticks_since_boot ) > 0;
Why not just return _Watchdog_Ticks_since_boot < ticks;
> +}
> +
> +/**
> * @brief Obtain Ticks Per Seconds
> *
> * This routine implements the rtems_clock_get_ticks_per_second
> --
> 1.8.4.5
>
> ___
> 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] bsp/tms570: implemented and tested initialization of Cortex-R performance counters.
Pushed.
Followups can just be subsequent patches.
On 8/22/2014 10:20 AM, Pavel Pisa wrote:
> The code is written as BSP specific now but it should work for all
> Cortex-A and R based CPUs and can be moved to ARM generic place in future.
>
> StackOverflow suggested sequences of writes to the registers required
> to start counters is used.
>
> http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
> ---
> c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c | 88
> +--
> 1 file changed, 84 insertions(+), 4 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
> b/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
> index f25380c..3ce2f63 100644
> --- a/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
> +++ b/c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c
> @@ -3,7 +3,14 @@
> *
> * @ingroup tms570_clocks
> *
> - * @brief System clocks.
> + * @brief Cortex-R performace counters
> + *
> + * The counters setup functions are these which has been suggested
> + * on StackOverflow
> + *
> + * Code is probably for use on Cortex-A without modifications as well.
> + *
> + *
> http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor
> */
>
> /*
> @@ -14,9 +21,6 @@
> * 166 36 Praha 6
> * Czech Republic
> *
> - * Based on LPC24xx and LPC1768 BSP
> - * by embedded brains GmbH and others
> - *
> * 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.
> @@ -27,6 +31,79 @@
> #include
> #include
>
> +static int cpu_counter_initialized;
> +
> +
> +/**
> + * @brief set mode of Cortex-R performance counters
> + *
> + * Based on example found on http://stackoverflow.com
> + *
> + * @param[in] do_reset if set, values of the counters are reset
> + * @param[in] enable_divider if set, CCNT counts clocks divided by 64
> + * @retval Void
> + */
> +static inline void _CPU_Counter_init_perfcounters(
> +int32_t do_reset,
> +int32_t enable_divider
> +)
> +{
> + /* in general enable all counters (including cycle counter) */
> + int32_t value = 1;
> +
> + /* peform reset */
> + if (do_reset)
> + {
> +value |= 2; /* reset all counters to zero */
> +value |= 4; /* reset cycle counter to zero */
> + }
> +
> + if (enable_divider)
> +value |= 8; /* enable "by 64" divider for CCNT */
> +
> + value |= 16;
> +
> + /* program the performance-counter control-register */
> + asm volatile ("mcr p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
> +
> + /* enable all counters */
> + asm volatile ("mcr p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x800f));
> +
> + /* clear overflows */
> + asm volatile ("mcr p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x800f));
> +}
> +
> +/**
> + * @brief initialize Cortex-R performance counters subsystem
> + *
> + * Based on example found on http://stackoverflow.com
> + *
> + * @retval Void
> + *
> + */
> +static void _CPU_Counter_initialize(void)
> +{
> + rtems_interrupt_level level;
> +
> + rtems_interrupt_disable(level);
> +
> + if ( cpu_counter_initialized ) {
> +rtems_interrupt_enable(level);
> +return;
> + }
> +
> + /* enable user-mode access to the performance counter */
> + asm volatile ("mcr p15, 0, %0, c9, c14, 0\n\t" :: "r"(1));
> +
> + /* disable counter overflow interrupts (just in case) */
> + asm volatile ("mcr p15, 0, %0, c9, c14, 2\n\t" :: "r"(0x800f));
> +
> + _CPU_Counter_init_perfcounters(false, false);
> +
> + cpu_counter_initialized = 1;
> +
> + rtems_interrupt_enable(level);
> +}
>
> /**
> * @brief returns the actual value of Cortex-R cycle counter register
> @@ -39,6 +116,9 @@
> CPU_Counter_ticks _CPU_Counter_read(void)
> {
>uint32_t ticks;
> + if ( !cpu_counter_initialized ) {
> +_CPU_Counter_initialize();
> + }
>asm volatile ("mrc p15, 0, %0, c9, c13, 0\n": "=r" (ticks));
>return ticks;
> }
--
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 1/2] rtems: Inline rtems_clock_get_ticks_since_boot()
On Fri, Aug 22, 2014 at 11:22 AM, Joel Sherrill
wrote:
>
> On 8/22/2014 10:18 AM, Gedare Bloom wrote:
>> On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
>> wrote:
>>> Update documentation.
>>> ---
>>> cpukit/rtems/Makefile.am| 1 -
>>> cpukit/rtems/include/rtems/rtems/clock.h| 14 +--
>>> cpukit/rtems/src/clockgettickssinceboot.c | 31
>>> -
>>> cpukit/score/include/rtems/score/watchdog.h | 7 ++
>>> cpukit/score/include/rtems/score/watchdogimpl.h | 8 ---
>>> doc/user/clock.t| 31
>>> -
>>> 6 files changed, 24 insertions(+), 68 deletions(-)
>>> delete mode 100644 cpukit/rtems/src/clockgettickssinceboot.c
>>>
>>> diff --git a/cpukit/rtems/Makefile.am b/cpukit/rtems/Makefile.am
>>> index b00e251..a1fafb1 100644
>>> --- a/cpukit/rtems/Makefile.am
>>> +++ b/cpukit/rtems/Makefile.am
>>> @@ -151,7 +151,6 @@ librtems_a_SOURCES += src/barrierdata.c
>>> librtems_a_SOURCES += src/clockget.c
>>> librtems_a_SOURCES += src/clockgetsecondssinceepoch.c
>>> librtems_a_SOURCES += src/clockgettickspersecond.c
>>> -librtems_a_SOURCES += src/clockgettickssinceboot.c
>>> librtems_a_SOURCES += src/clockgettod.c
>>> librtems_a_SOURCES += src/clockgettodtimeval.c
>>> librtems_a_SOURCES += src/clockgetuptime.c
>>> diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
>>> b/cpukit/rtems/include/rtems/rtems/clock.h
>>> index d80218d..ff71665 100644
>>> --- a/cpukit/rtems/include/rtems/rtems/clock.h
>>> +++ b/cpukit/rtems/include/rtems/rtems/clock.h
>>> @@ -149,15 +149,15 @@ rtems_status_code rtems_clock_get_seconds_since_epoch(
>>> );
>>>
>>> /**
>>> - * @brief Obtain Ticks Since Boot
>>> + * @brief Gets the current ticks counter value.
>>> *
>>> - * This routine implements the rtems_clock_get_ticks_since_boot
>>> - * directive.
>>> - *
>>> - * @retval This method returns the number of ticks since boot. It cannot
>>> - * fail since RTEMS always keeps a running count of ticks since
>>> boot.
>>> + * @return The current tick counter value. With a 1ms clock tick, this
>>> counter
>>> + * overflows after 50 days since boot.
>>> */
>>> -rtems_interval rtems_clock_get_ticks_since_boot(void);
>>> +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_get_ticks_since_boot(void)
>>> +{
>>> + return _Watchdog_Ticks_since_boot;
>>> +}
>> This should go to a new file clockimpl.h for consistency.
> If it part of the public API, then it has to be in clock.h.
Ah. Oops.
-Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
BSP Build Failures Appeal
Hi The build failures I reported were with the latest RSB tools Please pitch in and let's resolve them. I left a similar build going for the weekend but using the head of gcc, newlib, and binutils. Hopefully the results are similar. Thanks. -- 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: or1k build issues
Hi, On Fri, Aug 22, 2014 at 5:11 PM, Joel Sherrill wrote: > Hi > > Some basic or1ksim BSP issues: > > (1) I can't build what is committed. > > gmake[7]: Entering directory > `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-or1k-or1k_or1ksim-rtems/or1k-rtems4.11/c/or1k_or1ksim/lib/libbsp/or1k' > Makefile:731: *** missing separator. Stop. > > I think this was an issue with the generated preinstall.am. I will be > committing an updated version. > Did not have this problem before. I pulled the latests changes and run ./bootstrap -p and ./boostrap, and I was able to build the new BSP. > (2) I built with networking on. I assume the soft float is normal > GCC code and thus the format is IEEE 754. I set a conditional > to indicate that in xdr_float.c > > (3) Can we rename or1k_or1ksim to just or1ksim? > > It seems redundant to have or1k in the name twice. Are you ok > if I rename the make/custom file? > Sure I second this opinion. > Does this impact anything else that would need to be updated? > > (4) Even with NOP addressed, spcache01 doesn't link. It is > missing a few symbols from the cache manager. > > (5) tm27.h is not provided by the BSP so none of the tmtests > or psxtmtests will compile. I added the stub version to the > Makefile.am so the tests will at least compile EXCEPT for the > spcache01 noted above. > It's provided > https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/or1k/or1ksim/Makefile.am line 33 > (6) Is the or1ksim built by RSB now? If so how? > I remember I sent Chris an old patch to do so, but I think he may be too busy to check it. If it has any problems, I will sumbit a new one. > (7) Is the simulator really just called sim? If so, that is a WAY too > generic name. If that's the case, we need to suggest to Christian > that it gets renamed something more or1k specific like or1ksim. > Depends where do you configured/built it. It's called or32-elf-sim (from old last release?) and sim from github, or vise versa. > (8) How do you debug with the simulator? > I run the following command: "or32-elf-sim -f ~/sim.cfg $PATH_TO_EXE" where ~/sim.cfg is in my home, it's also here (should I add it to RTEMS and if yes where?) https://github.com/heshamelmatary/or1k-rtems/blob/master/sim.cfg And it should wait for gdb to remotely connect at port 50001 > I think I am close to being able to help investigate but this > weekend is the Southern Brewers Festival so I probably shouldn't > touch code too much. :) > I will fixup the other issues and submit the patch. I am just a little busy with debugging the printf issue these days :) > -- > 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: tms570 Cortex-R performance counters and some ideas related to RTEMS timekeeping code
Hello Joel, On Friday 22 of August 2014 17:25:24 Joel Sherrill wrote: > Pushed. > > Followups can just be subsequent patches. thanks, you are faster than light ... As for the RTEMS timekeeping code, I can imagine how it could look better. I do not like Clock_driver_nanoseconds_since_last_tick. I am not even sure if it is really used by TOD (i.e. in ticker test seems to print rounded values on our board). In the fact I would like to see RTEMS to work completely tickless on hardware with modern free runing timebase and easily updated compare event hardware. That would allow to implement all POSIX time related functions with resolution limited only by hardware. Scheduler is a question. Wen more than one task of same priority are ready to run then tick is easiest but even in such case slice time can be computed and only event for its overflow timer event is set. But all that is huge amount of work. I would start with easier side now. It is necessary to have reliable timebase. Consider 64 bit value running at some clock source speed. It is really hard to have that reliable on PC hardware, the common base 8254 can be used for that but access is horribly slow. All other mechanisms (HPET, TSC) are problematic - need probe and check that they are correct and synchronous between cores, do not change with sleep modes etc. Really difficult task which is solved by thousands lines of code by Linux kernel. But ARM and PowerPC based systems usually provide reasonable timer source register which is synchronized over all cores. Unfortuantelly, ARM ones provide usually only 32 bits wide register. I have solved problem how to extend that 32 bit counter to 64 bit for one my friend who worked at BlackBerry. Their phones platform uses Cortex-A and QNX. The design constrains has been given by usecase - userspace events timestamping in QML profiller. This adds constrain that code can be called on more cores concurrently, using mutex would degrade performance horribly, privileged instructions cannot be used and value available from core was only 32 bit. I have designed for him attached code fragments and he has written some Qt derived code which is was used in Q10 phone debugging builds. The main ideas is to write extension to more than 60 bits without locking and use GCC builtin atomic support to ensure that counter overflow results only in single increment of higher value part. The only requirement for correct function is that clockCyclesExt() is called at least once per half of the counter overflow period and its execution is not interrupted for longer than equivalent time. Code even minimizes cache write contention cases. What do you think about use of this approach in RTEMS? Then next step is to base timing on values which are not based on the ticks. I have seen that discussion about NTP time format (integer seconds + 1/2^32 fractions). Other option is 64bit nsec which is better regard 2038 overflow problem. The priority queue for finegrained timers ordering is tough task. It would worth to have all operations with additional paremeter about required precision for each interval/time event etc ... But that is for longer discussion and incremental solution. I cannot provide my full time for such enhancements anyway. But it could be nice project if funding is found. I have friend who has grants from ESA to develop theory for precise time sources fussion (atomic clocks etc) and works on real hardware for satelite based clock synchronization too. We have spoken about Linux kernel NTP time synchronization and PLL loop long time ago and both gone to same conclusion how it should be done right way. I would be interresting to have this solution in RTEMS as well. But to do it right it would require some agency/company funded project. We have even networking cards with full IEEE-1588 HW support there for Intel and some articles about our findings regarding problem to synchronize time where most problematic part are latencies between ETHERNET card hardware and CPU core. They are even more problematic than precise time over local ETHERNET LAN ... So I think that there is enough competent people to come with something usesfull. But most of them cannot afford to work on it only for their pleassure. OK, that some dump of my ideas. I need to switch to other HW testing now to sustain our company and university project above sea level. Best wishes, Pavel /* gcc -Wall atomic-extend-cc.c */ /*** * * * Copyright (c) 2014, Pavel Pisa * * All rights reserved. * * * * 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 * * -
Re: tms570 Cortex-R performance counters and some ideas related to RTEMS timekeeping code
On August 22, 2014 11:44:11 AM CDT, Pavel Pisa wrote: >Hello Joel, > >On Friday 22 of August 2014 17:25:24 Joel Sherrill wrote: >> Pushed. >> >> Followups can just be subsequent patches. > >thanks, you are faster than light ... Just truing to wrap up things on a Friday. :) >As for the RTEMS timekeeping code, I can imagine how it could >look better. I do not like Clock_driver_nanoseconds_since_last_tick. >I am not even sure if it is really used by TOD (i.e. in ticker test >seems to print rounded values on our board). The Classic API get time method used returns TOD in a format with seconds and ticks since the last second. The print in that test only prints seconds. There is a nanoseconds sample which prints at higher granularity. > >In the fact I would like to see RTEMS to work completely tickless >on hardware with modern free runing timebase and easily updated >compare event hardware. That would allow to implement all POSIX time >related functions with resolution limited only by hardware. > Agreed. >Scheduler is a question. Wen more than one task of same priority >are ready to run then tick is easiest but even in such case >slice time can be computed and only event for its overflow timer event >is set. > We just need to take that into account for that as an input for calculating when the next tick occurs. I think time slice is the only factor other than the watchdog timers. >But all that is huge amount of work. Yep. But we can identify a development path where it is a sequence of smallish steps. >I would start with easier side now. It is necessary to have reliable >timebase. Consider 64 bit value running at some clock source speed. >It is really hard to have that reliable on PC hardware, the common >base 8254 can be used for that but access is horribly slow. All other >mechanisms (HPET, TSC) are problematic - need probe and check that >they are correct and synchronous between cores, do not change with >sleep modes etc. Really difficult task which is solved by thousands >lines of code by Linux kernel. > >But ARM and PowerPC based systems usually provide reasonable >timer source register which is synchronized over all cores. >Unfortuantelly, ARM ones provide usually only 32 bits wide register. >I have solved problem how to extend that 32 bit counter to 64 >bit for one my friend who worked at BlackBerry. Their phones platform >uses Cortex-A and QNX. The design constrains has been given >by usecase - userspace events timestamping in QML profiller. >This adds constrain that code can be called on more cores concurrently, >using mutex would degrade performance horribly, privileged instructions >cannot be used and value available from core was only 32 bit. > >I have designed for him attached code fragments and he has written >some Qt derived code which is was used in Q10 phone debugging builds. > >The main ideas is to write extension to more than 60 bits without >locking and use GCC builtin atomic support to ensure that counter >overflow >results only in single increment of higher value part. > >The only requirement for correct function is that clockCyclesExt() >is called at least once per half of the counter overflow period >and its execution is not interrupted for longer than equivalent time. >Code even minimizes cache write contention cases. > >What do you think about use of this approach in RTEMS? Sounds reasonable. The counter overflow period should be relatively long so this should be considered when determining the maximum length of time allowed between ticks. >Then next step is to base timing on values which are not based on >the ticks. I have seen that discussion about NTP time format >(integer seconds + 1/2^32 fractions). Other option is 64bit nsec >which is better regard 2038 overflow problem. The priority queue >for finegrained timers ordering is tough task. It would worth >to have all operations with additional paremeter about required >precision >for each interval/time event etc ... I have discussed offline converting the delta chains in the watchdog to use timestamps. This would also let us do higher granularity absolute time events. Right now the TOD chain is second granularity. But I don't have any good solutions to that. But it could be a discrete unit of work. >But that is for longer discussion and incremental solution. > >I cannot provide my full time for such enhancements anyway. None of us can. We have to have a plan with the steps and nibble. >But it could be nice project if funding is found. I have friend >who has grants from ESA to develop theory for precise time sources >fussion (atomic clocks etc) and works on real hardware for satelite >based clock synchronization too. We have spoken about Linux kernel >NTP time synchronization and PLL loop long time ago and both gone >to same conclusion how it should be done right way. I would be >interresting >to have this solution in RTEMS as well. But to do it right it would >require some agency/company funded projec
Re: tms570 Cortex-R performance counters and some ideas related to RTEMS timekeeping code
On Fri, Aug 22, 2014 at 1:45 PM, Joel Sherrill wrote: > > > On August 22, 2014 11:44:11 AM CDT, Pavel Pisa wrote: >>Hello Joel, >> >>On Friday 22 of August 2014 17:25:24 Joel Sherrill wrote: >>> Pushed. >>> >>> Followups can just be subsequent patches. >> >>thanks, you are faster than light ... > > Just truing to wrap up things on a Friday. :) > >>As for the RTEMS timekeeping code, I can imagine how it could >>look better. I do not like Clock_driver_nanoseconds_since_last_tick. >>I am not even sure if it is really used by TOD (i.e. in ticker test >>seems to print rounded values on our board). > > The Classic API get time method used returns TOD in a format with seconds and > ticks since the last second. The print in that test only prints seconds. > There is a nanoseconds sample which prints at higher granularity. > Hi Pavel, you may also be interested in the recent mailing list thread with subject: [Bug 2180] New: _TOD_Get_with_nanoseconds() is broken on SMP Sebastian suggested we adopt FreeBSD mechanisms for our clock drivers. -Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] rtems: Add more clock tick functions
On Friday 22 of August 2014 17:24:41 Gedare Bloom wrote:
> On Fri, Aug 22, 2014 at 11:12 AM, Sebastian Huber
>
> wrote:
> > Add rtems_clock_ticks_later(), rtems_clock_ticks_later_us() and
> > rtems_clock_ticks_later_us().
> >
> > FIXME: Patch is incomplete. Documentation and tests are missing. Just
> > for API review.
> > ---
> > cpukit/rtems/include/rtems/rtems/clock.h | 66
> > 1 file changed, 66 insertions(+)
> >
> > diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
> > b/cpukit/rtems/include/rtems/rtems/clock.h index ff71665..cee930e 100644
> > --- a/cpukit/rtems/include/rtems/rtems/clock.h
> > +++ b/cpukit/rtems/include/rtems/rtems/clock.h
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include /* struct timeval */
> >
> > @@ -160,6 +161,71 @@ RTEMS_INLINE_ROUTINE rtems_interval
> > rtems_clock_get_ticks_since_boot(void) }
> >
> > /**
> > + * @brief Returns the ticks counter value delta ticks in the future.
> > + *
> > + * @param[in] delta The ticks delta value.
> > + *
> > + * @return The tick counter value delta ticks in the future.
> > + */
> > +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later(
> > + rtems_interval delta
> > +)
> > +{
> > + return _Watchdog_Ticks_since_boot + delta;
> > +}
> > +
> > +/**
> > + * @brief Returns the ticks counter value at least delta microseconds in
> > the + * future.
> > + *
> > + * @param[in] delta The delta value in microseconds.
> > + *
> > + * @return The tick counter value at least delta microseconds in the
> > future. + */
> > +RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_ticks_later_us(
> > + rtems_interval delta
> > +)
> > +{
> > + rtems_interval us_per_tick =
> > rtems_configuration_get_microseconds_per_tick(); +
> > + return _Watchdog_Ticks_since_boot + (delta + us_per_tick - 1) /
> > us_per_tick; +}
> > +
> > +/**
> > + * @brief Returns true if the current ticks counter value indicates a
> > time + * before the time specified by the ticks value and false
> > otherwise. + *
> > + * @param[in] ticks The ticks value.
> > + *
> > + * This can be used to write busy loops with a timeout.
> > + *
> > + * @code
> > + * status busy( void )
> > + * {
> > + * rtems_interval timeout = rtems_clock_ticks_later_us( 1 );
> > + *
> > + * do {
> > + * if ( ok() ) {
> > + * return success;
> > + * }
> > + * } while ( rtems_clock_ticks_before( timeout ) );
> > + *
> > + * return timeout;
> > + * }
> > + * @endcode
> > + *
> > + * @retval true The current ticks counter value indicates a time before
> > the + * time specified by the ticks value.
> > + * @retval false Otherwise.
> > + */
> > +RTEMS_INLINE_ROUTINE bool rtems_clock_ticks_before(
> > + rtems_interval ticks
> > +)
> > +{
> > + return ( (int32_t) ticks - (int32_t) _Watchdog_Ticks_since_boot ) > 0;
>
> Why not just return _Watchdog_Ticks_since_boot < ticks;
For sure not, to have correctly working overflow arithmetics
it is required to use subtraction of unsigned types and then
to limit result to signed type of same size.
Overflow of subtraction of signed types is undefined according
to the C standard. The implementation causing exception is correct
but seldom used (can be enabled for MIPS on GCC). But comparison
is often optimized. So for example next code
int fnc(int32_t x)
{
if ((x + 0x7fff) < -0x1000) {
return 1;
} else {
return 0;
}
}
can be legally optimized to
int fnc(int32_t x)
{
return 0;
}
because for any valid x number <-0x8000;0x7fff>
arithmetic value of the sum cannot be smaller than -1.
And this kind of optimization is seen in reality.
So even Sebastian's above code which tries to prevent
overflow case can be misoptimized and broken.
Correct is
return ( (int32_t) ( (uint32_t) ticks - (uint32_t) _Watchdog_Ticks_since_boot
) ) > 0;
Because I have worry that I can often write code incorrectly
or compare types of different sizes I use special macros to declare
overflow arithmetics in my code
http://sourceforge.net/p/ulan/ulut/ci/master/tree/ulut/ul_utdefs.h#l73
May it be that my macros are real overkill but definition of
#define ul_cyclic_gt_32(x,y) \
((int32_t)((uint32_t)(x)-(uint32_t)(y))>0)
#define ul_cyclic_gt_64(x,y) \
((int64_t)((uint64_t)(x)-(uint64_t)(y))>0)
would worth to be included in RTEMS.
If you want to reuse som code from uLUt library directly
then its license tries to be specially friendly to RTEMS.
It lists MPL (Mozilla Public License) option which should
be OK and I declare there that GPL with linking exception
is OK for my code which declares MPL+GPL as well.
The lengthy discussion of above arithmetic operations did happen
on Linux kernel lists two or three years ago. Many more years ago,
I have discussed the same problem when IMX1 timers been revwitten
for high resolution support. And I have even experienced that time
misfunction on real hardware in some situations.
This kind of bugs are very h
[PATCH 1/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.
---
testsuites/sptests/spcache01/init.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/testsuites/sptests/spcache01/init.c
b/testsuites/sptests/spcache01/init.c
index 2c9d184..ad9b54f 100644
--- a/testsuites/sptests/spcache01/init.c
+++ b/testsuites/sptests/spcache01/init.c
@@ -27,7 +27,11 @@
const char rtems_test_name[] = "SPCACHE 1";
-#define I() __asm__ volatile ("nop")
+#ifdef __or1k__
+ #define I() __asm__ volatile ("l.nop")
+#else
+ #define I() __asm__ volatile ("nop")
+#endif
#define I8() I(); I(); I(); I(); I(); I(); I(); I()
--
1.9.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/5] libcpu: Add new entry for or1k cpu and include cache manager stubs.
--- c/src/lib/libcpu/or1k/Makefile.am | 20 +++ c/src/lib/libcpu/or1k/configure.ac | 31 + c/src/lib/libcpu/or1k/preinstall.am | 24 ++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 11 ++ 4 files changed, 86 insertions(+) create mode 100644 c/src/lib/libcpu/or1k/Makefile.am create mode 100644 c/src/lib/libcpu/or1k/configure.ac create mode 100644 c/src/lib/libcpu/or1k/preinstall.am create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache_.h diff --git a/c/src/lib/libcpu/or1k/Makefile.am b/c/src/lib/libcpu/or1k/Makefile.am new file mode 100644 index 000..99b868e --- /dev/null +++ b/c/src/lib/libcpu/or1k/Makefile.am @@ -0,0 +1,20 @@ +ACLOCAL_AMFLAGS = -I ../../../aclocal + +include $(top_srcdir)/../../../automake/compile.am + +CLEANFILES = +DISTCLEANFILES = +noinst_PROGRAMS = + +include_libcpudir = $(includedir)/libcpu + +## shared/cache +include_libcpu_HEADERS = ../shared/include/cache.h +noinst_PROGRAMS += shared/cache.rel +shared_cache_rel_SOURCES = ../shared/src/no_cache.c shared/cache/cache_.h +shared_cache_rel_CPPFLAGS = $(AM_CPPFLAGS) -I$(srcdir)/shared/cache +shared_cache_rel_LDFLAGS = $(RTEMS_RELLDFLAGS) + +include $(srcdir)/preinstall.am + +include $(top_srcdir)/../../../automake/local.am diff --git a/c/src/lib/libcpu/or1k/configure.ac b/c/src/lib/libcpu/or1k/configure.ac new file mode 100644 index 000..c87c0f1 --- /dev/null +++ b/c/src/lib/libcpu/or1k/configure.ac @@ -0,0 +1,31 @@ +## Process this file with autoconf to produce a configure script. + +AC_PREREQ([2.69]) +AC_INIT([rtems-c-src-lib-libcpu-or1k],[_RTEMS_VERSION],[http://www.rtems.org/bugzilla]) +RTEMS_TOP([../../../../..],[../../..]) + +RTEMS_CANONICAL_TARGET_CPU + +AM_INIT_AUTOMAKE([no-define foreign subdir-objects 1.12.2]) +AM_MAINTAINER_MODE + +RTEMS_ENV_RTEMSBSP + +RTEMS_PROJECT_ROOT + +RTEMS_PROG_CC_FOR_TARGET +AM_PROG_CC_C_O +RTEMS_CANONICALIZE_TOOLS +RTEMS_PROG_CCAS + +# At this time all models should use the shared directory so do this +AM_CONDITIONAL(shared, true) + +AC_PATH_PROG([AMPOLISH3],[ampolish3],[]) + +RTEMS_AMPOLISH3 + +# Explicitly list all Makefiles here +AC_CONFIG_FILES([Makefile +]) +AC_OUTPUT diff --git a/c/src/lib/libcpu/or1k/preinstall.am b/c/src/lib/libcpu/or1k/preinstall.am new file mode 100644 index 000..c27c429 --- /dev/null +++ b/c/src/lib/libcpu/or1k/preinstall.am @@ -0,0 +1,24 @@ +## Automatically generated by ampolish3 - Do not edit + +if AMPOLISH3 +$(srcdir)/preinstall.am: Makefile.am + $(AMPOLISH3) $(srcdir)/Makefile.am > $(srcdir)/preinstall.am +endif + +all-am: $(PREINSTALL_FILES) + +PREINSTALL_FILES = +CLEANFILES += $(PREINSTALL_FILES) + +PREINSTALL_DIRS = +DISTCLEANFILES += $(PREINSTALL_DIRS) + +$(PROJECT_INCLUDE)/libcpu/$(dirstamp): + @$(MKDIR_P) $(PROJECT_INCLUDE)/libcpu + @: > $(PROJECT_INCLUDE)/libcpu/$(dirstamp) +PREINSTALL_DIRS += $(PROJECT_INCLUDE)/libcpu/$(dirstamp) + +$(PROJECT_INCLUDE)/libcpu/cache.h: ../shared/include/cache.h $(PROJECT_INCLUDE)/libcpu/$(dirstamp) + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/libcpu/cache.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/libcpu/cache.h + diff --git a/c/src/lib/libcpu/or1k/shared/cache/cache_.h b/c/src/lib/libcpu/or1k/shared/cache/cache_.h new file mode 100644 index 000..8ba2ca4 --- /dev/null +++ b/c/src/lib/libcpu/or1k/shared/cache/cache_.h @@ -0,0 +1,11 @@ +/* + * or1k Cache Manager Support + */ + +#ifndef __OR1K_CACHE_H +#define __OR1K_CACHE_H + +#include + +#endif +/* end of include file */ -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/5] Rename or1k_or1ksim BSP to or1ksim
--- c/src/lib/libbsp/or1k/or1ksim/make/custom/or1k_or1ksim.cfg | 7 --- c/src/lib/libbsp/or1k/or1ksim/make/custom/or1ksim.cfg | 7 +++ 2 files changed, 7 insertions(+), 7 deletions(-) delete mode 100644 c/src/lib/libbsp/or1k/or1ksim/make/custom/or1k_or1ksim.cfg create mode 100644 c/src/lib/libbsp/or1k/or1ksim/make/custom/or1ksim.cfg diff --git a/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1k_or1ksim.cfg b/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1k_or1ksim.cfg deleted file mode 100644 index fff00ae..000 --- a/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1k_or1ksim.cfg +++ /dev/null @@ -1,7 +0,0 @@ -include $(RTEMS_ROOT)/make/custom/default.cfg - -RTEMS_CPU = or1k - -CPU_CFLAGS = -O2 - -CFLAGS_OPTIMIZE_V ?= -O0 -g diff --git a/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1ksim.cfg b/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1ksim.cfg new file mode 100644 index 000..fff00ae --- /dev/null +++ b/c/src/lib/libbsp/or1k/or1ksim/make/custom/or1ksim.cfg @@ -0,0 +1,7 @@ +include $(RTEMS_ROOT)/make/custom/default.cfg + +RTEMS_CPU = or1k + +CPU_CFLAGS = -O2 + +CFLAGS_OPTIMIZE_V ?= -O0 -g -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/5] Add or1k to the list of targets that use IEEE 754 in xdr_float.c
--- cpukit/librpc/src/xdr/xdr_float.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cpukit/librpc/src/xdr/xdr_float.c b/cpukit/librpc/src/xdr/xdr_float.c index 8640058..cf081a7 100644 --- a/cpukit/librpc/src/xdr/xdr_float.c +++ b/cpukit/librpc/src/xdr/xdr_float.c @@ -69,6 +69,7 @@ static char *rcsid = "$FreeBSD: src/lib/libc/xdr/xdr_float.c,v 1.7 1999/08/28 00 defined(__mips__) || defined(__moxie__) || \ defined(__nios2__) || \ defined(__ns32k__) || \ +defined(__or1k__) || \ defined(__sparc__) || \ defined(__ppc__) || defined(__PPC__) || \ defined(__sh__) || \ -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/5] or1ksim BSP: Include cache manager stubs, and re-generate preinstall.am files.
--- c/src/lib/libbsp/or1k/or1ksim/Makefile.am | 9 +++- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 72 - c/src/lib/libbsp/or1k/preinstall.am | 3 +- 3 files changed, 48 insertions(+), 36 deletions(-) diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index d5eb10c..f1315c4 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -9,7 +9,7 @@ ACLOCAL_AMFLAGS = -I ../../../../aclocal include $(top_srcdir)/../../../../automake/compile.am include_bspdir = $(includedir)/bsp -#include_libcpudir = $(includedir)/libcpu +include_libcpudir = $(includedir)/libcpu dist_project_lib_DATA = bsp_specs @@ -21,7 +21,6 @@ include_bsp_HEADERS = include_HEADERS = include/bsp.h nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h - include_bsp_HEADERS += ../shared/include/linker-symbols.h include_bsp_HEADERS += ../../../libbsp/shared/include/mm.h include_bsp_HEADERS += ../../shared/include/utility.h @@ -99,6 +98,12 @@ libbsp_a_SOURCES += ../../shared/src/irq-default-handler.c libbsp_a_SOURCES += ../../shared/src/irq-generic.c libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c + +# Cache +libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c +libbsp_a_SOURCES += ../../shared/include/cache_.h +libbsp_a_CPPFLAGS = -I$(srcdir)/../../shared/include + ### # Special Rules # ### diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index e75733c..a83e053 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -2,113 +2,119 @@ if AMPOLISH3 $(srcdir)/preinstall.am: Makefile.am - $(AMPOLISH3) $(srcdir)/Makefile.am > $(srcdir)/preinstall.am + $(AMPOLISH3) $(srcdir)/Makefile.am > $(srcdir)/preinstall.am endif PREINSTALL_DIRS = DISTCLEANFILES += $(PREINSTALL_DIRS) -all-local: $(TMPINSTALL_FILES) - -TMPINSTALL_FILES = -CLEANFILES = $(TMPINSTALL_FILES) - all-am: $(PREINSTALL_FILES) PREINSTALL_FILES = -CLEANFILES += $(PREINSTALL_FILES) +CLEANFILES = $(PREINSTALL_FILES) + +all-local: $(TMPINSTALL_FILES) + +TMPINSTALL_FILES = +CLEANFILES += $(TMPINSTALL_FILES) $(PROJECT_LIB)/$(dirstamp): - @$(MKDIR_P) $(PROJECT_LIB) - @: > $(PROJECT_LIB)/$(dirstamp) + @$(MKDIR_P) $(PROJECT_LIB) + @: > $(PROJECT_LIB)/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_LIB)/$(dirstamp) $(PROJECT_INCLUDE)/$(dirstamp): - @$(MKDIR_P) $(PROJECT_INCLUDE) - @: > $(PROJECT_INCLUDE)/$(dirstamp) + @$(MKDIR_P) $(PROJECT_INCLUDE) + @: > $(PROJECT_INCLUDE)/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_INCLUDE)/$(dirstamp) $(PROJECT_INCLUDE)/bsp/$(dirstamp): - @$(MKDIR_P) $(PROJECT_INCLUDE)/bsp - @: > $(PROJECT_INCLUDE)/bsp/$(dirstamp) + @$(MKDIR_P) $(PROJECT_INCLUDE)/bsp + @: > $(PROJECT_INCLUDE)/bsp/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_INCLUDE)/bsp/$(dirstamp) +$(PROJECT_INCLUDE)/libcpu/$(dirstamp): + @$(MKDIR_P) $(PROJECT_INCLUDE)/libcpu + @: > $(PROJECT_INCLUDE)/libcpu/$(dirstamp) +PREINSTALL_DIRS += $(PROJECT_INCLUDE)/libcpu/$(dirstamp) + $(PROJECT_LIB)/bsp_specs: bsp_specs $(PROJECT_LIB)/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_LIB)/bsp_specs + $(INSTALL_DATA) $< $(PROJECT_LIB)/bsp_specs PREINSTALL_FILES += $(PROJECT_LIB)/bsp_specs $(PROJECT_INCLUDE)/bsp.h: include/bsp.h $(PROJECT_INCLUDE)/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp.h $(PROJECT_INCLUDE)/bsp/bootcard.h: ../../shared/include/bootcard.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/bootcard.h + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/bootcard.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/bootcard.h $(PROJECT_INCLUDE)/bsp/linker-symbols.h: ../shared/include/linker-symbols.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/linker-symbols.h + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/linker-symbols.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/linker-symbols.h $(PROJECT_INCLUDE)/bsp/mm.h: ../../../libbsp/shared/include/mm.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/mm.h + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/mm.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/mm.h $(PROJECT_INCLUDE)/bsp/utility.h: ../../shared/include/utility.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) - $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/utility.h + $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/utility.h PREINSTALL_FILES
Re: Using rtl-host in covor - some questions
Hi, thanks for all your replies. 2014-08-14 15:38 GMT+02:00 Joel Sherrill : > > On 8/13/2014 10:13 PM, Chris Johns wrote: > > On 14/08/2014 7:34 am, Joel Sherrill wrote: > >> The other part is in covoar itself. As it processes each exe and builds > >> the internal > >> database of information, it needs the physical address of each method of > >> interest > >> in that particular exe. That is done by an invocation of nm with some > >> magic processing > >> afterwards. This could be done with libelf I think. > > The rtl-host is a wrapper to libelf which is included in the rtl-host > > code we are not dependent on host specifics or versions. > Currently covoar uses system() to invoke nm (maybe with a sed) and then > process it > using regular file operations. > > Not exactly, currently there is do_coverage.sh shell script, where nm is invoked and its output is filtered with grep and sed before running covoar. Filtered output is written to text file which is passed to covoar by configuration file. Personally, I don't see much difference between invoking nm and > rtl-host. Either > will require a system and then loading the symbol set from a file. On a > large set > of executables, this may be a large time consumer. It would be better to > directly > use libelf to read the symbols. It should simplify and speed things up. > >>> But I also wonder if it would not be better to focus on changing flow > >>> of covoar - to avoid multiple runs (one for each symbol set as it > >>> would be now), because it takes quite long. I think it should be done > >>> in such way, that covoar reads symbol sets configuration file, runs > >>> analysis and takes data for all desired symbols from all sets and > >>> finally performs multiple reporting part, generating simple, generic > >>> output for each symbols set. > >>> > >> Then covoar knows what purpose and scope of the reports are. As it > >> stands now, covoar knows NOTHING > >> about RTEMS. Let's keep it that way. > > Out of interest what is config file format for covoar ? I have added INI > > file support to the rtl-host repo and it seems stable and flexible. > I think it is just name=value without sections. I honestly don't recall > but it is not fancy. > It could easily be switched to .ini. >> covoar gets slower as the set of symbols and tests grows. The standard > >> run now already does at > >> least two covoar runs. Once for "all" and one for "core". The build and > >> test execution time dominates. > > Where is bottleneck ? The RTL code uses an STL map for symbol look up. > See above. I think executing nm on each exe with whatever filter > commands and > then reading them. Using libelf directly will help a lot. > > I don't recall any other hot spots but that there are places where you > have to > cycle over all exe's for all symbols of interest. That is obviously > O( num exes * num syms) but I don't think it is the big issue. I think > the first > issue is just like make vs waf. Avoid doing system() and parsing output > files > 500 times (# tests) and just read the symbol table directly. That has to > be a > huge time saver > >> As we process smaller sets of symbols, covoar will be faster anyway. > >> Besides, if it is slow enough, > >> eventually we will profile and fix it. :) > >>> Another job I am thinking about doing next is adding more bsps support > >>> for coverage and getting things working on more bsps. This should be > >>> quite simple. > >>> > >> This requires the simulator support. But you should be able to do arm > >> and x86 with qemu. > >>> There is still one problem waiting for decision :-) What with rtems > >>> grub boot img for qemu? How should we integrate it into rtems-tools? > >>> > >> Chris? > > Ah yes. I think we should download an image from a know spot but I have > > not looked into how to do this with the RSB. > Where should I place this image? Is there any RTEMS ftp or something like this where could I put it, or maybe should I just push it to some Dropbox or sth and download it with RSB? > > > > Maybe building grub from source is possible but that can be something > > for another day. > > > > Chris > > -- > 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 > > Chris, should I move rtl-host repo into rtems-tools or wait for your action? I need it to get covoar-related work ready to commit. I am now trying to get things working together and would like to prepare patches to show them working on the end of SOCIS period. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
