On 23/07/2016 3:47 AM, vivek kukreja wrote:
I'm working on improving the current tracing framework of
RTEMS(Capture Engine and Trace Linker) for GSoC 2016. In the current
phase, I have to transport trace files from RTEMS to host machine.
I've built rtems-libbsd drivers for xilinx_zynq_19_qemu bsp
Hi everyone,
I'm working on improving the current tracing framework of
RTEMS(Capture Engine and Trace Linker) for GSoC 2016. In the current
phase, I have to transport trace files from RTEMS to host machine.
I've built rtems-libbsd drivers for xilinx_zynq_19_qemu bsp and all
examples are building w
I was testing I2C test case for BBB. When I hit compile I have got
following linking error. Any clue what may be error ?
arm-rtems4.12-gcc -B../../../../../beagleboneblack/lib/ -specs bsp_specs
-qrtems -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections -Wall
-Wmissing-prototypes -Wimplicit
Update #2752.
---
cpukit/score/src/threadhandler.c | 15 ---
testsuites/sptests/spextensions01/init.c | 74
2 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/cpukit/score/src/threadhandler.c b/cpukit/score/src/threadhandler.c
index 2fa6d07
Do not use RTEMS_NO_RETURN hints for debug configurations to ease use of
stack traces in case of fatal errors.
---
cpukit/score/include/rtems/score/basedefs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/score/include/rtems/score/basedefs.h
b/cpukit/score/include/rte
RTEMS: https://github.com/deval-maker/rtems/tree/RPi Libbsd:
https://github.com/deval-maker/rtems-libbsd/tree/rpi_usb
Deval Shah
On Fri, Jul 22, 2016 5:33 AM, Alan Cudmore alan.cudm...@gmail.com wrote:
Hi Deval, That is great news! Is this in your bsdlib github repository? I would
like to tr
Hello Jennifer,
I just went through your commits on the Capture Engine and I see you
have mentioned about disabling the engine before running trace. This
is missing from the capture doc though. We will fix that.
Thanks for clearing this out Jennifer. I'm working on live-tracing for
GSoC and I thin
On 22/07/2016 17:05, Sebastian Huber wrote:
_CPU_Context_Get_PC() ?
I would like this to be localised to the CPU implementation and
something that is figured out when a new port is done.
Yes, I think a _CPU_Context_Get_PC() would be the right way to do this.
Excellent. Thanks for the feedb
On 22/07/16 08:52, Chris Johns wrote:
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 a
