On Fri, Mar 5, 2021 at 10:27 AM Joel Sherrill wrote:
>
>
>
> On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber
> wrote:
>>
>> On 05/03/2021 16:11, jan.som...@dlr.de wrote:
>>
>> > Some of the resulting CTF events have a very large timestamp. This only
>> > occurs for events of which are created b
On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 05/03/2021 16:11, jan.som...@dlr.de wrote:
>
> > Some of the resulting CTF events have a very large timestamp. This only
> occurs for events of which are created by CPUs other than CPU0, but not all
>
On 05/03/2021 16:11, jan.som...@dlr.de wrote:
Some of the resulting CTF events have a very large timestamp. This only occurs
for events of which are created by CPUs other than CPU0, but not all of them.
I ran rtems-record-lttng in gdb and could track it to record-client.c:176
(https://git.rtem
Hello,
I try to do some performance measurements with the rtems-record functionality.
Since the target doesn't have Ethernet, but a lot of RAM, I collect all events
in a large buffer during runtime and flush the events via the
"record_dump_zlib_base64" method in the end.
This RTEMS side works we
Thank you very much for your reply. I'm using MSYS2 MinGW 64-bit.
Actually I also tried to install RTEMS 4.11.0 and 4.11.2 and I didn't
succeed.
After running:
$ ../source-builder/sb-set-builder --prefix=/opt/rtems/4.11
4.11/rtems-sparc --jobs=none
in ...@LAPTOP-NOT8H6PV MINGW64 /c/opt/rtems/4.11.
