Re: [PATCH] score: Add missing define to cache manager
Hello Daniel, thanks for the fix: http://git.rtems.org/rtems/commit/?id=e7a42a0cfbafc2311888780b086010aef6556311 -- 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: powerpc/gwlcfm does not compile
Fixed: http://git.rtems.org/rtems/commit/?id=0a314839012ab765a70df05eaadc4dba7440223b -- 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: powerpc/mpc5668g does not compile
Fixed: http://git.rtems.org/rtems/commit/?id=f3237a3c3bbe5a298b5ae30a36b24e6f601c6f8b -- 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: [rtems commit] bsp/sparc: Flush icache before first time enabling interrupts
This breaks at least SIS with --enable-smp: gmake[6]: Entering directory `/scratch/git-rtems-testing/rtems/build-sparc-sis-rtems/sparc-rtems4.11/c/sis/testsuites/samples/hello' sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I. -I../../../../../../../rtems/c/src/../../testsuites/samples/hello -I.. -mcpu=cypress -O0 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c mv -f .deps/init.Tpo .deps/init.Po sparc-rtems4.11-gcc -B../../../../../sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress -O0 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o hello.exe init.o ../../../../../sis/lib/librtemscpu.a(libscore_a-threadstartmultitasking.o): In function `_Thread_Start_multitasking': /scratch/git-rtems-testing/rtems/build-sparc-sis-rtems/sparc-rtems4.11/c/sis/cpukit/score/../../../../../../rtems/c/src/../../cpukit/score/src/threadstartmultitasking.c:78: undefined reference to `_BSP_Start_multitasking' On 22/08/14 13:07, Daniel Hellstrom wrote: Module:rtems Branch:master Commit:54f3476e2493a957efb0e30c77226d496e7fc5a1 Changeset: http://git.rtems.org/rtems/commit/?id=54f3476e2493a957efb0e30c77226d496e7fc5a1 Author:Daniel Cederman Date: Thu Jul 3 11:18:55 2014 +0200 bsp/sparc: Flush icache before first time enabling interrupts A secondary processor might miss changes done to the trap table if the instruction cache is not flushed. Once interrupts are enabled any other required cache flushes can be ordered via the cache manager. -- 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
[PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
---
cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h
b/cpukit/score/cpu/sparc/rtems/score/cpu.h
index 9c38b55..d4c2ef0 100644
--- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
@@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current
__asm__( "g6" );
void _CPU_SMP_Send_interrupt( uint32_t target_processor_index );
+ #if defined(__leon__)
void _BSP_Start_multitasking( Context_Control *heir )
RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
#define _CPU_Start_multitasking _BSP_Start_multitasking
+ #endif
static inline void _CPU_SMP_Processor_event_broadcast( void )
{
--
1.7.9.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] rtems: Add more clock tick functions
Add rtems_clock_tick_later(), rtems_clock_tick_later_usec() and
rtems_clock_tick_before().
---
cpukit/rtems/include/rtems/rtems/clock.h | 71 +
doc/user/clock.t | 104 +++
testsuites/sptests/sp37/init.c | 55
testsuites/sptests/sp37/sp37.doc | 5 ++
testsuites/sptests/sp37/system.h | 4 ++
5 files changed, 239 insertions(+)
diff --git a/cpukit/rtems/include/rtems/rtems/clock.h
b/cpukit/rtems/include/rtems/rtems/clock.h
index ff71665..7595f5e 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,76 @@ 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_tick_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_in_usec The delta value in microseconds.
+ *
+ * @return The tick counter value at least delta microseconds in the future.
+ */
+RTEMS_INLINE_ROUTINE rtems_interval rtems_clock_tick_later_usec(
+ rtems_interval delta_in_usec
+)
+{
+ rtems_interval us_per_tick = rtems_configuration_get_microseconds_per_tick();
+
+ /*
+ * Add one additional tick, since we don't know the time to the clock next
+ * tick.
+ */
+ return _Watchdog_Ticks_since_boot
++ (delta_in_usec + us_per_tick - 1) / us_per_tick + 1;
+}
+
+/**
+ * @brief Returns true if the current ticks counter value indicates a time
+ * before the time specified by the tick value and false otherwise.
+ *
+ * @param[in] tick The tick value.
+ *
+ * This can be used to write busy loops with a timeout.
+ *
+ * @code
+ * status busy( void )
+ * {
+ * rtems_interval timeout = rtems_clock_tick_later_usec( 1 );
+ *
+ * do {
+ * if ( ok() ) {
+ * return success;
+ * }
+ * } while ( rtems_clock_tick_before( timeout ) );
+ *
+ * return timeout;
+ * }
+ * @endcode
+ *
+ * @retval true The current ticks counter value indicates a time before the
+ * time specified by the tick value.
+ * @retval false Otherwise.
+ */
+RTEMS_INLINE_ROUTINE bool rtems_clock_tick_before(
+ rtems_interval tick
+)
+{
+ return (int32_t) ( tick - _Watchdog_Ticks_since_boot ) > 0;
+}
+
+/**
* @brief Obtain Ticks Per Seconds
*
* This routine implements the rtems_clock_get_ticks_per_second
diff --git a/doc/user/clock.t b/doc/user/clock.t
index 921d1cb..1e821ad 100644
--- a/doc/user/clock.t
+++ b/doc/user/clock.t
@@ -21,6 +21,9 @@ the clock manager are:
@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 current ticks
counter value
+@item @code{@value{DIRPREFIX}clock_tick_later} - Get tick value in the future
+@item @code{@value{DIRPREFIX}clock_tick_later_usec} - Get tick value in the
future in microseconds
+@item @code{@value{DIRPREFIX}clock_tick_before} - Is tick value is before a
point in time
@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 seconds since boot
@@ -617,6 +620,107 @@ This directive will not cause the running task to be
preempted.
@c
@c
@page
+@subsection CLOCK_TICK_LATER - Get tick value in the future
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@findex rtems_clock_tick_later
+@example
+rtems_interval rtems_clock_tick_later(
+ rtems_interval delta
+);
+@end example
+@end ifset
+
+@subheading DESCRIPTION:
+
+Returns the ticks counter value delta ticks in the future.
+
+@subheading NOTES:
+
+This directive is callable from an ISR.
+
+This directive will not cause the running task to be preempted.
+
+@c
+@c
+@c
+@page
+@subsection CLOCK_TICK_LATER_USEC - Get tick value in the future in
microseconds
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@findex rtems_clock_tick_later_usec
+@example
+rtems_interval rtems_clock_tick_later_usec(
+ rtems_interval delta_in_usec
+);
+@end example
+@end ifset
+
+@subheading DESCRIPTION:
+
+Returns the ticks counter value at least delta microseconds in the future.
+
+@subheading NOTES:
+
+This directive is callable from an ISR.
+
+This directive will not cause the running task to be preempted.
+
+@c
+@c
+@c
+@page
+@subsection CLOCK_TICK_BEFORE - Is tick value is before a point in time
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+
Re: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
On 25/08/14 11:45, Daniel Cederman wrote: --- cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h b/cpukit/score/cpu/sparc/rtems/score/cpu.h index 9c38b55..d4c2ef0 100644 --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); void _CPU_SMP_Send_interrupt( uint32_t target_processor_index ); + #if defined(__leon__) void _BSP_Start_multitasking( Context_Control *heir ) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; #define _CPU_Start_multitasking _BSP_Start_multitasking + #endif In case it is LEON specific, then it should have a LEON specific name. -- 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
[PATCH V2] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
Rename _BSP_Start_multitasking to _LEON3_Start_multitasking to show that
it is LEON specific
---
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |2 +-
cpukit/score/cpu/sparc/rtems/score/cpu.h |6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c
b/c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c
index 9166ad5..b7c347e 100644
--- a/c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c
+++ b/c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c
@@ -82,7 +82,7 @@ void _CPU_SMP_Send_interrupt(uint32_t target_processor_index)
LEON3_IrqCtrl_Regs->force[target_processor_index] = 1 << LEON3_MP_IRQ;
}
-void _BSP_Start_multitasking(
+void _LEON3_Start_multitasking(
Context_Control *heir
)
{
diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h
b/cpukit/score/cpu/sparc/rtems/score/cpu.h
index 9c38b55..e44ab71 100644
--- a/cpukit/score/cpu/sparc/rtems/score/cpu.h
+++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h
@@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current
__asm__( "g6" );
void _CPU_SMP_Send_interrupt( uint32_t target_processor_index );
- void _BSP_Start_multitasking( Context_Control *heir )
+ #if defined(__leon__)
+ void _LEON3_Start_multitasking( Context_Control *heir )
RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
- #define _CPU_Start_multitasking _BSP_Start_multitasking
+ #define _CPU_Start_multitasking _LEON3_Start_multitasking
+ #endif
static inline void _CPU_SMP_Processor_event_broadcast( void )
{
--
1.7.9.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Using rtl-host in covor - some questions
2014-08-24 5:32 GMT+02:00 Chris Johns :
> On 23/08/2014 2:54 pm, Krzysztof Mięsowicz wrote:
>
>>
>> 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?
>>
>>
> There is ftp.rtems.org and that is where the image can be placed. Maybe a
> binary under rtems-tools.git. I am not sure.
> I need to add something like '%fetch' to the RSB to allow a configuration
> file the ability to do this.
A binary under rtems-tools repo is probably simpler for now - it could be
placed in the same directory as other coverage-related files from
rtems-testing repo like some css files, and configuration file introduced
by me.
>
>
> Chris, should I move rtl-host repo into rtems-tools or wait for your
>> action?
>>
>
> There are a couple if issues to resolve. First is how to merge the commit
> history from the rtl-host repo into the rtems-tools repo. I would like the
> commit history to be present so the history of who has worked on the code
> is maintained. Second, what is the structure in the rtems-tools repo and
> how to we integrate the various bits under a waf build tree ?
>
>
About the structure - on my PC I copied rtl-host directory just into
rtems-tools directory, so tree output is as follows:
rtems-tools
├── doc
│ ├── asciidoc
│ └── images
├── rtemstoolkit
├── rtl-host
│ ├── build-linux2
│ ├── elftoolchain
│ ├── libiberty
│ ├── waf-tools
│ └── win32
├── tester
│ ├── config
│ ├── covoar
│ ├── rt
│ └── rtems
└── tools
├── 4.10
├── 4.11
├── 4.9
└── libffi
Then, I was able to point from covoar/wscript to rtl-host/build-linux2 dir
where librld.a is placed, and link with this library. I think this is not
perfect solution, because rtl-host must be built independently before
covoar - but it works for now. You can find diff for covoar wscript
attached.
diff --git a/tester/covoar/wscript b/tester/covoar/wscript
index 88add6e..8cb33bf 100644
--- a/tester/covoar/wscript
+++ b/tester/covoar/wscript
@@ -46,6 +46,16 @@ APPNAME='covoar'
top = '.'
out = 'build'
+#
+# Paths to rtl-host
+#
+rtl_host_build_dir = "./../../rtl-host/build-linux2"
+rtl_host_dir = "./../../rtl-host"
+rtl_includes = ['../../rtl-host',
+ '../../rtl-host/elftoolchain/common',
+ '../../rtl-host/elftoolchain/libelf',
+ '../../rtl-host/libiberty']
+
def options(opt):
opt.load('compiler_cxx')
@@ -54,8 +64,12 @@ def configure(conf):
conf.check_cc(function_name='open64', header_name="stdlib.h", mandatory =
False)
conf.check_cc(function_name='stat64', header_name="stdlib.h", mandatory =
False)
conf.write_config_header('covoar-config.h')
+conf.env.STLIBPATH_RLD = conf.path.abspath() +
'/../../rtl-host/build-linux2'
+conf.env.STLIB_RLD = ['rld','iberty','elf']
+#conf.env.append_value('STLIBPATH', [conf.path.abspath() +
'/../../rtl-host/build-linux2'])
def build(bld):
+
bld.stlib(target = 'ccovoar',
source = ['app_common.cc',
'ConfigFile.cc',
@@ -89,9 +103,15 @@ def build(bld):
'Target_lm32.cc',
'Target_m68k.cc',
'Target_powerpc.cc',
-'Target_sparc.cc'],
+'Target_sparc.cc',
+'SymbolSet.cpp',
+'SymbolSetReader.cpp'],
cflags = ['-O2', '-g'],
- includes = ['.'])
+ cxxflags = ['-std=c++11', '-O2', '-g'],
+# libpath = rtl_host_build_dir,
+# lib = 'rld',
+ includes = ['.',
+ './symbolGen'] + rtl_includes)
bld.program(target = 'trace-converter',
source = ['TraceConverter.cc',
@@ -106,12 +126,12 @@ def build(bld):
bld.program(target = 'covoar',
source = ['covoar.cc'],
-use = 'ccovoar',
+use = ['ccovoar','RLD'],
cflags = ['-O2', '-g'],
includes = ['.'])
bld.program(target = 'covoar',
source = ['covoar.cc'],
-use = 'ccovoar',
+use = ['ccovoar','RLD'],
cflags = ['-O2', '-g'],
includes = ['.'])
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: BSP Build Failures Appeal
On 8/23/2014 10:33 PM, Chris Johns wrote: > On 23/08/2014 1:57 am, Joel Sherrill wrote: >> The build failures I reported were with the latest RSB tools >> Please pitch in and let's resolve them. >> > I have a regression build that includes building all BSPs using ... > > $ rm -rf build rsb-report-* log_* && ../source-builder/sb-set-builder > --prefix=$HOME/development/rtems/4.11 --log=log_all_rtems --with-rtems > --trace --regression 4.11/rtems-all > > ... running on sync.rtems.org as I am also seeing failures. This should > give me a list of error reports with the first failure on an architecture. Apparently my build with the RSB tools didn't see all those failures. I repeated the same build script/configuration with tools from the head and nearly all BSPs failed. I may have updated RTEMS between those two points in time and the problem got worse. This is the configure line for powerpc/psim. All others were the same with the architecture and BSP replaced: ../rtems/configure --target=powerpc-rtems4.11 \ --prefix=/home/joel/rtems-4.11-work/bsp-install/ --disable-multiprocessing \ --disable-cxx --disable-rdbg --enable-maintainer-mode --enable-tests \ --enable-networking --enable-posix --disable-itron --disable-deprecated \ --disable-ada --enable-expada --enable-rtemsbsp=psim >> I left a similar build going for the weekend but using the >> head of gcc, newlib, and binutils. Hopefully the results >> are similar. > Given the churn GSoC patches are creating I think we are still a while > away from a freeze before release branching 4.11. +1 Hopefully not too long though. Most of them are more contained to BSPs, ports, etc. than in past years where there was score work. > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
On 8/25/2014 5:10 AM, Sebastian Huber wrote: > On 25/08/14 11:45, Daniel Cederman wrote: >> --- >> cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h >> b/cpukit/score/cpu/sparc/rtems/score/cpu.h >> index 9c38b55..d4c2ef0 100644 >> --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h >> +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h >> @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control >> *_SPARC_Per_CPU_current __asm__( "g6" ); >> >> void _CPU_SMP_Send_interrupt( uint32_t target_processor_index ); >> >> + #if defined(__leon__) >> void _BSP_Start_multitasking( Context_Control *heir ) >> RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; >> #define _CPU_Start_multitasking _BSP_Start_multitasking >> + #endif > In case it is LEON specific, then it should have a LEON specific name. > What's the overall rationale? What happens on all other architectures/variants? Can this simply be a matter of deferring the selection/implementation to the BSP? We do that for other cases where the precise CPU model must be known. The interface from the score/cpu is well known and is mostly implemented in score/cpu. But sometimes, it can't be. -- 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: powerpc/gwlcfm does not compile
Thanks. I will start a build sweep again once we have resolved the cache compilation impact. On 8/25/2014 2:11 AM, Sebastian Huber wrote: > Fixed: > > http://git.rtems.org/rtems/commit/?id=0a314839012ab765a70df05eaadc4dba7440223b > -- 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: [rtems-tools commit] Update readme.
Hi I am thrilled to see this code finally becoming more widely available. I am now asking questions about "productization" which is reproducibility, maintainability, making it available to users, enhancement path, etc. Would it be possible to update the blog to reflect the current location of the code? Chris.. does having this in rtems-tools mean that a standard *-rtems* gdb will have the Python pretty printers? Is there an up to date status of which core handlers and managers have at least an initial pretty printer? Is there anyway to automate testing these? I know the gdb macros that I mostly wrote were a pain in the *&%$ to make sure they stayed up to date and in sync. It was easy to miss them for months after a change impacted them. --joel On 8/24/2014 6:45 PM, Chris Johns wrote: > Module:rtems-tools > Branch:master > Commit:6e75f4ebf5450154231a1f7c1c2ba97e60d2c074 > Changeset: > http://git.rtems.org/rtems-tools/commit/?id=6e75f4ebf5450154231a1f7c1c2ba97e60d2c074 > > Author:Dhananjay Balan > Date: Tue Jul 9 22:39:27 2013 +0530 > > Update readme. > Included useage instructions. > > --- > > tools/gdb/python/README.md |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/tools/gdb/python/README.md b/tools/gdb/python/README.md > index 567c195..8858a4f 100644 > --- a/tools/gdb/python/README.md > +++ b/tools/gdb/python/README.md > @@ -2,3 +2,5 @@ rtems-gdb > = > > GDB extenstions to RTEMS. > + > +See [this blog post for > instructions](http://dbalan.github.io/blog/2013/06/23/debugging-rtems-with-gdb/) > > ___ > vc mailing list > v...@rtems.org > http://lists.rtems.org/mailman/listinfo/vc -- 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/5] sptests/spcache01: Make inline assembly conditional to account for OpenRISC l.nop instruction.
I pushed all of this set and will be testing soon.
Can you post your simulator configuration file?
--joel
On 8/22/2014 3:20 PM, Hesham ALMatary wrote:
> ---
> 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()
>
--
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] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
On 08/25/2014 05:04 PM, Joel Sherrill wrote: On 8/25/2014 5:10 AM, Sebastian Huber wrote: On 25/08/14 11:45, Daniel Cederman wrote: --- cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h b/cpukit/score/cpu/sparc/rtems/score/cpu.h index 9c38b55..d4c2ef0 100644 --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); void _CPU_SMP_Send_interrupt( uint32_t target_processor_index ); + #if defined(__leon__) void _BSP_Start_multitasking( Context_Control *heir ) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; #define _CPU_Start_multitasking _BSP_Start_multitasking + #endif In case it is LEON specific, then it should have a LEON specific name. What's the overall rationale? If its mandated by the CPU port, e.g. all the stuff defined by no_cpu/cpu.h, then it should be _CPU_*. In case all BSPs of a CPU port must implement a CPU port function, then it is _BSP_*. In case only certain multilib variants implement it specifically, then they should have an appropriate multilib specific prefix, e.g. _LEON3_* or _ARMV7M_*. Does this make sense? Maybe we should add this stuff to the CPU supplement. -- 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] score: Define _CPU_Start_multitasking only for LEON SPARC, not SPARC in general
On 8/25/2014 11:44 AM, Sebastian Huber wrote: > On 08/25/2014 05:04 PM, Joel Sherrill wrote: >> On 8/25/2014 5:10 AM, Sebastian Huber wrote: >>> On 25/08/14 11:45, Daniel Cederman wrote: --- cpukit/score/cpu/sparc/rtems/score/cpu.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/cpukit/score/cpu/sparc/rtems/score/cpu.h b/cpukit/score/cpu/sparc/rtems/score/cpu.h index 9c38b55..d4c2ef0 100644 --- a/cpukit/score/cpu/sparc/rtems/score/cpu.h +++ b/cpukit/score/cpu/sparc/rtems/score/cpu.h @@ -1203,9 +1203,11 @@ register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); void _CPU_SMP_Send_interrupt( uint32_t target_processor_index ); + #if defined(__leon__) void _BSP_Start_multitasking( Context_Control *heir ) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; #define _CPU_Start_multitasking _BSP_Start_multitasking + #endif >>> In case it is LEON specific, then it should have a LEON specific name. >>> >> What's the overall rationale? > If its mandated by the CPU port, e.g. all the stuff defined by > no_cpu/cpu.h, then it should be _CPU_*. In case all BSPs of a CPU port > must implement a CPU port function, then it is _BSP_*. In case only > certain multilib variants implement it specifically, then they should > have an appropriate multilib specific prefix, e.g. _LEON3_* or > _ARMV7M_*. Does this make sense? Maybe we should add this stuff to the > CPU supplement. > Yeah. I get this part and we do need better rules but what's the issue with this one method? The ifdef made it look like only the leon flavor of RTEMS and no others even had this method. -- 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: [rtems-tools commit] Update readme.
On 26/08/2014 1:39 am, Joel Sherrill wrote: I am thrilled to see this code finally becoming more widely available. I am now asking questions about "productization" which is reproducibility, maintainability, making it available to users, enhancement path, etc. Would it be possible to update the blog to reflect the current location of the code? What blog ? There is also the wiki page that needs updating. Chris.. does having this in rtems-tools mean that a standard *-rtems* gdb will have the Python pretty printers? No. These files are not installed by default. I am adding waf support so you can install them under a prefix and under that prefix it assumes you have an installed gdb. To begin with the RTEMS support will not automatically load. You will need to use: (gdb) py import rtems to get the support loaded. That may change once the support is more stable. My intention is to have the RSB install these for you so RSB built tools will be default have this support. Is there an up to date status of which core handlers and managers have at least an initial pretty printer? No. I have only just imported the repo and I did that as a way to see how to merge one repo into another, ie the rtl-host repo. The scripts do not work as are and I am looking into this. Is there anyway to automate testing these? I know the gdb macros that I mostly wrote were a pain in the *&%$ to make sure they stayed up to date and in sync. It was easy to miss them for months after a change impacted them. No at the moment. To test you need a suitable gdb and RTEMS executable and that executable needs to have the all the APIs included the test script requires. I do no think such a test exists. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
or1ksim in rtems-source-builder
Hi FWIW I don't think or1ksim has a bset in RSB yet. -- 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: or1ksim in rtems-source-builder
On 26/08/2014 8:26 am, Joel Sherrill wrote: FWIW I don't think or1ksim has a bset in RSB yet. I think this would be placed under the 'bare' config tree. The RTEMS config could then add this to the build set for this architecture. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Rtems_fsmount dosfs hanging
Hi Andre, I am too trying to understand SD card/MMC protocol on Raspberry pi for RTEMS. You said in your last mail that you have already done some progress on this. Could you please share your code at some place, so that others can get a help from your code in case anybody else too is trying to understand/develop SD card support for Raspberry pi. Thanks for the help!! Ritesh On Wed, May 14, 2014 at 12:30 AM, Andre Marques < andre.lousa.marq...@gmail.com> wrote: > On 05/13/14 12:15, Andrey Mozzhuhin wrote: > > Do you not forget to call rtems_blkdev_request_done in read routine of > block device driver? > Also try to increase CONFIGURE_MAXIMUM_TASKS - bdbuf need some worker > tasks. > > > I call rtems_blkdev_request_done after each read request, and changing > CONFIGURE_MAXIMUM_TASKS to 20 (instead of 2) did not had any impact. > > > > >> https://github.com/jncronin/rpi-boot/blob/master/emmc.c > > Hmm. Implementation specific to Raspberry Pi is not good idea. It is > better to separate MMC/SD protocol implementation and hardware support like > in FreeBSD or Linux. > > > Yes, the point in the end is probably to have the MMC/SD protocol > somewhere else, just like the spi-sd-card driver (SD card access through > SPI interface protocol, at c/src/libchip/i2c/spi-sd-card*). > > > > >> Not sure how to approach this problem, as the logic seems right. Will > do more testing in the meanwhile. > > > Today I have re-formated the card (under Linux), and the block data read > on RPi checks with the card hexdump on Linux. > > So far I tested: > > - The block data that is being read, and compared with the same block data > read on Linux (small mismatch (4 bits) at the middle of a 512 byte block > before, no mismatch now) > > - The request buffer contents ( > http://www.rtems.org/onlinedocs/doxygen/cpukit/html/structrtems__blkdev__sg__buffer.html). > Looking at this I don't know what the User pointer is. I'm using the buffer > pointer to store my readings. > > - Reading the partition table from the first block. I can read the first > block and register the card partition as a logical disk, so reading and > registering the partition table is no problem. > > - Tried also a busy wait between block readings. > > The result is always the same: when mounting the card partition, it reads > the first two partition blocks and then hangs. > > > If you get stuck share your sources and let me know. > > > Will try to get the code to github soon. > > > > > 2014-05-13 14:03 GMT+04:00 Andre Marques : > >> On 05/12/14 19:25, Andrey Mozzhuhin wrote: >> >> I think you need start with simple tests without file systems and block >> device driver. >> Try read and write blocks with known patterns and check it on PC and >> Raspberry Pi. >> >> >> I have checked the data read by my emmc driver from the first two blocks >> (the ones it reads) on the RPi, and compared with an hexdump of those same >> two blocks on Linux, and there is a small mismatch at the middle of the >> first block. >> >> Not sure how to approach this problem, as the logic seems right. Will do >> more testing in the meanwhile. >> >> >> What are you use for MMC/SD protocol? Can I see it and block device >> driver somewhere? >> >> >> I'm porting the following code >> >> https://github.com/jncronin/rpi-boot/blob/master/emmc.c >> >> and using the following SD card documentation >> >> Physical Layer Simplified Specification (3.01) - >> https://www.sdcard.org/downloads/pls/simplified_specs/archive/part1_301.pdf >> >> Host Controller Simplified Specification (2.00) - >> https://www.sdcard.org/downloads/pls/simplified_specs/archive/partA2_200.pdf >> >> and the raspberry soc datasheet: Broadcom BCM2835 Peripherals Guide >> (Chapter 5 - EMMC) >> >> >> >> 2014-05-12 20:23 GMT+04:00 Andre Marques : >> >>> Hello, >>> >>> I have used the pc386 BSP to mount the card (before your suggestions) >>> using the fileio sample and it could read the card contents perfectly. >>> >>> Then I filled the card with zeros using dd on Linux, modified the fileio >>> sample to format the card with msdos_format(dev, NULL) and then mounted it >>> on the pc 386 BSP fileio sample and I could write and read the card. >>> >>> On Linux I set the card with the necessary files for Raspberry, and when >>> my driver tries to mount the card on the Raspberry Pi it reads the first 2 >>> blocks (now 0 and 1, because the card has no partition table) and hangs, >>> just as before. >>> >>> I guess my driver is having some reading problems. >>> >>> >>> On 05/05/14 19:30, Andrey Mozzhuhin wrote: >>> >>> You can try to use SD Card in opposite direction: >>> 0) fill SD Card with zeroes; >>> 1) format partition under RTEMS with msdos_format() function; >>> 2) check that PC can read/write this SD Card; >>> 3) if PC fails to mount this partition - dump SD Card and check that all >>> data is on right sectors. >>> >>> >>> >>> 2014-05-05 22:28 GMT+04:00 Andrey Mozzhuhin : >>> Hi, Andre You can try to us
