Re: Issue with 'rtems_shell_wait_for_input' function
Hello Chris, Inside rtems_shell_wait_for_input we call the change_serial_settings function which is returning RTEMS_UNSUCCESSFUL so the test doesn't start on qemu. I tried the tests on gdb for other bsps and they work. I'm still looking into this issue so I can start working on transports. If you have any idea about this error, please suggest any docs to help solve it until Sebastian is away. Thank you. Regards, Vivek On Apr 19, 2017 6:03 AM, "Chris Johns" wrote: > On 18/04/2017 20:12, vivek kukreja wrote: > >> Hello Sebastian, all, >> >> Sir as you said the uart_set_attributes function for xilinx serial >> driver simply returns false. I'm reffering the following file: >> /c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c where the >> tcsetattr function fails. I'm looking at the older implementations of >> uart for xilinx and your recent commits to solve this issue. I'm also >> studying the new Termios driver and it would be helpful if you can >> refer some approach or other guidelines for this exercise. >> >> > I do not think any termios attributes have been supported in the Zynq > driver. I think Sebastian has made the call return false which is an error > which is correct. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Issue with 'rtems_shell_wait_for_input' function
Hello Sebastian, all, Sir as you said the uart_set_attributes function for xilinx serial driver simply returns false. I'm reffering the following file: /c/src/lib/libbsp/arm/xilinx-zynq/console/zynq-uart.c where the tcsetattr function fails. I'm looking at the older implementations of uart for xilinx and your recent commits to solve this issue. I'm also studying the new Termios driver and it would be helpful if you can refer some approach or other guidelines for this exercise. Regards, Vivek On Tue, Mar 7, 2017 at 8:21 PM, Sebastian Huber wrote: > On 03/03/17 23:50, vivek kukreja wrote: >> >> Hello all, >> >> I made few changes to the fileio test to run NFS using libbsd. The test >> compiles and when i run it on qemu NFS is initialised. >> >> The test starts with the 'rtems_shell_wait_for_input' function which >> returns RTEMS_UNSATISFIED so the test quits as soon as it begins. I read >> this means the terminal related attributes could not be set. When i bypass >> this function to directly start the test it works fine. Im not sure this is >> a bug or some problem with my configuration. Any help with this issue is >> appreciated! > > > The serial driver doesn't implement the set attributes device handler > properly and returns an error. > > -- > 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: Queries regarding Tracing related bugs and GSoC 2017
Hello Gedare, everyone, I have created a ticket for the Run-Time Tracing project at: https://devel.rtems.org/ticket/2961#ticket The project description includes all the project ideas discussed on the Tracing projects page. Some details in the ticket may need to be modified for example the target RTEMS version. I'm not sure who will be the owner/mentor for this effort so I have left it blank for now. Meanwhile I have put up the first draft of my proposal on the RTEMS GSoC 2017 page. Here is the link: https://docs.google.com/document/d/1-IoZwnO1W914SJnTTeoLD6ljHJZqKBNvqZdn2gfUtkc/edit?usp=sharing I would request you and other concerned experts to review my proposal and suggest any modifications. I'm also looking into the timeout errors I faced in the capture and fileio examples. I will try to resolve these issues at the earliest. Regards, Vivek On Wed, Mar 22, 2017 at 9:13 PM, Gedare Bloom wrote: > On Sun, Mar 19, 2017 at 11:23 AM, vivek kukreja > wrote: >> Hello developers, >> >> I have worked on CTF tracing last year under GSoC. I was working on my >> previous deliverables and i noticed there are some bugs in the current >> capture and function tracing examples on qemu for arm/xilinx_zynq_a9, >> related to recent updates made to TCB and termios implementation. I'm >> working on resolving these issues so I can merge my previous changes. >> I have mailed Chris regarding this and I was suggested to ping the >> developer list for further clarification on these errors, and whether >> I should create any tickets. >> > Good. Probably you should have a ticket related to the project. Maybe > create a GSoC Project ticket. > >> I also wanted to enquire about the status of the Live tracing project >> this year in GSoC. I'm considering the following ideas for a proposal, >> once the tracing support is re-established: >> >> 1. libDWARF integration: I've been studying libDWARF for >> functionalities that can be ported to RTEMS, for the purpose of >> finding function signatures and variable types to be traced by the >> trace linker. This can be used to auto-configure the signatures/types >> at the trace linking phase of an application. >> >> 2. Transports API: In GSoC 2016 I worked on transport for moving >> traces to host. I investigated serial and USB transport apart from >> ethernet using libBSD. There is discussion on the Tracing projects >> page about integrating all transports and providing an API for custom >> transports in the application for both capture and function tracing. >> >> 3. Live tracing: In capture tracing, the trace process has to be >> paused before reading the trace (as discussed with Jennifer Averrett, >> the previous contributor). I'm looking at alternatives like copying >> the unsafe buffer to a new one which can in turn be dumped on host >> using NFS or other transport options. We can create a low priority >> task for this purpose, along with the trace buffering functions >> defined in rtld-trace-buffer.ini. >> >> Please suggest any improvements or additions to the above ideas. Also >> I dont know if there is any interest in this project for GSoC 2017 but >> I would like to merge my previous changes soon nonetheless. >> > This continues to be an important area to support. I suspect a > "Transports API" would be a good beneficial project to scope out and > understand. Without Transports, it is hard to create a uniform > approach to live tracing that would work well across Architectures/BSP > families. > >> Regards, >> Vivek >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Queries regarding Tracing related bugs and GSoC 2017
Hello developers, I have worked on CTF tracing last year under GSoC. I was working on my previous deliverables and i noticed there are some bugs in the current capture and function tracing examples on qemu for arm/xilinx_zynq_a9, related to recent updates made to TCB and termios implementation. I'm working on resolving these issues so I can merge my previous changes. I have mailed Chris regarding this and I was suggested to ping the developer list for further clarification on these errors, and whether I should create any tickets. I also wanted to enquire about the status of the Live tracing project this year in GSoC. I'm considering the following ideas for a proposal, once the tracing support is re-established: 1. libDWARF integration: I've been studying libDWARF for functionalities that can be ported to RTEMS, for the purpose of finding function signatures and variable types to be traced by the trace linker. This can be used to auto-configure the signatures/types at the trace linking phase of an application. 2. Transports API: In GSoC 2016 I worked on transport for moving traces to host. I investigated serial and USB transport apart from ethernet using libBSD. There is discussion on the Tracing projects page about integrating all transports and providing an API for custom transports in the application for both capture and function tracing. 3. Live tracing: In capture tracing, the trace process has to be paused before reading the trace (as discussed with Jennifer Averrett, the previous contributor). I'm looking at alternatives like copying the unsafe buffer to a new one which can in turn be dumped on host using NFS or other transport options. We can create a low priority task for this purpose, along with the trace buffering functions defined in rtld-trace-buffer.ini. Please suggest any improvements or additions to the above ideas. Also I dont know if there is any interest in this project for GSoC 2017 but I would like to merge my previous changes soon nonetheless. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Error in Trace buffering related to TCB struct upgrade
Hello developers, I am working on trace buffering, referring: https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering I compiled the fileio example as instructed but trace linker(rtems-tld) throws a wrapper compilation error related to struct Thread_Control. The TCB struct implementation was upgraded recently but support for function tracing seems broken: error: 'struct _Thread_Control' has no member named 'real_priority'; did you mean 'Real_priority'? I am going through the changes to TCB struct to hopefully fix back the support. If someone has worked on this before, any pointers are appreciated! Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Issue with 'rtems_shell_wait_for_input' function
Hello all, I made few changes to the fileio test to run NFS using libbsd. The test compiles and when i run it on qemu NFS is initialised. The test starts with the 'rtems_shell_wait_for_input' function which returns RTEMS_UNSATISFIED so the test quits as soon as it begins. I read this means the terminal related attributes could not be set. When i bypass this function to directly start the test it works fine. Im not sure this is a bug or some problem with my configuration. Any help with this issue is appreciated! Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem configuring ethernet interface for NFS in rtems-libbsd
Hello Sebastian,
I figured out my error. I was using a smaller stack size until last year so the
nfs client hung up on initialising. I reset some config values and its working
now. Thank you for your help.
Regards,
Vivek
> On 14-Feb-2017, at 19:18, vivek kukreja wrote:
>
> Hello Sebastian,
>
> The output of the qemu command is as follows:
>
> Warning: nic cadence_gem.1 has no peer
> nexus0:
> zy7_slcr0: on nexus0
> cgem0: on nexus0
> miibus0: on cgem0
> e1000phy0: PHY 0 on miibus0
> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseT-FDX, 1000baseT-FDX-master, auto
> e1000phy1: PHY 23 on miibus0
> e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseT-FDX, 1000baseT-FDX-master, auto
> cgem0: Ethernet address: 52:54:00:12:34:56
> [zone: socket] kern.ipc.maxsockets limit reached
> [zone: udp_inpcb] kern.ipc.maxsockets limit reached
> [zone: udpcb] kern.ipc.maxsockets limit reached
> cgem0: cgem_mediachange: could not set ref clk0 to 2500
>
> I tried attaching the debug log file (partial) generated by using the
> '-d exec' option but its too large (atleast 25 MB).
>
> I debugged the code and found that control reaches till the
> 'rtems_bsd_program_call' function(under
> rtems-libbsd/rtemsbsd/rtems/rtems-program.c) and stops at the
> following step:
>
> if (setjmp(prog_ctrl->return_context) == 0) {
> exit_code = (*prog)(context);
> }
>
> I think execution gets stuck at the assignment statement. I'm still
> working on this and thank you for helping.
>
> Regards,
> Vivek
>
> On Tue, Feb 14, 2017 at 3:51 PM, Sebastian Huber
> wrote:
>>
>>
>>> On 14/02/17 11:10, vivek kukreja wrote:
>>>
>>> Hello developers,
>>>
>>> I'm working on transporting application traces to host using the
>>> libbsd ethernet driver. I have compiled an app for
>>> arm/xilinx_zynq_a9_qemu and used the rtems bsd commands to setup NFS
>>> in the app.
>>> This example used to work until last year but the implementation of
>>> the function 'rtems_bsd_command_ifconfig' has been changed since. I'm
>>> getting the following error on qemu while trying to setup the ethernet
>>> interface:
>>>
>>> [zone: socket] kern.ipc.maxsockets limit reached
>>> [zone: udp_inpcb] kern.ipc.maxsockets limit reached
>>> [zone: udpcb] kern.ipc.maxsockets limit reached
>>
>>
>> I am not sure if this is really an error. Could you please send the complete
>> log messages.
>>
>> --
>> 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: Problem configuring ethernet interface for NFS in rtems-libbsd
Hello Sebastian,
The output of the qemu command is as follows:
Warning: nic cadence_gem.1 has no peer
nexus0:
zy7_slcr0: on nexus0
cgem0: on nexus0
miibus0: on cgem0
e1000phy0: PHY 0 on miibus0
e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto
e1000phy1: PHY 23 on miibus0
e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto
cgem0: Ethernet address: 52:54:00:12:34:56
[zone: socket] kern.ipc.maxsockets limit reached
[zone: udp_inpcb] kern.ipc.maxsockets limit reached
[zone: udpcb] kern.ipc.maxsockets limit reached
cgem0: cgem_mediachange: could not set ref clk0 to 2500
I tried attaching the debug log file (partial) generated by using the
'-d exec' option but its too large (atleast 25 MB).
I debugged the code and found that control reaches till the
'rtems_bsd_program_call' function(under
rtems-libbsd/rtemsbsd/rtems/rtems-program.c) and stops at the
following step:
if (setjmp(prog_ctrl->return_context) == 0) {
exit_code = (*prog)(context);
}
I think execution gets stuck at the assignment statement. I'm still
working on this and thank you for helping.
Regards,
Vivek
On Tue, Feb 14, 2017 at 3:51 PM, Sebastian Huber
wrote:
>
>
> On 14/02/17 11:10, vivek kukreja wrote:
>>
>> Hello developers,
>>
>> I'm working on transporting application traces to host using the
>> libbsd ethernet driver. I have compiled an app for
>> arm/xilinx_zynq_a9_qemu and used the rtems bsd commands to setup NFS
>> in the app.
>> This example used to work until last year but the implementation of
>> the function 'rtems_bsd_command_ifconfig' has been changed since. I'm
>> getting the following error on qemu while trying to setup the ethernet
>> interface:
>>
>> [zone: socket] kern.ipc.maxsockets limit reached
>> [zone: udp_inpcb] kern.ipc.maxsockets limit reached
>> [zone: udpcb] kern.ipc.maxsockets limit reached
>
>
> I am not sure if this is really an error. Could you please send the complete
> log messages.
>
> --
> 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
Problem configuring ethernet interface for NFS in rtems-libbsd
Hello developers, I'm working on transporting application traces to host using the libbsd ethernet driver. I have compiled an app for arm/xilinx_zynq_a9_qemu and used the rtems bsd commands to setup NFS in the app. This example used to work until last year but the implementation of the function 'rtems_bsd_command_ifconfig' has been changed since. I'm getting the following error on qemu while trying to setup the ethernet interface: [zone: socket] kern.ipc.maxsockets limit reached [zone: udp_inpcb] kern.ipc.maxsockets limit reached [zone: udpcb] kern.ipc.maxsockets limit reached I am trying to correctly configure the resources in my app (by following the nfs01 test in rtems-libbsd) but any pointers regarding this issue are appreciated. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem while linking rtems-libbsd with application
> On 13-Feb-2017, at 12:36, vivek kukreja wrote: > > Hello Chris, > > I have tried compiling the app with -lm flag but to no avail. I think the > rtems-libbsd waf build process has to be modified a bit to link sfp.c using > the -lm flag. I tried altering the libbsd waf script but couldn't fix the > error. I'm trying to fix it and any help is greatly appreciated. :) Nevermind. I cloned and reinstalled the latest rtems-libbsd and now the app compiles using the -lm flag. Thanks a lot! > Regards, > Vivek > >>> On 09-Feb-2017, at 07:54, Chris Johns wrote: >>> >>> On 09/02/2017 09:54, vivek kukreja wrote: >>> Hello all, >> >> Hello and welcome back to RTEMS. >> >>> >>> I have setup rtems for arm/xilinx_zynq_a9_qemu pair and installed >>> rtems-libbsd. Im trying to run NFS in an application but i get an >>> error while linking libbsd drivers. I use the following commands to >>> compile the application: >>> >>> arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs >>> bsp_specs -qrtems -DHAVE_CONFIG_H -I. >>> -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio -I.. >>> -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/../support/include >>> -I/home/vivek/sandbox/rtems-libbsd/rtemsbsd/include >>> -I/home/vivek/sandbox/rtems-libbsd/freebsd/include >>> -I/home/vivek/sandbox/rtems-libbsd/freebsd/sys -march=armv7-a >>> -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g >>> -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes >>> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs >>> -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o >>> /home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio/init.c >>> mv -f .deps/init.Tpo .deps/init.Po >>> arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs >>> bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard >>> -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall >>> -Wmissing-prototypes -Wimplicit-function-declaration >>> -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections >>> -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 >>> -o fileio.exe init.o >>> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a >>> >>> I'm getting the following error: >>> >>> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a(sfp.c.12.o): >>> In function `convert_sff_power': >>> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/../../freebsd/sbin/ifconfig/sfp.c:614: >>> undefined reference to `log10' >>> >>> I think this is a linking issue(in the rtems-libbsd build) and i'm >>> reinstalling libbsd to double-check. If anyone has come across this >>> error before please help me resolve it. >>> >> >> Try adding -lm to the libraries you need to link with. It looks to me like >> the recent changes Sebastian has made with libbsd has added a dependence on >> the libm.a library. >> >> Chris >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem while linking rtems-libbsd with application
Hello Chris, I have tried compiling the app with -lm flag but to no avail. I think the rtems-libbsd waf build process has to be modified a bit to link sfp.c using the -lm flag. I tried altering the libbsd waf script but couldn't fix the error. I'm trying to fix it and any help is greatly appreciated. :) Regards, Vivek > On 09-Feb-2017, at 07:54, Chris Johns wrote: > >> On 09/02/2017 09:54, vivek kukreja wrote: >> Hello all, > > Hello and welcome back to RTEMS. > >> >> I have setup rtems for arm/xilinx_zynq_a9_qemu pair and installed >> rtems-libbsd. Im trying to run NFS in an application but i get an >> error while linking libbsd drivers. I use the following commands to >> compile the application: >> >> arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs >> bsp_specs -qrtems -DHAVE_CONFIG_H -I. >> -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio -I.. >> >> -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/../support/include >> -I/home/vivek/sandbox/rtems-libbsd/rtemsbsd/include >> -I/home/vivek/sandbox/rtems-libbsd/freebsd/include >> -I/home/vivek/sandbox/rtems-libbsd/freebsd/sys -march=armv7-a >> -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g >> -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes >> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs >> -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o >> /home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio/init.c >> mv -f .deps/init.Tpo .deps/init.Po >> arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs >> bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard >> -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall >> -Wmissing-prototypes -Wimplicit-function-declaration >> -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections >> -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 >> -o fileio.exe init.o >> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a >> >> I'm getting the following error: >> >> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a(sfp.c.12.o): >> In function `convert_sff_power': >> /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/../../freebsd/sbin/ifconfig/sfp.c:614: >> undefined reference to `log10' >> >> I think this is a linking issue(in the rtems-libbsd build) and i'm >> reinstalling libbsd to double-check. If anyone has come across this >> error before please help me resolve it. >> > > Try adding -lm to the libraries you need to link with. It looks to me like > the recent changes Sebastian has made with libbsd has added a dependence on > the libm.a library. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Problem while linking rtems-libbsd with application
Hello all, I have setup rtems for arm/xilinx_zynq_a9_qemu pair and installed rtems-libbsd. Im trying to run NFS in an application but i get an error while linking libbsd drivers. I use the following commands to compile the application: arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I. -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio -I.. -I/home/vivek/sandbox/rtems/c/src/../../testsuites/samples/../support/include -I/home/vivek/sandbox/rtems-libbsd/rtemsbsd/include -I/home/vivek/sandbox/rtems-libbsd/freebsd/include -I/home/vivek/sandbox/rtems-libbsd/freebsd/sys -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o /home/vivek/sandbox/rtems/c/src/../../testsuites/samples/fileio/init.c mv -f .deps/init.Tpo .deps/init.Po arm-rtems4.12-gcc -B../../../../../xilinx_zynq_a9_qemu/lib/ -specs bsp_specs -qrtems -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -o fileio.exe init.o /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a I'm getting the following error: /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/libbsd.a(sfp.c.12.o): In function `convert_sff_power': /home/vivek/sandbox/rtems-libbsd/build/arm-rtems4.12-xilinx_zynq_a9_qemu/../../freebsd/sbin/ifconfig/sfp.c:614: undefined reference to `log10' I think this is a linking issue(in the rtems-libbsd build) and i'm reinstalling libbsd to double-check. If anyone has come across this error before please help me resolve it. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC 2017: Live tracing project status
Hello Chris, all, This is in response to Gedare's mail regarding project ideas for GSoC 2017. I am looking forward to applying under RTEMS as a student again this year. I am currently updating my previous code(for CTF integration and ethernet transport) with the mainline repo changes and preparing a detailed doc. I couldn't commit much time this year but i hope to cover up before summer. I would like you to please review my work so i can further improve the code. Also, i wanted to enquire about the status of the Live tracing project this year. I am investigating libDWARF support for RTEMS and further improvements to support live tracing and make the tracing support more automated. I wanted to clarify whether this is a priority before i start working on my proposal. I'm excited to explore other related open projects too. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Help required with setting up TFTP communication between QEMU instance and host machine
Hi Chris, Thank you for your prompt advice regarding tap interface. I followed this mail chain and successfully run the ping01 example in rtems-libbsd: https://lists.rtems.org/pipermail/users/2015-June/029063.html Now I can ping and FTP into the QEMU instance from host machine! Regards, Vivek > On 23-Jul-2016, at 01:04, Chris Johns wrote: > >> 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 and all >> examples are building with QEMU for arm. >> The testsuite has examples of a TFTP(and NFS) client running on the >> loopback interface, but I need help with configuring the ethernet >> interface. > > Please look at the rcconf01 test: > > https://git.rtems.org/rtems-libbsd/tree/testsuite/rcconf01/test_main.c#n43 > > Create an in memory rc.conf file with: > > hostname=vivek > ifconfig_cgem0="inet 1.2.3.4 netmask 255.255.255.0" > defaultrouter="1.2.3.1" > > Call 'rtems_bsd_run_rc_conf_script' with the script. > >> If someone has worked on setting up communication between RTEMS target >> and host machine, or has similar examples please share. Any help is >> appreciated! > > If you are on Linux you need to set up a tap and then get qemu to use the > tap. I do not use Linux so I cannot help. > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Help required with setting up TFTP communication between QEMU instance and host machine
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 with QEMU for arm. The testsuite has examples of a TFTP(and NFS) client running on the loopback interface, but I need help with configuring the ethernet interface. If someone has worked on setting up communication between RTEMS target and host machine, or has similar examples please share. Any help is appreciated! PS: As a hack I have tried setting up SSH between the QEMU instance and host but it's a hack. The transport mechanisms will be tested on hardware next. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Help required with RTEMS Capture Engine.
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 think this should be my starting point. Regards, Vivek On Fri, Jul 22, 2016 at 6:09 AM, Chris Johns wrote: > 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 think the buffer is protected when it is running. > > > Thanks. This makes streaming difficult and so it will need to change at some > point in time. The pre-smp version was designed to allow streaming. > > Vivek, you will have to run a trace and then stop the capture and extract > the data. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Help required with RTEMS Capture Engine.
Hello all, I'm Vivek Kukreja and i'm working on Capture Engine for GSoC this year. I'm running rtems 4.12 and I came across an error on running the capture.exe example to trace user extensions. The 'ctrace' command is giving an error RTEMS_UNSATISFIED. I think this error is due to a faulty if condition in cpukit/libmisc/capture.c I think the following exit condition is inconsistent: if ( (capture_flags_global & RTEMS_CAPTURE_ON) != 0 ) And it should be: if ( (capture_flags_global & RTEMS_CAPTURE_ON) == 0 ) I've been asked to open a ticket for this bug but i wanted to confirm beforehand if anyone else faced this issue, since the capture engine code was commited 16months back. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Hello Chris, > On 30-May-2016, at 10:38, Chris Johns wrote: > >> On 30/05/2016 13:51, vivek kukreja wrote: >> >> The init.c file for capture example doesnt include confdefs.h. Are there any >> other examples i can look at? > > The capture init.c in the testsuite includes system.h. I suggest you take a > look in that file. In system.h file i tried increasing minimum stack size, number of tasks etc but the problem persists. >> The ctrace command(specifically rtems_capture_print_trace_records function) >> calls rtems_capture_read to read records from cpu buffers which returns >> RTEMS_UNSATISFIED. > > Why does that function return that status code? Because RTEMS_CAPTURE_ON flag is set in capture_flags_global. First we set the flag when we run cenable command but while running ctrace command we want the flag to be unset. This made no sense to me. I tried looking up solutions online but couldn't find since many links are for RTEMS 4.11 or before. I'm looking at older versions of capture engine now to better understand the problem. If you have any thoughts please share. > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Hello Chris, The init.c file for capture example doesnt include confdefs.h. Are there any other examples i can look at? The ctrace command(specifically rtems_capture_print_trace_records function) calls rtems_capture_read to read records from cpu buffers which returns RTEMS_UNSATISFIED. Regards, Vivek > On 28-May-2016, at 04:11, Chris Johns wrote: > >> On 27/05/2016 4:22 PM, vivek kukreja wrote: >> Now the ctrace command returns the following error: >> trace read failed: RTEMS_UNSATISFIED. > > Is there enough resources defined in your init.c where confdefs.h is included? > >> I think the problem lies in rtems_capture_read function call in >> capture_support.c file. Im trying to debug the capture engine code. Does >> anyone how to resolve this? > > Do you know what the call is? > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Now the ctrace command returns the following error: trace read failed: RTEMS_UNSATISFIED. I think the problem lies in rtems_capture_read function call in capture_support.c file. Im trying to debug the capture engine code. Does anyone how to resolve this? > On 26-May-2016, at 23:56, vivek kukreja wrote: > >> On Thu, May 26, 2016 at 6:16 PM, vivek kukreja >> wrote: >> >> Hello all, >> >> I'm facing a problem with function tracing. I made changes to rtems-tld >> command to ouput a CTF metadata file but i need sizes of arguments and >> return values at compile-time to be put in the metadata file. >> For now i have yet to put actual variable sizes. Any recommendations how to >> go about it? We could use shared libraries or gdb along with >> fileio-wrapper.o to identify variables and sizes from symbol table. >> >> Also, my tasks for this week include tracing user-extensions and converting >> them to CTF. >> I followed the tutorial on >> https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt to >> run capture.exe example but failed. >> Is building grub image necessary? Trying to run the example for >> xilinx_zynq_a9_qemu bsp directly on Qemu doesn't seem to work. RMON task is >> visible in the init tasks list but 'ctset RMON' command fails. Any >> suggestions how to make this work? >>> Nevermind. Instead of RMON I had to put object id of the task(argument). >> >> >> Regards, >> Vivek >> >>> On Tue, May 24, 2016 at 6:56 AM, Chris Johns wrote: >>> >>>> On 23/05/2016 23:19, Isaac Gutekunst wrote: >>>> >>>> Hi Vivek, >>>> >>>> This is looking good! >>> >>> >>> I agree. >>> >>> >>>> I somewhat sketchy solution for getting binary files off a target is to >>>> print them as intel hex, and copy them from the terminal. If the Zynq >>>> bsp supports networking, you could setup a TFTP server. My ugly trace >>>> implementation implements the lttng-live protocol for getting the CTF >>>> stream off the target. >>>> >>>> See >>>> https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt >>>> >>>> >>>> Chris, do you think it's worth going down this path yet? I think this is >>>> the best long term solution, as it makes RTEMS targets with networking >>>> support remotely traceable with babeltrace and Trace Compass. >>> >>> We will have to at some stage so what ever effort is spent should help us >>> get a step closer. We just need monitor it does not stall the main focus of >>> the work. At the moment it is looking like the best solution to getting >>> data of the boards. >>> >>>> I'm a little confused how the BSD, old style, and lwip networking stacks >>>> differ, and whether it would be possible to target all three easily. >>> >>> >>> This is a general area of confusion and flux. >>> >>>> My >>>> understanding is that the existing stack, and the BSD stack both >>>> integrate into the RTEMS filesystem (have file descriptors), while LWIP >>>> has some super ugly macros that redefine read/write/etc. >>> >>> >>> Let me document here what currently exists for LibBSD stack and the legacy >>> stack. Maybe Pavel can help with the LwIP stack. >>> >>> Legacy Stack (stack in the RTEMS source tree): >>> >>> 1. Configured by tables and calls. Documented in the RTEMS Network >>> Supplement. >>> 2. Has network file system support for NFSv2, FTP and TFTP. >>> >>> LibBSD Stack >>> >>> 1. Configured using FreeBSD rc.conf(5) format files. I have only just added >>> this support and it is limited but functional interface with static >>> configurations. I am working on this support. The tar support changes I >>> have recently posted and the RTEMS print changes are all related to this >>> support. >>> 2. No networked file system support. This is an important issue that needs >>> to be resolved. >>> >>> Chris >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
On Thu, May 26, 2016 at 6:16 PM, vivek kukreja wrote: > > Hello all, > > I'm facing a problem with function tracing. I made changes to rtems-tld > command to ouput a CTF metadata file but i need sizes of arguments and return > values at compile-time to be put in the metadata file. > For now i have yet to put actual variable sizes. Any recommendations how to > go about it? We could use shared libraries or gdb along with fileio-wrapper.o > to identify variables and sizes from symbol table. > > Also, my tasks for this week include tracing user-extensions and converting > them to CTF. > I followed the tutorial on > https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt to > run capture.exe example but failed. > Is building grub image necessary? Trying to run the example for > xilinx_zynq_a9_qemu bsp directly on Qemu doesn't seem to work. RMON task is > visible in the init tasks list but 'ctset RMON' command fails. Any > suggestions how to make this work? >> Nevermind. Instead of RMON I had to put object id of the task(argument). > > > Regards, > Vivek > > On Tue, May 24, 2016 at 6:56 AM, Chris Johns wrote: >> >> On 23/05/2016 23:19, Isaac Gutekunst wrote: >>> >>> Hi Vivek, >>> >>> This is looking good! >> >> >> I agree. >> >> >>> I somewhat sketchy solution for getting binary files off a target is to >>> print them as intel hex, and copy them from the terminal. If the Zynq >>> bsp supports networking, you could setup a TFTP server. My ugly trace >>> implementation implements the lttng-live protocol for getting the CTF >>> stream off the target. >>> >>> See >>> https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt >>> >>> >>> Chris, do you think it's worth going down this path yet? I think this is >>> the best long term solution, as it makes RTEMS targets with networking >>> support remotely traceable with babeltrace and Trace Compass. >>> >> >> We will have to at some stage so what ever effort is spent should help us >> get a step closer. We just need monitor it does not stall the main focus of >> the work. At the moment it is looking like the best solution to getting data >> of the boards. >> >>> I'm a little confused how the BSD, old style, and lwip networking stacks >>> differ, and whether it would be possible to target all three easily. >> >> >> This is a general area of confusion and flux. >> >>> My >>> understanding is that the existing stack, and the BSD stack both >>> integrate into the RTEMS filesystem (have file descriptors), while LWIP >>> has some super ugly macros that redefine read/write/etc. >> >> >> Let me document here what currently exists for LibBSD stack and the legacy >> stack. Maybe Pavel can help with the LwIP stack. >> >> Legacy Stack (stack in the RTEMS source tree): >> >> 1. Configured by tables and calls. Documented in the RTEMS Network >> Supplement. >> 2. Has network file system support for NFSv2, FTP and TFTP. >> >> LibBSD Stack >> >> 1. Configured using FreeBSD rc.conf(5) format files. I have only just added >> this support and it is limited but functional interface with static >> configurations. I am working on this support. The tar support changes I have >> recently posted and the RTEMS print changes are all related to this support. >> 2. No networked file system support. This is an important issue that needs >> to be resolved. >> >> Chris > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Hello all, I'm facing a problem with function tracing. I made changes to rtems-tld command to ouput a CTF metadata file but i need sizes of arguments and return values at compile-time to be put in the metadata file. For now i have yet to put actual variable sizes. Any recommendations how to go about it? We could use shared libraries or gdb along with fileio-wrapper.o to identify variables and sizes from symbol table. Also, my tasks for this week include tracing user-extensions and converting them to CTF. I followed the tutorial on https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt to run capture.exe example but failed. Is building grub image necessary? Trying to run the example for xilinx_zynq_a9_qemu bsp directly on Qemu doesn't seem to work. RMON task is visible in the init tasks list but 'ctset RMON' command fails. Any suggestions how to make this work? Regards, Vivek On Tue, May 24, 2016 at 6:56 AM, Chris Johns wrote: > On 23/05/2016 23:19, Isaac Gutekunst wrote: > >> Hi Vivek, >> >> This is looking good! >> > > I agree. > > I somewhat sketchy solution for getting binary files off a target is to >> print them as intel hex, and copy them from the terminal. If the Zynq >> bsp supports networking, you could setup a TFTP server. My ugly trace >> implementation implements the lttng-live protocol for getting the CTF >> stream off the target. >> >> See >> >> https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt >> >> >> Chris, do you think it's worth going down this path yet? I think this is >> the best long term solution, as it makes RTEMS targets with networking >> support remotely traceable with babeltrace and Trace Compass. >> >> > We will have to at some stage so what ever effort is spent should help us > get a step closer. We just need monitor it does not stall the main focus of > the work. At the moment it is looking like the best solution to getting > data of the boards. > > I'm a little confused how the BSD, old style, and lwip networking stacks >> differ, and whether it would be possible to target all three easily. >> > > This is a general area of confusion and flux. > > My >> understanding is that the existing stack, and the BSD stack both >> integrate into the RTEMS filesystem (have file descriptors), while LWIP >> has some super ugly macros that redefine read/write/etc. >> > > Let me document here what currently exists for LibBSD stack and the legacy > stack. Maybe Pavel can help with the LwIP stack. > > Legacy Stack (stack in the RTEMS source tree): > > 1. Configured by tables and calls. Documented in the RTEMS Network > Supplement. > 2. Has network file system support for NFSv2, FTP and TFTP. > > LibBSD Stack > > 1. Configured using FreeBSD rc.conf(5) format files. I have only just > added this support and it is limited but functional interface with static > configurations. I am working on this support. The tar support changes I > have recently posted and the RTEMS print changes are all related to this > support. > 2. No networked file system support. This is an important issue that needs > to be resolved. > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Weekly GSoC IRC Meetings: Wed 10am EDT
I am sorry Gedare i couldn't appear for the meeting. I was travelling and i couldn't check my mail. I will be present for the next meeting or if you could schedule another meeting this week itself. I'm maintaining a few documents on Google docs and will upload a blog by tomorrow. Also i'm facing some issues with the capture-engine examples. I will write another mail to put up my doubts. Vivek On Tue, May 24, 2016 at 8:31 PM, Gedare Bloom wrote: > We will have our first weekly IRC meeting for GSoC students tomorrow, > Wednesday May 25 10:00 A.M. Eastern Daylight Savings Time (EDT: UTC-4) > hence 14:00 UTC/GMT. The purpose of these meetings is for each student > to briefly (about 5 minutes) discuss what they have been working on, > and what they will work on for the upcoming week. Joel or I will > moderate and ask questions, and other mentors or community members may > be there as well. Each student will also update their status on the > GSoC Tracking Page on our wiki. > > All mentors and the community are welcomed to attend, but we do ask > that during this time you keep non-GSoC discussions offline to > facilitate a quick meeting. > > Gedare > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Hello all, Thanks for the prompt answer regarding libBSD drivers Chris. I found a few links and have setup Qemu for Xilinx Zynq A9. I will try to build drivers for USB and Ethernet and run a few examples on qemu by next week. I have made some rudimentary changes in rtems-tld and rtrace shell utiltiy to print traces in CTF. I tested these changes on fileio.exe example for both sparc/erc32 and arm/xilinx_zynq_a9_qemu(tested on qemu). I am working on producing metadata in TSDL format as required by CTF 1.9. I will send patches for review this week. Once we have trace in CTF we can write Babeltrace scripts for testing the output. However, CTF bitstream is produced on target and pulling it on host is tricky. Is there any solution apart from copy-pasting from terminal? Also, I'm trying to trace user-extensions by running multiple applications on Qemu for better understanding. These traces will be converted to CTF next. Any comments regarding my project plan or progress are welcome. Regards, Vivek On Tue, May 10, 2016 at 2:40 PM, vivek kukreja wrote: > Hello Chris, Joel, Isaac, > > Sorry for the delay in getting back. I was ill for the last couple days. > > Here is a quick status update, > > * Setup my work environment. Earlier I was using RTEMS version 4.11 > because I could not download the source code for 4.12 from GIT in my > university network. I have not moved to the new version. > > * Compiled the Xilinx Qemu BSP. I am unable to find help on how to run the > BSP on Qemu however. I will send another mail to ask for help on the list. > > * Prepared some documents to plan the project and track progress. Please > take a look at these documents, and recommend any changes. > https://drive.google.com/open?id=0B2FBdgOy1yWXWE44RnhNLXUwLVU > > * Started studying Babeltrace to understand its capabilities. > > In the rest of the week, I will > > * Study the source code for scheduler events tracing in User Extensions. > > * Ensure that I have the BSP running on Qemu. > > * Port my experimental changes in RTEMS TLD to the version 4.12 and share > patches with you, to get some feedback. > > On Wed, Apr 27, 2016 at 6:45 PM, vivek kukreja > wrote: > >> Hello all >> >> Thank you for your help and support. My proposal for Tracing tool >> improvements has been accepted in GSOC 2016. >> >> I will be occupied with university exams for the rest of this week. I >> will update the RTEMS page over the weekend. I will be able to commit >> full-time to the project in the coming weeks during my vacations. >> >> I am thrilled to start working on this project! >> >> Regards, >> Vivek >> > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Require help with running Xilinx Zynq Qemu BSP
Hello Chris, I am preparing for the next phase of my project where I will implement live-tracing over transport. For that drivers for USB and Ethernet have to be loaded in qemu. How will that work? Regards, Vivek > On 11-May-2016, at 05:30, Chris Johns wrote: > >> On 11/05/2016 02:57, vivek kukreja wrote: >> Hello, >> >> Sorry for not framing the question properly. >> >> I know how to run an application on the baremetal, with the command you >> have mentioned. But I want to know how to run a complete RTEMS boot >> image, along with OS components on the emulator. >> >> In the document that I have given a link above, the steps for running a >> boot image for i386 have been mentioned. > > Those instructions are for a PC and assume PC type hardware. > >> Is the similar possible for the Xilinx Zynq too? > > With the Zynq all you need to pass to qemu is the kernel image. > > What are wanting to do with the qemu and the Zynq BSP? > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Require help with running Xilinx Zynq Qemu BSP
Hello, Sorry for not framing the question properly. I know how to run an application on the baremetal, with the command you have mentioned. But I want to know how to run a complete RTEMS boot image, along with OS components on the emulator. In the document that I have given a link above, the steps for running a boot image for i386 have been mentioned. Is the similar possible for the Xilinx Zynq too? On Tue, May 10, 2016 at 4:02 PM, Jan Sommer wrote: > Am 2016-05-10 11:22, schrieb vivek kukreja: > >> Hello all, >> >> I have compiled the RTEMS 4.12 to generate BSP for Xilinx Zynq Qemu. >> However, I am unable to find any documents on how to run the BSP. >> >> I tried using this document >> https://devel.rtems.org/wiki/Developer/Simulators/QEMU >> but this does not mention the steps for Xilinx Zynq, and also some of the >> links in the document are dead. >> >> I haven't used Qemu, and will appreciate if someone can point me to the >> right document or give me tips to get this running. >> >> > I built a recent mainline qemu and could run an application with the > following command > > qemu-system-arm -no-reboot \ > -serial null -serial mon:stdio \ > -net none -nographic \ > -M xilinx-zynq-a9 \ > -m 256M \ > -kernel ticker/ticker.exe > > However this only works for the xilinx_zynq_a9_qemu bsp. It might be > possible to run applications for the zedboard bsp on qemu as well with the > right device tree configuration, but I haven't tried that yet. > > Best regards, > >Jan > > Regards, >> Vivek >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
On Tue, May 10, 2016 at 11:10 AM, vivek kukreja wrote: > Hello Chris, Joel, Isaac, > > Sorry for the delay in getting back. I was ill for the last couple days. > > Here is a quick status update, > > * Setup my work environment. Earlier I was using RTEMS version 4.11 > because I could not download the source code for 4.12 from GIT in my > university network. I have not moved to the new version. > Typo! I meant, I have NOW moved to the new version. > > * Compiled the Xilinx Qemu BSP. I am unable to find help on how to run the > BSP on Qemu however. I will send another mail to ask for help on the list. > > * Prepared some documents to plan the project and track progress. Please > take a look at these documents, and recommend any changes. > https://drive.google.com/open?id=0B2FBdgOy1yWXWE44RnhNLXUwLVU > > * Started studying Babeltrace to understand its capabilities. > > In the rest of the week, I will > > * Study the source code for scheduler events tracing in User Extensions. > > * Ensure that I have the BSP running on Qemu. > > * Port my experimental changes in RTEMS TLD to the version 4.12 and share > patches with you, to get some feedback. > > On Wed, Apr 27, 2016 at 6:45 PM, vivek kukreja > wrote: > >> Hello all >> >> Thank you for your help and support. My proposal for Tracing tool >> improvements has been accepted in GSOC 2016. >> >> I will be occupied with university exams for the rest of this week. I >> will update the RTEMS page over the weekend. I will be able to commit >> full-time to the project in the coming weeks during my vacations. >> >> I am thrilled to start working on this project! >> >> Regards, >> Vivek >> > > Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Require help with running Xilinx Zynq Qemu BSP
Hello all, I have compiled the RTEMS 4.12 to generate BSP for Xilinx Zynq Qemu. However, I am unable to find any documents on how to run the BSP. I tried using this document https://devel.rtems.org/wiki/Developer/Simulators/QEMU but this does not mention the steps for Xilinx Zynq, and also some of the links in the document are dead. I haven't used Qemu, and will appreciate if someone can point me to the right document or give me tips to get this running. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC2016: Improvements in RTEMS Tracing Framework
Hello Chris, Joel, Isaac, Sorry for the delay in getting back. I was ill for the last couple days. Here is a quick status update, * Setup my work environment. Earlier I was using RTEMS version 4.11 because I could not download the source code for 4.12 from GIT in my university network. I have not moved to the new version. * Compiled the Xilinx Qemu BSP. I am unable to find help on how to run the BSP on Qemu however. I will send another mail to ask for help on the list. * Prepared some documents to plan the project and track progress. Please take a look at these documents, and recommend any changes. https://drive.google.com/open?id=0B2FBdgOy1yWXWE44RnhNLXUwLVU * Started studying Babeltrace to understand its capabilities. In the rest of the week, I will * Study the source code for scheduler events tracing in User Extensions. * Ensure that I have the BSP running on Qemu. * Port my experimental changes in RTEMS TLD to the version 4.12 and share patches with you, to get some feedback. On Wed, Apr 27, 2016 at 6:45 PM, vivek kukreja wrote: > Hello all > > Thank you for your help and support. My proposal for Tracing tool > improvements has been accepted in GSOC 2016. > > I will be occupied with university exams for the rest of this week. I > will update the RTEMS page over the weekend. I will be able to commit > full-time to the project in the coming weeks during my vacations. > > I am thrilled to start working on this project! > > Regards, > Vivek > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC2016: Improvements in RTEMS Tracing Framework
Hello all Thank you for your help and support. My proposal for Tracing tool improvements has been accepted in GSOC 2016. I will be occupied with university exams for the rest of this week. I will update the RTEMS page over the weekend. I will be able to commit full-time to the project in the coming weeks during my vacations. I am thrilled to start working on this project! Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2016 Interested in Tracing was Re:
Hello All, I am very sorry for the late response. I have my exams starting this week, until the end of the month. I should be able to contribute full-time to the project during my vacations after the exam. I have made changes to the document to provide more details about my approach and deliverables in each phase. I hope I have answered most of the questions from Joel. Isaac, I have finally managed to download the source code from GIT on my laptop. It seems that the university network was blocking traffic over GIT protocol. I am now using a private internet connection to download source code. So far, I was using the 4.11 code that I had downloaded from FTP. I will soon port my changes to 4.12 and provide you a patch to look at. Please let me know any concerns you might have, that I can resolve before the acceptance deadline. I am really hoping to get accepted, and am looking forward to working with you on this project. Regards, Vivek On Mon, Apr 4, 2016 at 2:48 PM, Isaac Gutekunst wrote: > Hi Vivek, > > Awesome progress! Sorry if I missed this, but do you have a GitHub > repository, or some location where we can take a look at your work? I'm > excited to see what changes you've made, even if they are not final yet. > > Isaac > > > On 04/02/2016 10:30 AM, vivek kukreja wrote: > >> Hi Joel >> >> Sorry for the delay in responding and thank you for your comments on my >> proposal. >> >> I would like to share my progress so far. I ran the fileio trace example >> as described on the Trace Buffering page and started studying rtems-tld. I >> made changes so that rtems-tld command auto-generates a CTF metadata file >> for a given .ini file. I assumed each buffer as a different stream >> containing events like buffer entry/exit, buffer argument, return values >> etc. >> Then i modified the buffer functions so they produce trace described by >> above metadata. >> I have also made changes to RTEMS shell utility rtrace so it can print >> trace in CTF format for analysis. >> >> Thank you for highlighting user extensions. I haven't looked into these >> yet. Can you point me to an example or a test where these are being used? I >> will study these and update the document soon. >> >> Also, as you mentioned currently capture has to be paused for generating >> trace. Im investigating how this can be addressed in the capture engine. >> Any suggestions are appreciated. For example, im looking at a >> producer-consumer solution for simultaneous read/write using 2 threads. >> >> I intend to keep the framework structure intact, and reuse the existing >> functional tests. I will extend unit tests to test the new features >> regarding CTF trace generation. >> >> By the mid-term evaluation, auto generation of metadata and trace >> wrappers that produce CTF traces will be complete. The mid term deliverable >> will have all the capabilites of current trace framework, alebit the trace >> generated will be in CTF format. That will also allow us to decode these >> traces in Babeltrace too. >> I will also pay attention to creating good examples, documentation and >> video demonstration as you have suggested. >> >> Im occupied with my college exams but I will put these details in the >> document as soon as possible. >> >> Regards, >> Vivek >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2016 Interested in Tracing was Re:
Hi Joel Sorry for the delay in responding and thank you for your comments on my proposal. I would like to share my progress so far. I ran the fileio trace example as described on the Trace Buffering page and started studying rtems-tld. I made changes so that rtems-tld command auto-generates a CTF metadata file for a given .ini file. I assumed each buffer as a different stream containing events like buffer entry/exit, buffer argument, return values etc. Then i modified the buffer functions so they produce trace described by above metadata. I have also made changes to RTEMS shell utility rtrace so it can print trace in CTF format for analysis. Thank you for highlighting user extensions. I haven't looked into these yet. Can you point me to an example or a test where these are being used? I will study these and update the document soon. Also, as you mentioned currently capture has to be paused for generating trace. Im investigating how this can be addressed in the capture engine. Any suggestions are appreciated. For example, im looking at a producer-consumer solution for simultaneous read/write using 2 threads. I intend to keep the framework structure intact, and reuse the existing functional tests. I will extend unit tests to test the new features regarding CTF trace generation. By the mid-term evaluation, auto generation of metadata and trace wrappers that produce CTF traces will be complete. The mid term deliverable will have all the capabilites of current trace framework, alebit the trace generated will be in CTF format. That will also allow us to decode these traces in Babeltrace too. I will also pay attention to creating good examples, documentation and video demonstration as you have suggested. Im occupied with my college exams but I will put these details in the document as soon as possible. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2016 Interested in Tracing
Hi Chris, Isaac I implemented a C program as Isaac said to parse and understand an example CTF trace stream based on an input config. It was really helpful to understand the overall CTF structure. Now im looking at the Capture Engine code to understand how concurrent buffering is supported and how we can integrate native CTF generation with it. Any links/references are appreciated. Also, any pointers what method we should use for trace configuration once a preliminary CTF generation scheme is ready for use with rtems-tld would be helpful for the proposal. I'm travelling so i can update my proposal draft earliest by tomorrow, apologies for the delay. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: (offlist) Re: GSoC 2016 Interested in Tracing was Re:
Hello Isaac, Thanks for your suggestions on my proposal. I will use your personal email for future correspondence. I have a few questions: Can you please share some use-cases for tracing that developers are interested in? I would like to understand the features you require at Vecna and the flow of how tracing should work for your purpose. Also can you give an overview about the lttng-live functionality you have implemented and how its used? And how it can be improved using CTF? Regards, Vivek > On 17-Mar-2016, at 17:54, Isaac Gutekunst wrote: > > I Vivek, > > Thanks for the proposal. I am looking it over now! > > Welcome to the program and hello! > > A bit about me: I'm an embedded firmware engineer at Vecna Technologis > (vecna.com). We are using RTEMS > here for our next generation robotics platform. We are also committed to > helping RTEMS through open source > contributions, including mentoring GSoC students. > > I'm really excited that you are interested in trace. There are a lot of > fascinating and fundamental concepts lurking > within. There is also a huge opportunity to provide a feature which brings > RTEMS closer to feature parity with some > of the most expensive commercial RTOSs. That's pretty awesome! I'm personally > really excited because this functionality > has immediate use cases for our robotic work here. I've already done a decent > amount of unreleased work adding > lttng-live functionality to one of our projects. It's super alpha quality, > and written in C++ which might limit its > usefulness. > > I also have a system for emitting trace messages into a different buffer (not > the RTEMS Capture Engine), since I needed > to test it on Linux. > > > Chris: Does the current capture engine allow simultaneous reading and writing > of trace data? This is an important feature for > us at Vecna, and I imagine would be useful to others. Especially with > lttng-live support. > > Chris: Should most communication be typically be done on the rtems-devel > mailing list? > > Another note: > > You seem to have received the wrong email address. For GSoC I will either be > using this email (from work), > or iguteku...@gmail.com (personal email associated with the GSoC website). > > Isaac > >> On 03/17/2016 04:10 AM, vivek kukreja wrote: >> Hi Chris, >> Sorry for the delay. I was caught up with my college assessments. >> First draft of my proposal is up and open for comments. I'm going >> through the Capturing Engine documentation now and the Project >> description will be modified once i hear your suggestions. >> >> Also git services are working now since i will be using a different >> internet connection henceforth. >> I will setup RTEMS using the latest git repo and see if the error in >> the fileio tracing example is resolved and send a patch for the >> missing include statement at the earliest. >> >> Regards, >> Vivek >> >> >> From: Chris Johns >> Sent: 16 March 2016 10:18 >> To: Vivek Kukreja; guteku...@gmail.com >> Cc: Gedare Bloom >> Subject: Re: GSoC 2016 Interested in Tracing was Re: >> >> Hi, >> >> I have reviewed your document but I could no actual proposal in the >> Google Document https://goo.gl/8jRfyV. >> >> I have updated the proposal template so please check it against your one. >> >> I suggest you fill in each section answering the questions provided. >> g and fundamental concepts lurking > within. There is also a huge opportunity to provide a feature which brings > RTEMS closer to feature parity with some > of the most expensive commercial RTOSs. That's pretty awesome! I'm personally > really exc >> Thanks. >> Chris >> >>> On 15/03/2016 00:22, Vivek Kukreja wrote: >>> Hello Chris, Isaac >>> >>> Sorry for the delay in adding a student proposal on >>> https://devel.rtems.org/wiki/GSoC/2016. Its still in progress meanwhile i >>> am looking at alternate ways of accessing git. I have not heard from Isaac >>> regarding his interest in mentoring the project but I hope Chris will >>> comment on the proposal once it takes shape. >>> >>> Also regarding an issue i posted earlier about the trace buffering example >>> described on >>> https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering, i was >>> getting an error on running the rtems-tld command(fileio-wrapper.c:388:13: >>> error: dereferencing pointer to incomplete type 'struct Thread_Control') . >&
Re: GSoC 2016 Interested in Tracing was Re:
Hi Chris,
Sorry for the delay. I was caught up with my college assessments.
First draft of my proposal is up and open for comments. I'm going
through the Capturing Engine documentation now and the Project
description will be modified once i hear your suggestions.
Also git services are working now since i will be using a different
internet connection henceforth.
I will setup RTEMS using the latest git repo and see if the error in
the fileio tracing example is resolved and send a patch for the
missing include statement at the earliest.
Regards,
Vivek
From: Chris Johns
Sent: 16 March 2016 10:18
To: Vivek Kukreja; guteku...@gmail.com
Cc: Gedare Bloom
Subject: Re: GSoC 2016 Interested in Tracing was Re:
Hi,
I have reviewed your document but I could no actual proposal in the
Google Document https://goo.gl/8jRfyV.
I have updated the proposal template so please check it against your one.
I suggest you fill in each section answering the questions provided.
Thanks.
Chris
On 15/03/2016 00:22, Vivek Kukreja wrote:
> Hello Chris, Isaac
>
> Sorry for the delay in adding a student proposal on
> https://devel.rtems.org/wiki/GSoC/2016. Its still in progress meanwhile i am
> looking at alternate ways of accessing git. I have not heard from Isaac
> regarding his interest in mentoring the project but I hope Chris will comment
> on the proposal once it takes shape.
>
> Also regarding an issue i posted earlier about the trace buffering example
> described on https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering,
> i was getting an error on running the rtems-tld
> command(fileio-wrapper.c:388:13: error: dereferencing pointer to incomplete
> type 'struct Thread_Control') .
> I found that there is an include statement in the online repo of
> rtld-trace-buffer.ini file thats somehow missing from my installation(at
> development/rtems/4.12/share/rtems/trace-linker)
> "#include"
> Now the tracing example successfully builds.
>
> Regards,
> Vivek
> ________
> From: Chris Johns
> Sent: 10 March 2016 08:11
> To: Vivek Kukreja
> Cc: guteku...@gmail.com; Gedare Bloom
> Subject: Re: GSoC 2016 Interested in Tracing was Re:
>
> On 10/03/2016 06:39, Vivek Kukreja wrote:
>> Hello Chris, Isaac
>> I have run the modified hello world example and created a patch for it. I
>> cannot access your git server from my institute probably because of some
>> firewall issues. I will look into it.
>
> Please keep me posted about the git access.
>
>> Following is the output of diff command:
>> --- rtems-4.11.0-rc1master/testsuites/samples/hello/init.c 2015-12-13
>> 04:22:53.0 -0800
>> +++ rtems-4.11.0-rc1/testsuites/samples/hello/init.c 2016-03-09
>> 10:35:51.527042759 -0800
>> @@ -28,7 +28,7 @@
>>)
>>{
>> rtems_test_begin();
>> - printf( "Hello World\n" );
>> + printf( "Hello World- Modified by Vivek Kukreja 2016\n" );
>> rtems_test_end();
>> exit( 0 );
>>}
>>
>
> The https://devel.rtems.org/wiki/GSoC/GettingStarted pages asks you to
> post to the lists your patch and then update the GSoC 2016 page at
> https://devel.rtems.org/wiki/GSoC/2016. Can you please do this? Thanks.
>
>>
>> I have gone through some recent archives of the IRC and i have some
>> questions:
>>
>> 1. RTEMS trace linker uses function wrapping to instrument linked files of
>> app to interact with capture engine(on-target) and fetching trace data. As
>> Isaac has described in this archive
>> https://www.mail-archive.com/devel@rtems.org/msg06199.html, barectf is a
>> tool used for tracing user-defined data/structs. Is it required and feasible
>> as a GSOC project to create support for this feature? As Chris said this
>> would require deciding the structure of things a bit.
>> Also, can you throw some light on 'target integration' of the capture engine
>> with rtems-tld and what tasks does it entail currently?
>
> I have updated the Open Project TraceTool wiki page. Please see have a
> look and see if that answers your questions.
>
>> 2. LTTng and barectf support CTF generation. Its required that app/kernel
>> files linked using RTEMS trace linker generate either native CTF data or
>> trace-data that can be converted to CTF. Could you share some pointers/links
>> to understand the current architecture for CTF generation in RTEMS?
>
> Currently there is no CTF support in RTEMS.
>
>> I think this feature has few prerequisites yet many features will use this.
>> For example: live trace-reading(over TCP/IP) as Isaac suggested.
>
&g
Re: GSoC 2016 Interested in Tracing was Re:
Hi Chris,
Sorry for the delay. I was caught up with my college assessments.
First draft of my proposal is up and open for comments. I'm going
through the Capturing Engine documentation now and the Project
description will be modified once i hear your suggestions.
Also git services are working now since i will be using a different
internet connection henceforth.
I will setup RTEMS using the latest git repo and see if the error in
the fileio tracing example is resolved and send a patch for the
missing include statement at the earliest.
Regards,
Vivek
From: Chris Johns
Sent: 16 March 2016 10:18
To: Vivek Kukreja; guteku...@gmail.com
Cc: Gedare Bloom
Subject: Re: GSoC 2016 Interested in Tracing was Re:
Hi,
I have reviewed your document but I could no actual proposal in the
Google Document https://goo.gl/8jRfyV.
I have updated the proposal template so please check it against your one.
I suggest you fill in each section answering the questions provided.
Thanks.
Chris
> On 15/03/2016 00:22, Vivek Kukreja wrote:
> Hello Chris, Isaac
>
> Sorry for the delay in adding a student proposal on
> https://devel.rtems.org/wiki/GSoC/2016. Its still in progress meanwhile i am
> looking at alternate ways of accessing git. I have not heard from Isaac
> regarding his interest in mentoring the project but I hope Chris will comment
> on the proposal once it takes shape.
>
> Also regarding an issue i posted earlier about the trace buffering example
> described on https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering,
> i was getting an error on running the rtems-tld
> command(fileio-wrapper.c:388:13: error: dereferencing pointer to incomplete
> type 'struct Thread_Control') .
> I found that there is an include statement in the online repo of
> rtld-trace-buffer.ini file thats somehow missing from my installation(at
> development/rtems/4.12/share/rtems/trace-linker)
> "#include"
> Now the tracing example successfully builds.
>
> Regards,
> Vivek
> ________
> From: Chris Johns
> Sent: 10 March 2016 08:11
> To: Vivek Kukreja
> Cc: guteku...@gmail.com; Gedare Bloom
> Subject: Re: GSoC 2016 Interested in Tracing was Re:
>
>> On 10/03/2016 06:39, Vivek Kukreja wrote:
>> Hello Chris, Isaac
>> I have run the modified hello world example and created a patch for it. I
>> cannot access your git server from my institute probably because of some
>> firewall issues. I will look into it.
>
> Please keep me posted about the git access.
>
>> Following is the output of diff command:
>> --- rtems-4.11.0-rc1master/testsuites/samples/hello/init.c 2015-12-13
>> 04:22:53.0 -0800
>> +++ rtems-4.11.0-rc1/testsuites/samples/hello/init.c 2016-03-09
>> 10:35:51.527042759 -0800
>> @@ -28,7 +28,7 @@
>> )
>> {
>> rtems_test_begin();
>> - printf( "Hello World\n" );
>> + printf( "Hello World- Modified by Vivek Kukreja 2016\n" );
>> rtems_test_end();
>> exit( 0 );
>> }
>
> The https://devel.rtems.org/wiki/GSoC/GettingStarted pages asks you to
> post to the lists your patch and then update the GSoC 2016 page at
> https://devel.rtems.org/wiki/GSoC/2016. Can you please do this? Thanks.
>
>>
>> I have gone through some recent archives of the IRC and i have some
>> questions:
>>
>> 1. RTEMS trace linker uses function wrapping to instrument linked files of
>> app to interact with capture engine(on-target) and fetching trace data. As
>> Isaac has described in this archive
>> https://www.mail-archive.com/devel@rtems.org/msg06199.html, barectf is a
>> tool used for tracing user-defined data/structs. Is it required and feasible
>> as a GSOC project to create support for this feature? As Chris said this
>> would require deciding the structure of things a bit.
>> Also, can you throw some light on 'target integration' of the capture engine
>> with rtems-tld and what tasks does it entail currently?
>
> I have updated the Open Project TraceTool wiki page. Please see have a
> look and see if that answers your questions.
>
>> 2. LTTng and barectf support CTF generation. Its required that app/kernel
>> files linked using RTEMS trace linker generate either native CTF data or
>> trace-data that can be converted to CTF. Could you share some pointers/links
>> to understand the current architecture for CTF generation in RTEMS?
>
> Currently there is no CTF support in RTEMS.
>
>> I think this feature has few prerequisites yet many features will use this.
>> For example: live trace-reading(over TCP/IP) as Isaac sugges
Re: GSoC 2016 Interested in Tracing was Re:
Sorry, I clicked on Reply by mistake instead of Reply All. Here is an offline
exchange with Chris.
---
On 10/03/2016 06:39, Vivek Kukreja wrote:
> Hello Chris, Isaac
> I have run the modified hello world example and created a patch for it. I
> cannot access your git server from my institute probably because of some
> firewall issues. I will look into it.
Please keep me posted about the git access.
> Following is the output of diff command:
> --- rtems-4.11.0-rc1master/testsuites/samples/hello/init.c 2015-12-13
> 04:22:53.0 -0800
> +++ rtems-4.11.0-rc1/testsuites/samples/hello/init.c 2016-03-09
> 10:35:51.527042759 -0800
> @@ -28,7 +28,7 @@
> )
> {
> rtems_test_begin();
> - printf( "Hello World\n" );
> + printf( "Hello World- Modified by Vivek Kukreja 2016\n" );
> rtems_test_end();
> exit( 0 );
> }
>
The https://devel.rtems.org/wiki/GSoC/GettingStarted pages asks you to
post to the lists your patch and then update the GSoC 2016 page at
https://devel.rtems.org/wiki/GSoC/2016. Can you please do this? Thanks.
>
> I have gone through some recent archives of the IRC and i have some questions:
>
> 1. RTEMS trace linker uses function wrapping to instrument linked files of
> app to interact with capture engine(on-target) and fetching trace data. As
> Isaac has described in this archive
> https://www.mail-archive.com/devel@rtems.org/msg06199.html, barectf is a tool
> used for tracing user-defined data/structs. Is it required and feasible as a
> GSOC project to create support for this feature? As Chris said this would
> require deciding the structure of things a bit.
> Also, can you throw some light on 'target integration' of the capture engine
> with rtems-tld and what tasks does it entail currently?
I have updated the Open Project TraceTool wiki page. Please see have a
look and see if that answers your questions.
> 2. LTTng and barectf support CTF generation. Its required that app/kernel
> files linked using RTEMS trace linker generate either native CTF data or
> trace-data that can be converted to CTF. Could you share some pointers/links
> to understand the current architecture for CTF generation in RTEMS?
Currently there is no CTF support in RTEMS.
> I think this feature has few prerequisites yet many features will use this.
> For example: live trace-reading(over TCP/IP) as Isaac suggested.
Live trace is a function of the back end of the Capture Engine. The
Capture Engine at it's top takes in records from generated by barectf
and buffers them and at it's back end it interfaces to transports to get
the data off the target. This architecture disconnects the transport
from the tracing and allows different transports to be used. For example
it could TCP, or UDP, JTAG, SPI, or a UART. RTEMS users have a wide
range of hardware and often debug interfaces are unique because of the
costs they can add to hardware. Consider a satellite, adding a whole
network interface, MAC and TCP/IP stack to trace during development is
silly because there is no network in space yet all the hardware would
need to be provided for and at a minimum it would take valuable board
space. The key role of the Capture Engine is to provide a simple API for
the transport layers. This work in the Capture Engine is either
partially done or needs to be done.
A key function of the Capture engine is to provide concurrent buffering.
This means low overhead buffering safe in an SMP context. This is harder
than it appears. Keeping it separate from barectf and rtems-tld is
important.
>
> I'm not sure how ambitious these projects are but given a chance i would like
> to work on native CTF generation and live trace-reading with Isaac. Providing
> support for tracing user-defined structs(like barectf) sounds interesting too
> if that feature is required before CTF.
>
These are good GSoC tasks and we welcome your interest in the work.
Chris
___
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Interested to work on Tracing Tool(GSOC)
Hi everyone I'm sorry i did not add subject to the previous mail. I am Vivek Kukreja, currently pursuing Masters from India. I'm interested in applying for GSOC this year. I am a skilled C Programmer and have strong understanding of OS concepts. I'm interested in system programming and kernel development. I am interested to work on topics under Tracing. I am intrigued by the topic. I think this will be a good place to start for me. I have gone through Getting Started documentation and setup RTEMS on my machine. I have tried running the provided examples. I tried to run the tracing example, but am facing some problem during compilation (wrapper compilation error). I will continue looking into it, and report if I can't solve the problem on my own. Please tell me about the open projects under the Tracing Tool. I request you to please give me some pointers to get started. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[no subject]
Hi everyone I am Vivek Kukreja, currently pursuing Masters from India. I'm interested in applying for GSOC this year. I am a skilled C Programmer and have strong understanding of OS concepts. I'm interested in system programming and kernel development. I am interested to work on topics under Tracing. I am intrigued by the topic. I think this will be a good place to start for me. I have gone through Getting Started documentation and setup RTEMS on my machine. I have tried running the provided examples. I tried to run the tracing example, but am facing some problem during compilation (wrapper compilation error). I will continue looking into it, and report if I can't solve the problem on my own. Please tell me about the open projects under the Tracing Tool. I request you to please give me some pointers to get started. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
