On 30/09/2014 6:40 pm, Sebastian Huber wrote:
On 29/09/14 08:15, Chris Johns wrote:
Why do we not move the tool chain patches back to the RTEMS sources? I
think it would be nice if you can check out a particular RTEMS version
and then use the RSB and say: build me the tool chain for this versi
On 30/09/2014 6:28 pm, Sebastian Huber wrote:
On 30/09/14 00:48, Chris Johns wrote:
On 30/09/2014 3:26 am, Peter Dufault wrote:
On Sep 29, 2014, at 02:15 , Chris Johns wrote:
I can add the scripts to INI file format. I feel XML is too heavy a
requirement for parsing. There is a single C++ f
Hi
cc'ing Christian in case he has some insight.
Do you see this when you build with C++ enabled? I don't see this
problem on any other target.
or1k-rtems4.11-g++ -B../../.././lib/ -B../../.././or1ksim/lib/ -specs
bsp_specs -qrtems -DPACKAGE_NAME=\"rtems-c-src-librtems++\"
-DPACKAGE_TARNAME=\"r
On 2014-09-30 16:45, Sebastian Huber wrote:
If you need a link time option, then there is no standard way to do this
on the BSP level. Most BSPs use some sort of weak tables or functions.
The LEON3 BSP already uses such a thing for debug_uart_index for
example.
Ok, then I'll do something simil
Hello Daniel,
On 30/09/14 16:30, Daniel Cederman wrote:
I would like to add a way for the user of the leon3 bsp to specify the irq that
should be used for IPIs. Is it adding an option to configure.ac for the bsp
that is the recommended way? Or does there exist a supported way of setting bsp
spec
Hi,
I would like to add a way for the user of the leon3 bsp to specify the
irq that should be used for IPIs. Is it adding an option to
configure.ac for the bsp that is the recommended way? Or does there
exist a supported way of setting bsp specific parameters similar to how
it is done with co
rtems_cpu_usage_top should be used for this information.
---
cpukit/libmisc/capture/capture-cli.c | 272 ---
1 file changed, 272 deletions(-)
diff --git a/cpukit/libmisc/capture/capture-cli.c
b/cpukit/libmisc/capture/capture-cli.c
index fb93e53..dc1f3bc 100644
---
This patch removes functionality for stack checking from
the capture engine and requiresi the use of existing rtems
functions for this information. It modifies ctload to use
functionality similar to rtems cpuusage. It removes the
capture task and stores a new capture task record the first
time th
---
testsuites/libtests/Makefile.am | 2 +-
testsuites/libtests/configure.ac| 1 +
testsuites/libtests/top/Makefile.am | 21 +++
testsuites/libtests/top/init.c | 106
testsuites/libtests/top/system.h| 63 +
testsui
---
cpukit/libmisc/Makefile.am | 2 +-
cpukit/libmisc/cpuuse/cpuusagetop.c | 338
cpukit/libmisc/cpuuse/cpuuse.h | 19 ++
3 files changed, 358 insertions(+), 1 deletion(-)
create mode 100644 cpukit/libmisc/cpuuse/cpuusagetop.c
diff --git a/cp
---
cpukit/score/include/rtems/score/thread.h | 7 +++
cpukit/score/src/threadinitialize.c | 3 +++
2 files changed, 10 insertions(+)
diff --git a/cpukit/score/include/rtems/score/thread.h
b/cpukit/score/include/rtems/score/thread.h
index 456df35..299bac6 100644
--- a/cpukit/score/incl
This involved adding a new variable record to the capture buffer
and modifing the trace method to read those records.
---
testsuites/libtests/capture01/init.c | 112 ++-
1 file changed, 85 insertions(+), 27 deletions(-)
diff --git a/testsuites/libtests/capture01/in
---
cpukit/libmisc/Makefile.am | 2 +-
cpukit/libmisc/shell/main_top.c| 60 ++
cpukit/libmisc/shell/shellconfig.h | 6
3 files changed, 67 insertions(+), 1 deletion(-)
create mode 100644 cpukit/libmisc/shell/main_top.c
diff --git a/cpukit/li
---
cpukit/libmisc/cpuuse/cpuusagereport.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/cpukit/libmisc/cpuuse/cpuusagereport.c
b/cpukit/libmisc/cpuuse/cpuusagereport.c
index 296fa28..5cba819 100644
--- a/cpukit/libmisc/cpuuse/cpuusagereport.c
+++ b
---
cpukit/score/include/rtems/score/threadimpl.h | 30 +++
1 file changed, 30 insertions(+)
diff --git a/cpukit/score/include/rtems/score/threadimpl.h
b/cpukit/score/include/rtems/score/threadimpl.h
index 9321c01..6195561 100644
--- a/cpukit/score/include/rtems/score/thr
2014-09-21 20:07 GMT+02:00 :
> From: Tomasz Gregorek
>
> Added simple math to caclulate register values for the PLL
> and for the prescalers. It will try to keep 48MHz for the USB OTG FS.
> Also it will set latency on the Flash memory for the high speeds.
>
> Limitations:
> It is assumed that 1MH
Patches 1-5 were submitted and have requested changes.
Patches 6-9 move the capture engine ctload command to
a new rtems top command.
If there are no more requested changes for 1-5 I will
push them.
Jennifer Averett
___
devel mailing list
devel@rtem
On 29/09/14 08:15, Chris Johns wrote:
Why do we not move the tool chain patches back to the RTEMS sources? I
think it would be nice if you can check out a particular RTEMS version
and then use the RSB and say: build me the tool chain for this version.
I am ok with the INI file that defines t
On 14/08/14 16:25, Joel Sherrill wrote:
On 8/14/2014 9:21 AM, Sebastian Huber wrote:
>On 14/08/14 16:15, Joel Sherrill wrote:
>>>E.g. most of the tests won't even start without modifications. So
effectively I have to fall back to a polling driver for console if I
want to run the tests
On 30/09/14 00:48, Chris Johns wrote:
On 30/09/2014 3:26 am, Peter Dufault wrote:
On Sep 29, 2014, at 02:15 , Chris Johns wrote:
I can add the scripts to INI file format. I feel XML is too heavy a
requirement for parsing. There is a single C++ file that does it and
Python handles the format
20 matches
Mail list logo
