On 22/07/2016 16:44, Sebastian Huber wrote:
The stack pointer is part of the context. If you retrieve the PC from
here it should work for all threads.
All threads on the i386 arch or all threads on all archs?
I would like to make this simpler for all archs. I do not mind if we
require somethi
On 22/07/16 08:43, Sebastian Huber wrote:
On 22/07/16 08:34, Chris Johns wrote:
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_poi
On 22/07/16 08:34, Chris Johns wrote:
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_point, _is_fp,
_tls_area ) \
do { \
uint
On 22/07/2016 16:10, Sebastian Huber wrote:
On i386 the PC is stored on the stack frame:
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
_isr, _entry_point, _is_fp,
_tls_area ) \
do { \
uint32_t _stack; \
\
(void) _is_f
On 22/07/16 08:03, Sebastian Huber wrote:
On 22/07/16 07:51, Chris Johns wrote:
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by
the CPU
port inter
On 22/07/16 07:51, Chris Johns wrote:
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the
CPU
port interface and use something like _I386_* for thing
On 22/07/2016 15:39, Sebastian Huber wrote:
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular archit
On 22/07/16 07:30, Chris Johns wrote:
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
I would like this to be added to th
On 22/07/2016 15:26, Sebastian Huber wrote:
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
I would like this to be added to the formal _CPU_* port interface.
Withou
Could we please use the _CPU_* prefix only for stuff defined by the CPU
port interface and use something like _I386_* for things that are
specific to a particular architecture.
On 22/07/16 03:17, Chris Johns wrote:
Add an external symbol as a marker to the restore point in the
context switch.
---
cpukit/score/src/iterateoverthreads.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cpukit/score/src/iterateoverthreads.c
b/cpukit/score/src/iterateoverthreads.c
index 8933352..3296914 100644
--- a/cpukit/score/src/iterateoverthreads.c
+++ b/cpukit/score/src/iterateoverthreads.c
@@ -
On 13/07/2016 19:52, Chris Johns wrote:
I will take this away and come back with something. I need a suitable
interface for something I am working on.
My need for this change does not exist any more so I will not be doing
any further work on it.
Chris
---
cpukit/score/include/rtems/score/statesimpl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/score/include/rtems/score/statesimpl.h
b/cpukit/score/include/rtems/score/statesimpl.h
index 596246c..17b7342 100644
--- a/cpukit/score/include/rtems/score/statesimpl.h
+++ b/cpukit/scor
Add an external symbol as a marker to the restore point in the
context switch. If you set the IP to this location for a blocked
thread and you use the saved register values in the TCB you can
view the thread's context.
---
cpukit/score/cpu/i386/cpu_asm.S | 2 ++
1 file changed, 2 insertions(+)
di
On 22/07/2016 00:39, Jennifer Averett wrote:
If I remember correctly the capture engine should not be
running when you print and free records. The trace should
have been stopped then records printed and freed so that
the records in the buffer are visible when trace is turned
back on. I don't th
Hi Deval,
That is great news!
Is this in your bsdlib github repository?
I would like to try it out soon.
Thanks,
Alan
> On Jul 21, 2016, at 12:57 PM, Deval Shah wrote:
>
> Hello all,
>
> Good news ! The usb_ethernet controller is working.
>
> Dr. Joel pointed out to check if I am actually get
Hi Pavel,
I just updated my rtems-git repository and see these changes. It runs on the Pi
2, Pi A+, Model B, and Pi Zero for me. I definitely see the speedup in the
benchmarks.
Thanks!
Alan
> On Jul 17, 2016, at 6:48 PM, p...@cmp.felk.cvut.cz wrote:
>
> From: Pavel Pisa
>
> The changes corr
Hello all,
Good news ! The usb_ethernet controller is working.
Dr. Joel pointed out to check if I am actually getting the interrupt. So I
checked there and found out that there was no entry for USB interrupt. As soon
as I added that entry, everything started working.
Now I am getting the Power in t
If I remember correctly the capture engine should not be
running when you print and free records. The trace should
have been stopped then records printed and freed so that
the records in the buffer are visible when trace is turned
back on. I don't think the buffer is protected when it is runn
This helps to detect
* double insert, append, prepend errors, and
* get from empty chain errors.
---
cpukit/libcsupport/src/malloc_deferred.c | 6 ++-
cpukit/libcsupport/src/mount-mgr.c | 1 +
cpukit/libcsupport/src/printertask.c | 1 +
cpukit/libcsupp
hi, I add Multiple user root directory and access control for rtems,I have
test it on my board, can somebody interesting about it and test more?
--- ./base/ftpd.c 2016-03-11 11:39:41.752551200 +0800
+++ ./ftpd.c2016-07-21 16:10:59.308281000 +0800
@@ -189,7 +189,7 @@
#if HAVE_CONFIG_H
21 matches
Mail list logo
