Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 18 March 2018 at 06:47, Vijay Kumar Banerjee 
wrote:

> It worked !
>

That's great!  That's the good news then. I was using an old leon3 build
and maybe some older Qemu too and I think that's why I didn't see any
issues initially. I was hoping you could see the coverage running and the
reports generated from that but it looks like the full update to the
current master will be necessary to have a look. So until the parsing for
the INI files is added to the coverage.py we won't see the coverage
running. Unfortunately, I'm in the middle of exams until the following
Monday so I won't be able to sink any more time into it until then. You can
still figure out the RSB problem you're having and do some background
reading, brush up on your Python skills, have a read of the covoar code

https://github.com/RTEMS/rtems-tools/blob/master/tester/covoar/covoar.cc

just skim through, read the comments, get a sense of the what it's doing
and in what order.


> It's great to see it running ! I have attached the result .
>
> -- vijay
>
> On 18 March 2018 at 02:31, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 17 March 2018 at 20:08, Vijay Kumar Banerjee > > wrote:
>>
>>> yes it prints hello world
>>>
>>
>> Alright I've added an .ini for leon3-qemu to the current rtems-tools.
>> Pull this branch
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>
>> and try
>>
>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 01:31, Cillian O'Donnell 
>>> wrote:
>>>
 If you run just one test by itself without rtems-test

 qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
 leon3_generic -kernel $HOME/development/rtems/leon3/
 sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe

 Does the hello world print out?

 On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
> home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit
>> more expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" <
 cpodonne...@gmail.com> wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>> Just checked and the build was failing because one of the
>>> patches needed its hash to be updated to sha256. Just pushed that 
>>> change.
>>> The build finishes successfully on my end. Pull that change into
>>> couverture-build branch and try it again. I'm not seeing any 
>>> automake stuff
>>> here, so just check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 18 March 2018 at 06:51, Vijay Kumar Banerjee 
wrote:

> I guess I couldn't understand properly what you're suggesting ,
> on the basis of what I understood ,
> I have set the PATH like this
> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/luna
> tic/.local/bin:/home/lunatic/bin
>

I think this is about Joel's comment, it should go in the other thread for
that issue. That is what he meant so it must be something else then.

>
> I'm still getting the same error
>
>
> -- vijay
>
> On 17 March 2018 at 20:24, Joel Sherrill  wrote:
>
>> My guess on the build error is that the automake version used by RTEMS is
>> very old and may not produce output for --help that help2man can parse.
>>
>> Try building qemu from the RSB without the RTEMS tools in your PATH.
>>
>> If Couverture has been updated to a recent enough version of the upstream
>> qemu, then it is likely to fail the same way.
>>
>> --joel
>>
>> On Mar 17, 2018 9:46 AM, "Vijay Kumar Banerjee" 
>> wrote:
>>
>>> I built it manually
>>>
>>> the environment variable PATH looks like this
>>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>>> home/lunatic/.local/bin:/home/lunatic/bin
>>>
>>> I tried to run rtems-test again without --coverage , it gives the same
>>> result
>>> I have attached the log.
>>>
>>> -- vijay
>>>
>>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>>> wrote:
>>>
 Yes this is something more than my build, I'll need someone a bit more
 expert in the RSB to step in there. In the meantime, lets just build
 couverture-qemu manually so we can see is everything else working.

 git clone https://github.com/AdaCore/qemu

 cd qemu

 ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
 --disable-docs --disable-virtfs --disable-werror

 make

 make install

 then add the prefix to $PATH in .bashrc as well like before.

 export PATH=$HOME/qemu/install/bin:$PATH

 Then run rtem-test and see what happens


 On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing happens
>>
>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>> wrote:
>>
>>> If you build regular qemu with the RSB, does the same thing happen?
>>>
>>> Try
>>>
>>> ../source-builder/sb-set-builder --log=qemu_log.txt
>>> --prefix=$HOME/development/5 devel/qemu
>>>
>>>
>>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 still the same error

 -- vijay

 On 16 March 2018 at 21:39, Cillian O'Donnell >>> > wrote:

> Just checked and the build was failing because one of the patches
> needed its hash to be updated to sha256. Just pushed that change. The 
> build
> finishes successfully on my end. Pull that change into 
> couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so 
> just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/tr
>> ee/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special
>>> version of qemu designed for generating extra trace data for 
>>> coverage
>>> analysis). That's what those errors are about. I have an RSB build 
>>> for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB
>>>
>>> I know what the other problem is too. I have a specific
>>> environment variable defined for the path, sorry I can'

Re: autotools build fail from rsb

[Gedare Bloom]

On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill  wrote:
> I answered what I think the cause is on another thread.
>
> Take the ancient RTEMS autotools out of your PATH while building qemu. Use a
> PATH without RTEMS tools in it. I think the ancient automake version we use
> must have --help which help2man can't parse.
>

I don't think this is the solution, because the failure happens while
trying to build the autotools.

> On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee" 
> wrote:
>>
>> hello ,
>>
>> As suggested by Gedare , I have started this thread on the build error
>> that I'm getting .
>>
>> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while trying
>> to build autotools from rsb
>>
>> I'm using fedora 27 64bit .
>>
>> P.S: the error report is attached
>>
>> -- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

Thanks Cillian :)

It's great to see it running ,  I'll do some background reading about RSB,
and RTEMS-Tools along with the covoar code . And also work on my python
skills.

to try rtems-test on a bsp that runs gdb , I tried it on erc32 and that
also worked.

I'm also waiting for Joel and other mentors' review on my draft proposal,
so that I can also work on it and make any changes if needed.

Thanks .

-- vijay

On 18 March 2018 at 14:17, Cillian O'Donnell  wrote:

>
>
> On 18 March 2018 at 06:47, Vijay Kumar Banerjee 
> wrote:
>
>> It worked !
>>
>
> That's great!  That's the good news then. I was using an old leon3 build
> and maybe some older Qemu too and I think that's why I didn't see any
> issues initially. I was hoping you could see the coverage running and the
> reports generated from that but it looks like the full update to the
> current master will be necessary to have a look. So until the parsing for
> the INI files is added to the coverage.py we won't see the coverage
> running. Unfortunately, I'm in the middle of exams until the following
> Monday so I won't be able to sink any more time into it until then. You can
> still figure out the RSB problem you're having and do some background
> reading, brush up on your Python skills, have a read of the covoar code
>
> https://github.com/RTEMS/rtems-tools/blob/master/tester/covoar/covoar.cc
>
> just skim through, read the comments, get a sense of the what it's doing
> and in what order.
>
>
>> It's great to see it running ! I have attached the result .
>>
>> -- vijay
>>
>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes it prints hello world

>>>
>>> Alright I've added an .ini for leon3-qemu to the current rtems-tools.
>>> Pull this branch
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>>
>>> and try
>>>
>>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>

 -- vijay

 On 18 March 2018 at 01:31, Cillian O'Donnell 
 wrote:

> If you run just one test by itself without rtems-test
>
> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
> leon3_generic -kernel $HOME/development/rtems/leon3/
> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>
> Does the hello world print out?
>
> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I built it manually
>>
>> the environment variable PATH looks like this
>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>> home/lunatic/.local/bin:/home/lunatic/bin
>>
>> I tried to run rtems-test again without --coverage , it gives the
>> same result
>> I have attached the log.
>>
>> -- vijay
>>
>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>> wrote:
>>
>>> Yes this is something more than my build, I'll need someone a bit
>>> more expert in the RSB to step in there. In the meantime, lets just 
>>> build
>>> couverture-qemu manually so we can see is everything else working.
>>>
>>> git clone https://github.com/AdaCore/qemu
>>>
>>> cd qemu
>>>
>>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>>> --disable-docs --disable-virtfs --disable-werror
>>>
>>> make
>>>
>>> make install
>>>
>>> then add the prefix to $PATH in .bashrc as well like before.
>>>
>>> export PATH=$HOME/qemu/install/bin:$PATH
>>>
>>> Then run rtem-test and see what happens
>>>
>>>
>>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 the same error comes when I try to build qemu from the
 RTEMS/rtems-source-builder as well

 is the issue coming from my system ? I'm using fedora 27 64bit

 On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
 vijaykumar9...@gmail.com> wrote:

> yes , the same thing happens
>
> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" <
> cpodonne...@gmail.com> wrote:
>
>> If you build regular qemu with the RSB, does the same thing
>> happen?
>>
>> Try
>>
>> ../source-builder/sb-set-builder --log=qemu_log.txt
>> --prefix=$HOME/development/5 devel/qemu
>>
>>
>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> still the same error
>>>
>>> -- vijay
>>>
>>> On 16 March 2018 at 21:39, Cillian 

Re: x86_64 port and BSP (GSoC 2018)

[Gedare Bloom]

On Sat, Mar 17, 2018 at 2:32 PM, Joel Sherrill  wrote:
>
>
> On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom  wrote:
>>
>> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval 
>> wrote:
>> > First off, thank you so much for the prompt and detailed response! I
>> > really
>> > appreciate the help!
>> >
>> > On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom  wrote:
>> >
>> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval 
>> > wrote:
>> >> > Hey everyone!
>> >> >
>> >> > Here's a link to a draft of my proposal (also shared through the GSoC
>> >> > website, and linked to on the wiki):
>> >> >
>> >
>> > https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
>> >> >
>> >> > I'd appreciate all comments - even if you're just skimming, let me
>> >> > know
>> > if
>> >> > you have something to say!
>> >> >
>> >> > I have a few questions too, which I'd appreciate help with:
>> >> >
>> >> > Regarding the proposal:
>> >> >
>> >> > - Does it seem like I'm committing too little / too much?
>> >
>> >> I don't think you have work planned in a good way. The scope of the
>> >> second half is light, while the first half may be heavy. It is OK to
>> >> have schedule slip, but it is better if you can try to balance the
>> >> work over the phases. Also, note that GSoC is now a three-thirds
>> >> instead of two-halves timeline.
>> >
>> > Noted. I've revised it a bit (same link). Would you mind having another
>> > look?
>>
>
> I have always thought the first part of this project would be to get
> an UEFI "hello world" running on Qemu. That is the entry point to the
> BSP and as Chris pointed out, there is a fair amount of work just
> to ensure you can do prints to the optional video and later serial port.
>
> Then that can be hooked to initialize RTEMS. Implement the context
> switch code using setjmp/longjmp as guides.
>
> With the idle thread that simulates a clock tick, you can run a lot of
> the tests.
>
> Then deal with the interrupt controller and clock tick.
>
> Then add COM1.
>
> All that should be doable and testable on qemu.
>
>>
>> >> > - Are there any issues I've completely overlooked? Something I've
>> >> > oversimplified / that I may not realize the scope / difficulty of?
>> >
>> >> Getting boot to work properly may be harder than you anticipate.
>> >
>> > That's a good point. I've made the target for phase 1 about getting stub
>> > code there, boot/init code started, and patching the x86_64 tools up to
>> > have them be feature-complete. (It's hard to gauge if that's a
>> > satisfactory
>> > goal given that I'm not quite sure of the current status of the tools -
>> > this is why I'm hoping to resolve this ASAP.)
>> >
>> > Would you let me know if the deliverables seem more evenly distributed
>> > and
>> > realistic now?
>> >
>>
>> It does. I think Phase 3 remains light. I'd encourage you to flesh out
>> the plan for one of the "bonus" areas for this phase. That way, if you
>> reach it, you will be prepared to undertake it without having to think
>> too hard about the design aspects.
>>
>> >> Doing the ISR right means implementing the APIC support in a proper
>> >> way.
>> >> I think it will be a good idea for you to address SMP issues together
>> >> with the UP implementation.
>> >
>> >
>> > I agree, but I'd rather not commit to SMP support since that sounds like
>> > it
>> > might be too much - I can't know that, of course, but I think I'd rather
>> > keep it a bonus activity that I'll be able to pull in when I'm more in
>> > the
>> > swing of things and better able to gauge the effort required.
>>
>
> +1
>
>>
>> >> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be
>> >> > a
>> >> > potential mentor, or is ticket ownership not indicative of who the
>> > mentor
>> >> > might be?
>> >
>> >> Yes, Chris or Joel are likely mentors, unless another interested party
>> > pops up.
>>
> This project will likely require help from multiple mentors with Chris
> and I being the official mentor pair.
>
>>
>> > I see! Do mentors usually mentor more than one student?
>> >
>>
>> Some do.
>>
>> >> >
>> >> > Misc:
>> >> >
>> >> > - I noticed that this project has been proposed in the past, at least
>> >> > twice. Is there any constructive criticism from the proposals back
>> >> > then
>> >> > that I could learn from?
>> >
>> >> Not really. The previous proposals were weak, and this project was not
>> >> a high priority back then.
>> >
>> > Ah. Is there anything I can do to strengthen my proposal, in that case,
>> > besides the feedback you've already provided? I do already plan to
>> > tackle
>> > more tickets as time permits / get a head start on fixing / verifying
>> > the
>> > x86_64 tools up. Is there anything else I should also be doing? Any
>> > other
>> > resources I should be looking at?
>> >
>> > I just want to make sure that I know what I'm getting into and that you
>> > guys aren't making a blind bet - anything I can do to prove to you and
>> > me
>> > that I'm actually ca

Re: autotools build fail from rsb

[Vijay Kumar Banerjee]

I have set the PATH like this
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/luna
tic/.local/bin:/home/lunatic/bin

I'm still getting the same error


-- vijay

On 18 March 2018 at 16:01, Gedare Bloom  wrote:

> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill  wrote:
> > I answered what I think the cause is on another thread.
> >
> > Take the ancient RTEMS autotools out of your PATH while building qemu.
> Use a
> > PATH without RTEMS tools in it. I think the ancient automake version we
> use
> > must have --help which help2man can't parse.
> >
>
> I don't think this is the solution, because the failure happens while
> trying to build the autotools.
>
> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com>
> > wrote:
> >>
> >> hello ,
> >>
> >> As suggested by Gedare , I have started this thread on the build error
> >> that I'm getting .
> >>
> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while
> trying
> >> to build autotools from rsb
> >>
> >> I'm using fedora 27 64bit .
> >>
> >> P.S: the error report is attached
> >>
> >> -- vijay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: autotools build fail from rsb

[Gedare Bloom]

Vijay,

On Sun, Mar 18, 2018 at 6:36 AM, Vijay Kumar Banerjee
 wrote:
>
> I have set the PATH like this
> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>
> I'm still getting the same error
>
>
> -- vijay
>
> On 18 March 2018 at 16:01, Gedare Bloom  wrote:
>>
>> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill  wrote:
>> > I answered what I think the cause is on another thread.
>> >
>> > Take the ancient RTEMS autotools out of your PATH while building qemu.
>> > Use a
>> > PATH without RTEMS tools in it. I think the ancient automake version we
>> > use
>> > must have --help which help2man can't parse.
>> >
>>
>> I don't think this is the solution, because the failure happens while
>> trying to build the autotools.
>>

What happens when you run on the command line:

$> automake-1.12 --help

>> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee"
>> > 
>> > wrote:
>> >>
>> >> hello ,
>> >>
>> >> As suggested by Gedare , I have started this thread on the build error
>> >> that I'm getting .
>> >>
>> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while
>> >> trying
>> >> to build autotools from rsb
>> >>
>> >> I'm using fedora 27 64bit .
>> >>
>> >> P.S: the error report is attached
>> >>
>> >> -- vijay
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: autotools build fail from rsb

[Gedare Bloom]

On Sun, Mar 18, 2018 at 6:41 AM, Gedare Bloom  wrote:
> Vijay,
>
> On Sun, Mar 18, 2018 at 6:36 AM, Vijay Kumar Banerjee
>  wrote:
>>
>> I have set the PATH like this
>> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>>
>> I'm still getting the same error
>>
>>
>> -- vijay
>>
>> On 18 March 2018 at 16:01, Gedare Bloom  wrote:
>>>
>>> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill  wrote:
>>> > I answered what I think the cause is on another thread.
>>> >
>>> > Take the ancient RTEMS autotools out of your PATH while building qemu.
>>> > Use a
>>> > PATH without RTEMS tools in it. I think the ancient automake version we
>>> > use
>>> > must have --help which help2man can't parse.
>>> >
>>>
>>> I don't think this is the solution, because the failure happens while
>>> trying to build the autotools.
>>>
>
> What happens when you run on the command line:
>
> $> automake-1.12 --help
>

I suspect it is related to:
https://lists.gnu.org/archive/html/bug-automake/2017-06/msg3.html

The problem is how perl is handling regex escaping where a newer perl
causes an error when an older perl caused a warning. Since we are kind
of stuck with an older automake, you should install an older perl.
Apparently, something before 5.26.0 should work I guess.

-Gedare

>>> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee"
>>> > 
>>> > wrote:
>>> >>
>>> >> hello ,
>>> >>
>>> >> As suggested by Gedare , I have started this thread on the build error
>>> >> that I'm getting .
>>> >>
>>> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while
>>> >> trying
>>> >> to build autotools from rsb
>>> >>
>>> >> I'm using fedora 27 64bit .
>>> >>
>>> >> P.S: the error report is attached
>>> >>
>>> >> -- vijay
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: autotools build fail from rsb

[Vijay Kumar Banerjee]

-- vijay

On 18 March 2018 at 16:13, Gedare Bloom  wrote:

> On Sun, Mar 18, 2018 at 6:41 AM, Gedare Bloom  wrote:
> > Vijay,
> >
> > On Sun, Mar 18, 2018 at 6:36 AM, Vijay Kumar Banerjee
> >  wrote:
> >>
> >> I have set the PATH like this
> >> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/
> lunatic/.local/bin:/home/lunatic/bin
> >>
> >> I'm still getting the same error
> >>
> >>
> >> -- vijay
> >>
> >> On 18 March 2018 at 16:01, Gedare Bloom  wrote:
> >>>
> >>> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill 
> wrote:
> >>> > I answered what I think the cause is on another thread.
> >>> >
> >>> > Take the ancient RTEMS autotools out of your PATH while building
> qemu.
> >>> > Use a
> >>> > PATH without RTEMS tools in it. I think the ancient automake version
> we
> >>> > use
> >>> > must have --help which help2man can't parse.
> >>> >
> >>>
> >>> I don't think this is the solution, because the failure happens while
> >>> trying to build the autotools.
> >>>
> >
> > What happens when you run on the command line:
> >
> > $> automake-1.12 --help
> >
>
> I get the help(along with options and usage) printed on the screen .


> I suspect it is related to:
> https://lists.gnu.org/archive/html/bug-automake/2017-06/msg3.html
>
> The problem is how perl is handling regex escaping where a newer perl
> causes an error when an older perl caused a warning. Since we are kind
> of stuck with an older automake, you should install an older perl.
> Apparently, something before 5.26.0 should work I guess.
>
> -Gedare
>
> >>> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee"
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> hello ,
> >>> >>
> >>> >> As suggested by Gedare , I have started this thread on the build
> error
> >>> >> that I'm getting .
> >>> >>
> >>> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while
> >>> >> trying
> >>> >> to build autotools from rsb
> >>> >>
> >>> >> I'm using fedora 27 64bit .
> >>> >>
> >>> >> P.S: the error report is attached
> >>> >>
> >>> >> -- vijay
> >>
> >>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Error in Trace-buffering example

[Vidushi Vashishth]

Hello!

I am hoping to apply to Gsoc'18 for the runtime tracing project. I am
following the RTEMS tracing documentation [1] and have been trying to run
the fileio trace sample to familiarise with how traces are generated. I
have set the rtems-path to the installed BSP erc32 in the fileio-trace.ini.
The directory structure of my set up is the same as provided in the User
manual. However while trying to link the fileio.exe I get a few errors:

Command:

sparc-rtems5-gcc -Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems \

  -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall \

  -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes \

  -Wnested-externs -Wl,--gc-sections -mcpu=cypress \

  -o sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o

Error:
 *sparc-rtems5-gcc:* *error: *bsp_specs: No such file or director


Command:

rtems-tld -C fileio-trace.ini -W fileio-wrapper --
-Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems -mcpu=cypress -O2 -g
-ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-Wl,--gc-sections -mcpu=cypress -o
sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o

Error:

error: /development/rtems/kernel/erc32: Invalid RTEMS path

I am in quite a fix. My directory structure seems okay. Would appreciate
some insight.


References:
[1] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering

Best,
Vidushi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi all,
Here's the link to my proposal:
https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing

Please have a look, and comment where ever needed.
I tried my best to make time-line as realistic as possible. Please feel
free to comment in case of any unbalance or overlooked task.

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Christian Mauderer]

Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> Hi all,
> Here's the link to my proposal:
> https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing
> 
> Please have a look, and comment where ever needed.
> I tried my best to make time-line as realistic as possible. Please feel
> free to comment in case of any unbalance or overlooked task.
> 
> Regards,
> Udit agarwal
> 
> 

Hello Udit,

some (not too well sorted) notes:

1. One point I'm missing is the target that you produce a set of patches
that can be easily merged as soon as the libbsd receives it's next
update. Otherwise the only result from that project would be the
comparison document.


2. I'm not sure whether the point

  "Backport the SDIO driver residing within the mmccam stack to FreeBSD
version being used by libbsd"

is a good idea. It sounds like you want to do the backport on FreeBSD.
You most likely would have a lot of work with that without any really
useful results. It would be better to analyse whether some other
subsystems might have an influence on the performance measurement (which
I would expect to be quite few) and then do the backport directly on
RTEMS libbsd.


3. It seems that you have split up the test bench over all three phases.
It might would be more efficient to search a test bench and get it
running on FreeBSD as well as on RTEMS quite early. There should be no
difference whether it runs on the old SD-card driver, the SDIO one or
some USB stick. It should basically work with with any block device.

If you start to port it to RTEMS in phase 3 and then find out that it
doesn't work like expected, you will have to restart with searching some
other test bench. This would mean that you can throw away all results of
the workbench that you collected in between.


4. I'm not quite sure whether the amount of work would really fill all
three phases. Maybe you should plan an extended goal. With that topic
that could for example be a benchmark for some other drivers (like USB
storage).


5. Currently your results are a document and a set of patches that
(hopefully) can be integrated into libbsd in the future. I think that if
you find some good standard performance test for block devices, porting
that could be another core result that can be integrated directly and
not only after a libbsd upgrade.

With kind regards

Christian Mauderer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

On Mar 18, 2018 5:37 AM, "Gedare Bloom"  wrote:

On Sat, Mar 17, 2018 at 2:32 PM, Joel Sherrill  wrote:
>
>
> On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom  wrote:
>>
>> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval 
>> wrote:
>> > First off, thank you so much for the prompt and detailed response! I
>> > really
>> > appreciate the help!
>> >
>> > On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom  wrote:
>> >
>> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval 
>> > wrote:
>> >> > Hey everyone!
>> >> >
>> >> > Here's a link to a draft of my proposal (also shared through the
GSoC
>> >> > website, and linked to on the wiki):
>> >> >
>> >
>> > https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550G
DvVDS5QufvAnFE/edit?usp=sharing
>> >> >
>> >> > I'd appreciate all comments - even if you're just skimming, let me
>> >> > know
>> > if
>> >> > you have something to say!
>> >> >
>> >> > I have a few questions too, which I'd appreciate help with:
>> >> >
>> >> > Regarding the proposal:
>> >> >
>> >> > - Does it seem like I'm committing too little / too much?
>> >
>> >> I don't think you have work planned in a good way. The scope of the
>> >> second half is light, while the first half may be heavy. It is OK to
>> >> have schedule slip, but it is better if you can try to balance the
>> >> work over the phases. Also, note that GSoC is now a three-thirds
>> >> instead of two-halves timeline.
>> >
>> > Noted. I've revised it a bit (same link). Would you mind having another
>> > look?
>>
>
> I have always thought the first part of this project would be to get
> an UEFI "hello world" running on Qemu. That is the entry point to the
> BSP and as Chris pointed out, there is a fair amount of work just
> to ensure you can do prints to the optional video and later serial port.
>
> Then that can be hooked to initialize RTEMS. Implement the context
> switch code using setjmp/longjmp as guides.
>
> With the idle thread that simulates a clock tick, you can run a lot of
> the tests.
>
> Then deal with the interrupt controller and clock tick.
>
> Then add COM1.
>
> All that should be doable and testable on qemu.
>
>>
>> >> > - Are there any issues I've completely overlooked? Something I've
>> >> > oversimplified / that I may not realize the scope / difficulty of?
>> >
>> >> Getting boot to work properly may be harder than you anticipate.
>> >
>> > That's a good point. I've made the target for phase 1 about getting
stub
>> > code there, boot/init code started, and patching the x86_64 tools up to
>> > have them be feature-complete. (It's hard to gauge if that's a
>> > satisfactory
>> > goal given that I'm not quite sure of the current status of the tools -
>> > this is why I'm hoping to resolve this ASAP.)
>> >
>> > Would you let me know if the deliverables seem more evenly distributed
>> > and
>> > realistic now?
>> >
>>
>> It does. I think Phase 3 remains light. I'd encourage you to flesh out
>> the plan for one of the "bonus" areas for this phase. That way, if you
>> reach it, you will be prepared to undertake it without having to think
>> too hard about the design aspects.
>>
>> >> Doing the ISR right means implementing the APIC support in a proper
>> >> way.
>> >> I think it will be a good idea for you to address SMP issues together
>> >> with the UP implementation.
>> >
>> >
>> > I agree, but I'd rather not commit to SMP support since that sounds
like
>> > it
>> > might be too much - I can't know that, of course, but I think I'd
rather
>> > keep it a bonus activity that I'll be able to pull in when I'm more in
>> > the
>> > swing of things and better able to gauge the effort required.
>>
>
> +1
>
>>
>> >> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be
>> >> > a
>> >> > potential mentor, or is ticket ownership not indicative of who the
>> > mentor
>> >> > might be?
>> >
>> >> Yes, Chris or Joel are likely mentors, unless another interested party
>> > pops up.
>>
> This project will likely require help from multiple mentors with Chris
> and I being the official mentor pair.
>
>>
>> > I see! Do mentors usually mentor more than one student?
>> >
>>
>> Some do.
>>
>> >> >
>> >> > Misc:
>> >> >
>> >> > - I noticed that this project has been proposed in the past, at
least
>> >> > twice. Is there any constructive criticism from the proposals back
>> >> > then
>> >> > that I could learn from?
>> >
>> >> Not really. The previous proposals were weak, and this project was not
>> >> a high priority back then.
>> >
>> > Ah. Is there anything I can do to strengthen my proposal, in that case,
>> > besides the feedback you've already provided? I do already plan to
>> > tackle
>> > more tickets as time permits / get a head start on fixing / verifying
>> > the
>> > x86_64 tools up. Is there anything else I should also be doing? Any
>> > other
>> > resources I should be looking at?
>> >
>> > I just want to make sure that I know what I'm getting into and that you
>> > guys aren't making a blind bet - anything I can do to 

Re: autotools build fail from rsb

[Vijay Kumar Banerjee]

I have tried
perl-5.24.3
perl-5.22.4
perl-5.20.3

still getting the same error, it be coming from something else

-- vijay

On 18 March 2018 at 16:15, Vijay Kumar Banerjee 
wrote:

>
>
> -- vijay
>
> On 18 March 2018 at 16:13, Gedare Bloom  wrote:
>
>> On Sun, Mar 18, 2018 at 6:41 AM, Gedare Bloom  wrote:
>> > Vijay,
>> >
>> > On Sun, Mar 18, 2018 at 6:36 AM, Vijay Kumar Banerjee
>> >  wrote:
>> >>
>> >> I have set the PATH like this
>> >> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/luna
>> tic/.local/bin:/home/lunatic/bin
>> >>
>> >> I'm still getting the same error
>> >>
>> >>
>> >> -- vijay
>> >>
>> >> On 18 March 2018 at 16:01, Gedare Bloom  wrote:
>> >>>
>> >>> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill 
>> wrote:
>> >>> > I answered what I think the cause is on another thread.
>> >>> >
>> >>> > Take the ancient RTEMS autotools out of your PATH while building
>> qemu.
>> >>> > Use a
>> >>> > PATH without RTEMS tools in it. I think the ancient automake
>> version we
>> >>> > use
>> >>> > must have --help which help2man can't parse.
>> >>> >
>> >>>
>> >>> I don't think this is the solution, because the failure happens while
>> >>> trying to build the autotools.
>> >>>
>> >
>> > What happens when you run on the command line:
>> >
>> > $> automake-1.12 --help
>> >
>>
>> I get the help(along with options and usage) printed on the screen .
>
>
>> I suspect it is related to:
>> https://lists.gnu.org/archive/html/bug-automake/2017-06/msg3.html
>>
>> The problem is how perl is handling regex escaping where a newer perl
>> causes an error when an older perl caused a warning. Since we are kind
>> of stuck with an older automake, you should install an older perl.
>> Apparently, something before 5.26.0 should work I guess.
>>
>> -Gedare
>>
>> >>> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee"
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> hello ,
>> >>> >>
>> >>> >> As suggested by Gedare , I have started this thread on the build
>> error
>> >>> >> that I'm getting .
>> >>> >>
>> >>> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error
>> while
>> >>> >> trying
>> >>> >> to build autotools from rsb
>> >>> >>
>> >>> >> I'm using fedora 27 64bit .
>> >>> >>
>> >>> >> P.S: the error report is attached
>> >>> >>
>> >>> >> -- vijay
>> >>
>> >>
>>
>
>
RTEMS Tools Project - Source Builder Error Report
 Build: error: building automake-1.12.6-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder 
--prefix=/home/lunatic/development/rtems/5 devel/autotools
 Python: 2.7.14 (default, Feb 27 2018, 20:43:24) [GCC 7.3.1 20180130 (Red Hat 
7.3.1-2)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Linux lunatic 4.15.8-300.fc27.x86_64 #1 SMP Fri Mar 9 18:11:36 UTC 2018 x86_64
Tail of the build log:
-rwxr-xr-x 1000/1000  1033 2012-12-14 22:28 automake-1.12.6/t/canon2.sh
-rwxr-xr-x 1000/1000   958 2012-12-14 22:28 automake-1.12.6/t/upc2.sh
-rwxr-xr-x 1000/1000  2043 2012-12-14 22:28 automake-1.12.6/t/exeext4.sh
-rwxr-xr-x 1000/1000  1632 2012-12-14 22:28 
automake-1.12.6/t/doc-parsing-buglets-tabs.sh
-rwxr-xr-x 1000/1000  1377 2012-12-14 22:28 automake-1.12.6/t/gettext3.sh
-rwxr-xr-x 1000/1000  1684 2012-12-14 22:28 
automake-1.12.6/t/distcheck-configure-flags.sh
-rwxr-xr-x 1000/1000  1058 2012-12-14 22:28 automake-1.12.6/t/subobj2.sh
-rwxr-xr-x 1000/1000  1905 2012-12-14 22:28 automake-1.12.6/t/silent.sh
-rwxr-xr-x 1000/1000  2223 2012-12-14 22:28 automake-1.12.6/t/yacc-subdir.sh
-rwxr-xr-x 1000/1000  3406 2012-12-14 22:28 
automake-1.12.6/t/dist-auxdir-many-subdirs.sh
-r-xr-xr-x 1000/1000   448 2012-12-15 15:04 automake-1.12.6/t/compile3-w.sh
-rwxr-xr-x 1000/1000  2013 2012-12-14 22:28 
automake-1.12.6/t/aclocal-install-mkdir.sh
-rwxr-xr-x 1000/1000   966 2012-12-14 22:28 automake-1.12.6/t/order.sh
-rwxr-xr-x 1000/1000  1946 2012-12-14 22:28 
automake-1.12.6/t/remake-maintainer-mode.sh
-rwxr-xr-x 1000/1000  2152 2012-12-14 22:28 automake-1.12.6/t/silent7.sh
-rwxr-xr-x 1000/1000  2233 2012-12-14 22:28 
automake-1.12.6/t/instdir-prog.sh
-rwxr-xr-x 1000/1000  1234 2012-12-14 22:28 automake-1.12.6/t/man7.sh
-rwxr-xr-x 1000/1000  1001 2012-12-14 22:28 
automake-1.12.6/t/subdir-cond-err.sh
-rwxr-xr-x 1000/1000  2973 2012-12-14 22:28 automake-1.12.6/t/cxx-lt-demo.sh
-rwxr-xr-x 1000/1000   989 2012-12-14 22:28 automake-1.12.6/t/extra5.sh
-r-xr-xr-x 1000/1000   443 2012-12-15 15:04 automake-1.12.6/t/tap-more-w.sh
-rwxr-xr-x 1000/1000  3150 2012-12-14 01:27 
automake-1.12.6/t/testsuite-summary-count.sh
-rwxr-xr-x 1000/1000  1509 2012-12-14 22:28 
automake-1.12.6/t/aclocal-path.sh
-rwxr-xr-x 1000/1000  1043 2012-12-14 22:28 automake-1.12.6/t/version6.sh
-rwxr-xr-x 1000/1000  2050 2012-12-14 22:28 
automake-1.12.6/t/distcheck-configure-flags-am.sh
-rwxr-xr-x 1000/1000  1577 2012-12-14 22:28 
automake-1.12.6/t/tests-environment-backcompat.sh
-rwxr-

Re: autotools build fail from rsb

[Joel Sherrill]

On Mar 18, 2018 11:23 AM, "Vijay Kumar Banerjee" 
wrote:

I have tried
perl-5.24.3
perl-5.22.4
perl-5.20.3

still getting the same error, it be coming from something else


By any chance can this be worked around by disabling documentation for what
is being built?


-- vijay

On 18 March 2018 at 16:15, Vijay Kumar Banerjee 
wrote:

>
>
> -- vijay
>
> On 18 March 2018 at 16:13, Gedare Bloom  wrote:
>
>> On Sun, Mar 18, 2018 at 6:41 AM, Gedare Bloom  wrote:
>> > Vijay,
>> >
>> > On Sun, Mar 18, 2018 at 6:36 AM, Vijay Kumar Banerjee
>> >  wrote:
>> >>
>> >> I have set the PATH like this
>> >> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/luna
>> tic/.local/bin:/home/lunatic/bin
>> >>
>> >> I'm still getting the same error
>> >>
>> >>
>> >> -- vijay
>> >>
>> >> On 18 March 2018 at 16:01, Gedare Bloom  wrote:
>> >>>
>> >>> On Sat, Mar 17, 2018 at 12:37 PM, Joel Sherrill 
>> wrote:
>> >>> > I answered what I think the cause is on another thread.
>> >>> >
>> >>> > Take the ancient RTEMS autotools out of your PATH while building
>> qemu.
>> >>> > Use a
>> >>> > PATH without RTEMS tools in it. I think the ancient automake
>> version we
>> >>> > use
>> >>> > must have --help which help2man can't parse.
>> >>> >
>> >>>
>> >>> I don't think this is the solution, because the failure happens while
>> >>> trying to build the autotools.
>> >>>
>> >
>> > What happens when you run on the command line:
>> >
>> > $> automake-1.12 --help
>> >
>>
>> I get the help(along with options and usage) printed on the screen .
>
>
>> I suspect it is related to:
>> https://lists.gnu.org/archive/html/bug-automake/2017-06/msg3.html
>>
>> The problem is how perl is handling regex escaping where a newer perl
>> causes an error when an older perl caused a warning. Since we are kind
>> of stuck with an older automake, you should install an older perl.
>> Apparently, something before 5.26.0 should work I guess.
>>
>> -Gedare
>>
>> >>> > On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee"
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> hello ,
>> >>> >>
>> >>> >> As suggested by Gedare , I have started this thread on the build
>> error
>> >>> >> that I'm getting .
>> >>> >>
>> >>> >> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error
>> while
>> >>> >> trying
>> >>> >> to build autotools from rsb
>> >>> >>
>> >>> >> I'm using fedora 27 64bit .
>> >>> >>
>> >>> >> P.S: the error report is attached
>> >>> >>
>> >>> >> -- vijay
>> >>
>> >>
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error in Trace-buffering example

[Joel Sherrill]

On Mar 18, 2018 6:48 AM, "Vidushi Vashishth"  wrote:

Hello!

I am hoping to apply to Gsoc'18 for the runtime tracing project. I am
following the RTEMS tracing documentation [1] and have been trying to run
the fileio trace sample to familiarise with how traces are generated. I
have set the rtems-path to the installed BSP erc32 in the fileio-trace.ini.
The directory structure of my set up is the same as provided in the User
manual. However while trying to link the fileio.exe I get a few errors:

Command:

sparc-rtems5-gcc -Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems \

  -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall \

  -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes \

  -Wnested-externs -Wl,--gc-sections -mcpu=cypress \

  -o sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o


The -B option should have a full path not a partial one. The $prefix used
when building the BSP is missing.

Did you use a full path? Is there an argument missing to the invocation?




Error:
 *sparc-rtems5-gcc:* *error: *bsp_specs: No such file or director


Command:

rtems-tld -C fileio-trace.ini -W fileio-wrapper --
-Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems -mcpu=cypress -O2 -g
-ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-Wl,--gc-sections -mcpu=cypress -o sparc-rtems5/c/erc32/
testsuites/samples/fileio/fileio.exe sparc-rtems5/c/erc32/
testsuites/samples/fileio/init.o

Error:

error: /development/rtems/kernel/erc32: Invalid RTEMS path

I am in quite a fix. My directory structure seems okay. Would appreciate
some insight.


References:
[1] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering

Best,
Vidushi

___
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: RTEMS monitor commands and the shell

[Chris Johns]

Thomas, Paul and Sebastian, thank you for the feedback.

It seems like it would be nice to have this command controlled somehow and it is
something that should be fixed. I will take a look and see what I can do and
will report back with any issues or a patch.

Again thanks
Chris

On 16/03/2018 18:43, Paul Whitfield wrote:
> We have hit this problem with rtems 4.10.
> I think the monitor commands should be treated the same as the other shell 
> commands. 
> It should be possible to disable via shellconfig.h - by default all are 
> enabled, but that can be disabled. 
> 
> In our application, the monitor 'exit' command was particularly problematic 
> because customers connect to the monitor via telnet then type exit to end the 
> telnet session. 
> The exit command would trigger a fatal error exception, resulting in several 
> bug reports that were 'device restarted for no reason'. :-(
> 
> 
> 
> Regards
> Paul Whitfield
> 
> 
> 
> 
> 
> Paul Whitfield
> 
> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns
> Sent: Friday, 16 March 2018 3:01 PM
> To: Development
> Subject: RTEMS monitor commands and the shell
> 
> Hi,
> 
> The monitor commands are registered automatically in 
> `rtems_shell_init_once()` which means an application has no control over 
> these being present, the command mix and naming, for example there is a 
> `config` command in the monitor.
> 
> I am not sure what to do, if it is removed some applications may break 
> assuming these commands are present. A way to disable the command using 
> shellconfig.h would be nice.
> 
> Suggestions?
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> Scanned by Moncrieff Technology Solutions Secure Mail Appliance
> 
> Scanned by Moncrieff Technology Solutions Secure Mail Appliance
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: autotools build fail from rsb

[Chris Johns]

On 19/03/2018 03:23, Vijay Kumar Banerjee wrote:
> I have tried 
> perl-5.24.3

On FreeBSD I have:

ruru rtems $ type perl
perl is a tracked alias for /usr/local/bin/perl
ruru rtems $ perl --version

This is perl 5, version 24, subversion 3 (v5.24.3) built for
amd64-freebsd-thread-multi

I do not have `help2man` on my host:

ruru rtems $ type help2man
help2man: not found

> perl-5.22.4
> perl-5.20.3
> 
> still getting the same error, it be coming from something else 
> 

Yes it would seem likely.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Error in Trace-buffering example

[Chris Johns]

On 19/03/2018 03:44, Joel Sherrill wrote:
> On Mar 18, 2018 6:48 AM, "Vidushi Vashishth"  > wrote:
> 
> Hello!
> 
> I am hoping to apply to Gsoc'18 for the runtime tracing project. I am
> following the RTEMS tracing documentation [1] and have been trying to run
> the fileio trace sample to familiarise with how traces are generated. I 
> have
> set the rtems-path to the installed BSP erc32 in the fileio-trace.ini. The
> directory structure of my set up is the same as provided in the User 
> manual.
> However while trying to link the fileio.exe I get a few errors:
> 
> Command: 
> 
> sparc-rtems5-gcc -Bsparc-rtems5/erc32/lib/ -specs bsp_specs -qrtems \
> 
>           -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall \
> 
>           -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes \
> 
>           -Wnested-externs -Wl,--gc-sections -mcpu=cypress \
> 
>           -o sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
> sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o
> 
> 
> The -B option should have a full path not a partial one. The $prefix used when
> building the BSP is missing.
> 
> Did you use a full path? Is there an argument missing to the invocation?
> 

The link provided to our wiki does not have the full path. I am not sure why ...

> References:
> [1] https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
> 

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel