On 14 March 2018 at 18:26, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> wrote:
> I'm still getting the Covoar not found error > I'm not able to understand what am I missing, if it needs a fix, please > help me understand the code. > Have a look where all the rsb tools were built. Does covoar appear in there? The directory is something like: cd ~/development/rtems/4.12/bin > > Thanks > > On 9 March 2018 at 22:20, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> > wrote: > >> >> >> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" < >> vijaykumar9...@gmail.com> wrote: >> >> >> >> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" <joel.sherr...@gmail.com> wrote: >> >> >> >> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <cpodonne...@gmail.com> >> wrote: >> >>> >>> >>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <vijaykumar9...@gmail.com >>> > wrote: >>> >>>> Hello sir, >>>> >>>> I need some guidance to proceed to apply for #2920 as my GSoC project. >>>> >>>> I wanted to know the following points : >>>> >>>> 1. What are the prerequisites (do I have to produce something ? like >>>> the hello world ) >>>> >>> >>> Other than the hello world, there's no official prerequisites. Usually >>> the next thing is to fix a small bug, have a look at the tickets here: >>> >>> https://devel.rtems.org/query >>> >>> >>>> 2. reference materials (like specific doc), to familiarise with the >>>> rtems-tester and rsb . >>>> >>> >>> Relevant to you would be RTEMS Tester section of the main user manual. >>> The rest of the manual should be useful for setting up rtems in general. >>> >>> https://docs.rtems.org/branches/master/user/tools/tester.html >>> >> >> Running this and submitting some results for a BSP on a simulator would >> be a good step. >> This project requires doing that a lot. You can do one BSP that runs on >> a gdb based simulator >> and another on a qemu based simulator. >> >> I'll surely do that . currently I'm trying to run cillian's project , >> facing some issues with the test.py , which I'll try to fix , probably it's >> related to the path . I'll be at the other part of the country for a few >> days (4 days ), after that I'll try to submit results for a BSP on a >> simulator >> >> There is a project based on qemu that includes coverage trace ability. >> >> >>> >>> The links to the previous projects which you already found and the other >>> links I've mentioned. >>> >>> >>>> 3. how to properly plan the project into phase wise tasks and weekly >>>> sub-tasks. >>>> >>> >>> Essentially it would be: >>> 1. Get coverage analysis running again (converting the config files to >>> .ini and a couple of fixes to some of the parsing in the sections that >>> haven't been integrated, might be all that it takes). >>> 2. Then get the coverage tools integrated with RTEMS Tester. Which is >>> fix the outstanding issues that are mentioned in: >>> https://devel.rtems.org/ticket/2920 >>> Chris Johns might have things to add to this, ultimately the integration >>> to RTEMS Tester will be up to him. >>> >> >> I would add finishing getting the Couverture qemu into the RSB. >> >> Okay sir. >> >> >> Once the setup is running, there are a couple of meaty projects. >> >> Chris and I have talked about reworking the report generation in covoar. >> Currently, the C++ code writes HTML and txt files. It would be nice to >> have covoar generate something which is subsequently processed >> with a report generator. We don't have a complete solution in mind but >> writing Sphinx like the RTEMS documentation is an option. One challenge >> is that the current HTML output has filtering capability and that wouldn't >> be possible (I think) using Sphinx. >> >> The other desirable capability is to ensure the gcov output is correct and >> can be processed by the GNU gcov tool to produce reports with the same >> results as covoar. I think Cillian got a start on this but only as far as >> noting >> it wasn't always the same. We have a mentor from the GCC community >> to help with this. >> >> Once the gcov output is trustworthy, we can try other tools like lcov to >> see what other reports we can get. >> >> >> Thank you for describing the object in detail , I'll read more about >> covoar and try to understand how it generates the output and how it can be >> modified . >> >> >>> The order in which the problems are listed in that ticket are probably >>> the order in which you would complete them, the stuff about generating the >>> xml reports and gcov and all of that is probably a 2nd or 3rd phase task >>> for you depending on how it goes. The plan can change as you go along, its >>> just important that you make a plan to begin with. >>> >>> Good luck, >>> >>> Cillian. >>> >>> >>>> >>>> Thank you, >>>> Vijay k. >>>> >>>> >>>> >>>> >>>> >>>> On 1 March 2018 at 15:38, Cillian O'Donnell <cpodonne...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 1 March 2018 at 09:10, Vijay Kumar Banerjee < >>>>> vijaykumar9...@gmail.com> wrote: >>>>> >>>>>> hello, >>>>>> >>>>>> while trying to figure out the starting point, I came across this >>>>>> project form GSoC 2017 by C.P. O'Donell >>>>>> >>>>>> https://summerofcode.withgoogle.com/archive/2017/projects/49 >>>>>> 25375616385024/ >>>>>> >>>>>> Is this the project that has previous works on the project I'm >>>>>> wanting to take (#2920) ? If not , please help me find the right one. >>>>>> >>>>> >>>>> Hi Vijay, >>>>> >>>>> Yes that's the one, let me know if you have any questions about it. >>>>> When I checked last month coverage is not working with the RTEMS Tester >>>>> because the configuration files for the bsps in rtems-tools/tester/rtems >>>>> have been converted from .mc to .ini So the old .mc files I mention need >>>>> to >>>>> be converted before it will work again. >>>>> >>>>> This is what I wrote as the final documentation, it should help you >>>>> reproduce what I had working last summer. >>>>> >>>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools >>>>> >>>>> Try this branch in github for the starting point: >>>>> >>>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge >>>>> >>>>> Good luck with the project, >>>>> >>>>> Cillian. >>>>> >>>>> >>>>>> >>>>>> Also, please guide me with reading references and some small tickets >>>>>> related to the project . >>>>>> >>>>>> Thank you , >>>>>> Vijay k. >>>>>> >>>>>> >>>>>> On 26 February 2018 at 21:54, Vijay Kumar Banerjee < >>>>>> vijaykumar9...@gmail.com> wrote: >>>>>> >>>>>>> Thank you for giving me a detailed introduction to the project >>>>>>> objectives and mentors. >>>>>>> I am interested in # 2920: "Improve Coverage analysis toolkit". >>>>>>> >>>>>>> Please guide me with the resources to get started with the project >>>>>>> and get a deep understanding. >>>>>>> >>>>>>> Thank you >>>>>>> Vijay >>>>>>> >>>>>>> On 26 February 2018 at 15:36, Joel Sherrill <j...@rtems.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Feb 26, 2018 2:22 AM, "Christian Mauderer" < >>>>>>>> christian.maude...@embedded-brains.de> wrote: >>>>>>>> >>>>>>>> Am 24.02.2018 um 16:21 schrieb Vijay Kumar Banerjee: >>>>>>>> > Hello, >>>>>>>> > >>>>>>>> > As told by Joel, I sent the screenshots of my working hello world >>>>>>>> to his >>>>>>>> > personal email and have also included my name in the GSoC >>>>>>>> tracking page . >>>>>>>> > >>>>>>>> > >>>>>>>> > + Make Eclipse Target Interaction work with RTEMS >>>>>>>> > (https://www.eclipse.org/tcf/) >>>>>>>> > + Improvements to our coverage reporting. GCOV validation and >>>>>>>> covoar >>>>>>>> > reporting improvements >>>>>>>> > + wifi integration improvements >>>>>>>> > + aarch64 port >>>>>>>> > + x86_64 port / non-legacy PC BSP >>>>>>>> > - This project is large so we would need to work with whoever >>>>>>>> wants >>>>>>>> > to tackle it >>>>>>>> > to find the best subset for GSoC. >>>>>>>> > >>>>>>>> > Based on this list I went through the OpenProjects page >>>>>>>> > and came across the following Tickets ., >>>>>>>> > #2920 ,#3222,#2927 and the link to eclipse tcf . >>>>>>>> > >>>>>>>> > >>>>>>>> > out of them , I find these interesting >>>>>>>> > 1. "Improve coverage Analysis Toolset " (#2920); >>>>>>>> >>>>>>>> >>>>>>>> This area is mine. The ticket mat or may not be a great description >>>>>>>> of the goals. There are probably three things that need to be done. >>>>>>>> >>>>>>>> + Integrate ran recipes for Couverture variant of qemu. This might >>>>>>>> be a very small task. Last year's student just didn't get this >>>>>>>> integrated >>>>>>>> and was waiting for some patches to be merged on their side. >>>>>>>> >>>>>>>> + Verify the gcov output from covoar is correct and the gcov (and >>>>>>>> similar tools) matches the coverage reports it generates. We have >>>>>>>> someone >>>>>>>> from the GCC community to help mentor here. >>>>>>>> >>>>>>>> + Covoar generates HTML and text output directly. There is a desire >>>>>>>> for it to generate something equally useful that is processed by >>>>>>>> existing >>>>>>>> tools to generate reports. One possible option for this output could be >>>>>>>> Sphinx like our regular documentation. Or it could be a data-centric >>>>>>>> format >>>>>>>> processed by other tools. The current HTML allows filtering and >>>>>>>> sorting so >>>>>>>> not losing information and ease of use is important. This probably >>>>>>>> will end >>>>>>>> up simplifying C++ and adding Python. >>>>>>>> >>>>>>>> > 2. "libbsd:WiFi support needs rc.conf integration " (#3222) >>>>>>>> >>>>>>>> >>>>>>>> Christian's project to mentor. >>>>>>>> >>>>>>>> > also I came across # 3302 :" Build system conversion of BSP >>>>>>>> Config(.cfg) >>>>>>>> > files to pkg-config(.pc) files" >>>>>>>> > (I have some knowledge of Python, but not proficient in it, I can >>>>>>>> learn >>>>>>>> > it better if it's required ) >>>>>>>> > which I find interesting >>>>>>>> >>>>>>>> >>>>>>>> This one is Chris Johns project to mentor. It is an important and >>>>>>>> logically the next step in replacing our build system with the Python >>>>>>>> based >>>>>>>> waf. If you get through this one before the summer is out, then >>>>>>>> working on >>>>>>>> waf would probably make sense. >>>>>>>> >>>>>>>> Did I miss one? >>>>>>>> >>>>>>>> Hello Vijay, >>>>>>>> >>>>>>>> all of the projects would be good ones. >>>>>>>> >>>>>>>> The #2920 and #3302 are more connected to the host tools. They >>>>>>>> should be >>>>>>>> doable with few or no real hardware. But you should ask the two >>>>>>>> potential mentors about that. >>>>>>>> >>>>>>>> For the #3222 you would need some board supported by the libbsd >>>>>>>> (like >>>>>>>> Beagle Bone Black) and I would suggest a JTAG debugger (some OpenOCD >>>>>>>> based or similar). >>>>>>>> >>>>>>>> > >>>>>>>> > Am I following the right tickets? If not please help me find the >>>>>>>> right ones. >>>>>>>> >>>>>>>> The tickets are the right ones. >>>>>>>> >>>>>>>> > >>>>>>>> > Out of these , which one do you recommend me to take ? >>>>>>>> >>>>>>>> I would recommend to take a more detailed look at the tickets and >>>>>>>> start >>>>>>>> to ask some questions about it on the mailing list with CC to the >>>>>>>> (potential) mentors. >>>>>>>> >>>>>>>> Maybe you could also try to find some small tickets related to >>>>>>>> similar >>>>>>>> topics and just try to work on these. That could help you find out >>>>>>>> what >>>>>>>> you want to do. >>>>>>>> >>>>>>>> > My experience with C/C++ : I am proficient in C++11 with STL . >>>>>>>> Also >>>>>>>> > proficient in C language . >>>>>>>> > My experience with opensource : This is the first open source >>>>>>>> project >>>>>>>> > I'm taking up . >>>>>>>> >>>>>>>> It's no problem if it's your first Open Source project. That's the >>>>>>>> point >>>>>>>> of GSoC: To collect first Open Source experience. >>>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> Christian Mauderer >>>>>>>> >>>>>>>> > >>>>>>>> > Thank you , >>>>>>>> > Vijay K. >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -------------------------------------------- >>>>>>>> embedded brains GmbH >>>>>>>> Herr Christian Mauderer >>>>>>>> Dornierstr. 4 >>>>>>>> <https://maps.google.com/?q=Dornierstr.+4+%0D+D-82178+Puchheim+%0D+Germany&entry=gmail&source=g> >>>>>>>> D-82178 Puchheim >>>>>>>> Germany >>>>>>>> email: christian.maude...@embedded-brains.de >>>>>>>> Phone: +49-89-18 94 741 - 18 >>>>>>>> Fax: +49-89-18 94 741 - 08 >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> >> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
