Re: [GSOC - Tracing] Status Update

[Sebastian Huber]

On 28/06/18 19:41, Vidushi Vashishth wrote:

>Could you please create a self-contained repository which contains

>* a README

>* a simple RTEMS application which runs on a simulator BSP

>* the stuff that makes it possible to view the trace output (it is 
not a problem if it doesn't work, but all pieces should be included)


>The repository should not be a clone of some larger project. It may 
contain external references as submodules.


Okay. Got it. I will update you when its done.


Ok, do you have a time estimate for this? Which parts are missing?



>Did you modify babeltrace?

No I did not.


Ok, this is good.



>Why do you need a very recent babeltrace for your work?

I haven't tested the code with other versions of babeltrace. I cant 
say why it does not work with others. I ll try to test the code with 
other versions and identify what's wrong.


If it doesn't work with the babeltrace shipped with standard 
distributions, then this a slight burden to get started for users. It is 
not a high priority issue at the moment.




> Is visualization with Trace Compass a goal of this project?

No it isn't. Trace generation in CTF is a goal.


What are the consumers of this CTF? Why do we need it? What is the 
benefit for the RTEMS users?


--
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: [GSoC - x86_64] Console / serial communication

[Chris Johns]

On 28/06/2018 16:40, Amaan Cheval wrote:
> I believe it isn't, but QEMU is being "helpful" and multiplexing the COM1
> (RTEMS) stream with the VGA/VBE/etc. text mode streams.

OK.

> 
> I'm looking into how to either:
> - Make QEMU only print COM1 to stdio
> - Or, how to quiet FreeBSD through configuration (loader.conf lets us set
> console to comconsole, vidconsole, nullconsole, and efi)
> 
> I'll let y'all know as things progress!

Thanks.

> 
> Would it be a blocker if we couldn't quiet the UEFI firmware and loader.efi?
> 

Not at all. I was just curious and hopeful it just worked.

Chris

> On Thu, Jun 28, 2018, 3:39 AM Chris Johns  > wrote:
> 
> On 28/06/2018 00:37, Amaan Cheval wrote:
> > Since we skipped our meeting today, here's a quick screengrab of UART
> > working with -serial stdio on QEMU (just inb/outb instructions
> > directly, without termios or ns16550):
> > https://i.imgur.com/tumtD3Z.png
> 
> Nice. Is the loader.efi also using the UART?
> 
> Chris
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

>Could you please create a self-contained repository which contains

>* a README

>* a simple RTEMS application which runs on a simulator BSP

>* the stuff that makes it possible to view the trace output (it is not a
problem if it doesn't work, but all pieces should be included)

>The repository should not be a clone of some larger project. It may
contain external references as submodules.

Okay. Got it. I will update you when its done.

>Did you modify babeltrace?

No I did not.

>Why do you need a very recent babeltrace for your work?

I haven't tested the code with other versions of babeltrace. I cant say why
it does not work with others. I ll try to test the code with other versions
and identify what's wrong.

> Is visualization with Trace Compass a goal of this project?

No it isn't. Trace generation in CTF is a goal.

On Thu, Jun 28, 2018 at 11:43 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/06/18 07:42, Vidushi Vashishth wrote:
>
>> >which use case does this address? What is the connection to an RTEMS
>> application?
>> This converts the trace buffering of the fileio sample testcase output to
>> CTF. This pertains to the function tracing testcase. The CTF stream
>> generated records the entry and exit of the calloc, malloc, realloc and
>> free functions and also the values of the arguments and return values.
>>
>
> Could you please create a self-contained repository which contains
>
> * a README
>
> * a simple RTEMS application which runs on a simulator BSP
>
> * the stuff that makes it possible to view the trace output (it is not a
> problem if it doesn't work, but all pieces should be included)
>
> The repository should not be a clone of some larger project. It may
> contain external references as submodules.
>
>
>> >Why do I need sudo to run the commands?
>> The command needs permission to create a directory for the traces. The
>> command did not work without this.
>>
>
> It worked without sudo in my clone. Using sudo for this kind of stuff
> would be a very severe usability issue from my point of view.
>
>
>> >Why do I need your babeltrace? Not being able to use a tool from a
>> standard distribution makes it harder to do RTEMS tracing.
>> I wanted to work on integrating barectf with RTEMS trace linker instead.
>> I documented the approach in: https://vidushivashishth.githu
>> b.io/sixthpost/.
>>
>
> Could you please also post your stuff on the devel@rtems.org mailing
> list. I don't have time to look for blog posts actively.
>
> Did you modify babeltrace?
>
> Why do you need a very recent babeltrace for your work?
>
> I was stuck on deciding the yaml configuration input for the process and
>> sent out an email for this discussion on the mailing list as well. I have
>> however finally created one. I can continue work on the barectf approach if
>> that is okay with you? I will start a new thread on this with the
>> configuration file I have chosen?
>>
>
> I need a demo projects which puts all the pieces together. This is all to
> abstract to me.
>
>
>> >What can I do with a metadata stream and the CTF trace stream?
>> These can be transported to the host and then viewed using Trace Compass.
>>
>> I lost some time trying to figure things out on my own. I will be more
>> frequent in communicating places where I am stuck. Apologies for the same.
>>
>
> Is visualization with Trace Compass a goal of this project?
>
>
> --
> 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: [GSoC - x86_64] Console / serial communication

[Amaan Cheval]

I believe it isn't, but QEMU is being "helpful" and multiplexing the COM1
(RTEMS) stream with the VGA/VBE/etc. text mode streams.

I'm looking into how to either:
- Make QEMU only print COM1 to stdio
- Or, how to quiet FreeBSD through configuration (loader.conf lets us set
console to comconsole, vidconsole, nullconsole, and efi)

I'll let y'all know as things progress!

Would it be a blocker if we couldn't quiet the UEFI firmware and loader.efi?

On Thu, Jun 28, 2018, 3:39 AM Chris Johns  wrote:

> On 28/06/2018 00:37, Amaan Cheval wrote:
> > Since we skipped our meeting today, here's a quick screengrab of UART
> > working with -serial stdio on QEMU (just inb/outb instructions
> > directly, without termios or ns16550):
> > https://i.imgur.com/tumtD3Z.png
>
> Nice. Is the loader.efi also using the UART?
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC - Tracing] Status Update

[Sebastian Huber]

On 28/06/18 07:42, Vidushi Vashishth wrote:

>which use case does this address? What is the connection to an RTEMS 
application?
This converts the trace buffering of the fileio sample testcase output 
to CTF. This pertains to the function tracing testcase. The CTF stream 
generated records the entry and exit of the calloc, malloc, realloc 
and free functions and also the values of the arguments and return values.


Could you please create a self-contained repository which contains

* a README

* a simple RTEMS application which runs on a simulator BSP

* the stuff that makes it possible to view the trace output (it is not a 
problem if it doesn't work, but all pieces should be included)


The repository should not be a clone of some larger project. It may 
contain external references as submodules.




>Why do I need sudo to run the commands?
The command needs permission to create a directory for the traces. The 
command did not work without this.


It worked without sudo in my clone. Using sudo for this kind of stuff 
would be a very severe usability issue from my point of view.




>Why do I need your babeltrace? Not being able to use a tool from a standard distribution 
makes it harder to do RTEMS tracing.
I wanted to work on integrating barectf with RTEMS trace linker 
instead. I documented the approach in: 
https://vidushivashishth.github.io/sixthpost/.


Could you please also post your stuff on the devel@rtems.org mailing 
list. I don't have time to look for blog posts actively.


Did you modify babeltrace?

Why do you need a very recent babeltrace for your work?

I was stuck on deciding the yaml configuration input for the process 
and sent out an email for this discussion on the mailing list as well. 
I have however finally created one. I can continue work on the barectf 
approach if that is okay with you? I will start a new thread on this 
with the configuration file I have chosen?


I need a demo projects which puts all the pieces together. This is all 
to abstract to me.




>What can I do with a metadata stream and the CTF trace stream?
These can be transported to the host and then viewed using Trace Compass.

I lost some time trying to figure things out on my own. I will be more 
frequent in communicating places where I am stuck. Apologies for the same.


Is visualization with Trace Compass a goal of this project?

--
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