Re: RISC-V tool chain

[Sebastian Huber]

On 05/06/18 16:07, Gedare Bloom wrote:

On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
 wrote:

Hello,

the RISC-V is a new architecture and the tool chain is still under active
development. For example one bug which blocks the RTEMS support of the
64-bit RISC-V was fixed this week:

https://sourceware.org/bugzilla/show_bug.cgi?id=23244

The GDB support is only available in the development branch of GDB. This
makes it a bit difficult to use release versions of the tools. We used
snapshots in the past, but the snapshots are removed from the FSF download
sites and mirrors after some time (e.g. half a year). This is not good if
you want to bisect a bug and need to build the tool chain used for a certain
RTEMS version.

What do you think about adding snapshots used by RSB to the RTEMS FTP
server?


Hello Sebastian,

I believe this has been discussed before although I can't find the
thread. I have concerns about the maintenance of snapshots. How many
target toolchains will we do this for, what frequency will snapshots
be taken, and how long will we preserve them?


Yes, sorry. Each time I face the snapshot problem I first think about 
adding it to the RTEMS FTP server.




Is there a different low-cost technical solution that can be used
instead of a snapshot? For example, we can check-out a specific commit
from a repository: wouldn't it work well enough to identify such
commits and update them periodically instead of taking a full snapshot
of the tool sources? I believe this is how we have dealt with qemu in
the RSB, by picking one commit and sticking with it for awhile.


The Git checkouts have the problem that you need an internet connection 
during the build (as far as I remember). I tried to use a snapshot 
download via the Git web access, e.g.


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=snapshot;h=773ff7907c05313aebbcd5e8319e5b869ac4f792;sf=tgz

This resulted in a "403 - Snapshots not allowed".

We could use an unofficial mirror on Github, e.g.

https://codeload.github.com/bminor/binutils-gdb/tar.gz/c61b06a19a34baab66e3809c7b41b0c31009ed9f

My main concern with using all these different download sources is that 
this will likely not work if we want to use it in five or ten years due 
to URL changes.


--
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: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Joel Sherrill]

On Tue, Jun 5, 2018, 10:21 PM Chris Johns  wrote:

> On 1/6/18 9:13 am, Joel Sherrill wrote:
> > Just chatted with Chris. The coverage BSP ini file was a temporary
> > measure as I thought.
>
> I may have not understood the specific issue being discussed when we
> talked.
>
> I separated the INI files because this is what we do else where (see the
> leon3
> example below). I consider options as a way to vary the default behavior
> so the
> less we have the better. A default run without extra options is preferred.
>
> You cannot add --coverage to all supported BSPs and get coverage and for
> this
> option to be useful this is what the option should do. To control coverage
> you
> need to know it can be supported so the question becomes simple, if you
> can do
> coverage why would you decide not too? In other words 'leon3-qemu-cov'
> should
> not need a --coverage option unless you wish to change the sets used and
> that is
> varying the default behavior.
>
> For example you can run leon3 with:
>
>  leon3
>  leon3-qemu-cov
>  leon3-qemu
>  leon3-run
>  leon3-sis
>  leon3_tsim
>  leon3_tsim-run
>  leon3-tsim-cmds
>
> and we do not have options to manage any of these differences line 'tsim'
> so why
> is coverage being treated as something special? To me it is not.
>
> The separation was on purpose and for this reason and not temporary. The
> changes
> needed to have this happen may require some refactoring, I am not sure yet.
>

Good enough. Think on it.

>
> > Make a list of all the ideas we have had for improvements. We want
> > the code to get onto master.
> >
> > The list should be converted to Trac tickets very soon. Then we can
> > decide which are critical for GSoC, which Chris or I will work on, and
> > which are part of your GSoC.
>
> Have these tickets been created?
>

Don't think so

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

Re: [PATCH] Generate coverage analysis Report

[Joel Sherrill]

On Tue, Jun 5, 2018, 11:07 PM Vijay Kumar Banerjee 
wrote:

> On Wed, 6 Jun 2018, 08:31 Joel Sherrill,  wrote:
>
>>
>>
>> On Tue, Jun 5, 2018, 9:54 PM Chris Johns  wrote:
>>
>>>
>>> On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
>>> > On 31 May 2018 at 02:02, Joel Sherrill >> j...@rtems.org>>
>>> > wrote:
>>> > On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
>>> > mailto:vijaykumar9...@gmail.com>>
>>> wrote:
>>> >
>>> > On 31 May 2018 at 00:28, Joel Sherrill >> > > wrote:
>>> > I may not understand correctly but there is test_run and
>>> > coverage_run. Someone
>>> > suggested making coverage_running an option to test_run.
>>> If that's
>>> > what's being
>>> > asked for, then I think doing it in a follow up patch is
>>> OK.
>>> >
>>> > If that's the intended request, perhaps a ticket should be
>>> filed.
>>> >
>>> >
>>> > Sorry for all the confusion.
>>> > This patch doesn't change the way test works. It only adds an
>>> option to run
>>> > the coverage script. coverage_run just runs the
>>> coverage.coverage_run
>>> >
>>> >
>>> > :) And I am saying if we want to have one test_run with an
>>> argument, do it as
>>> > a future work iteration. File a ticket.
>>> >
>>> > We need to get the code working on the master.
>>> >
>>> > Okay, we can keep that as a future work (I haven't thought about it
>>> though). :)
>>> > Getting it to work on master is our primary objective.
>>> >
>>>
>>> Was a ticket raised to removing 'coverage_run' and to use 'test_run'?
>>>
>>
>> I haven't seen tickets for any of the issues we identified.
>>
> was there supposed to be tickets for each issue?
>

Yes. If they still apply.


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

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On Wed, 6 Jun 2018, 08:31 Joel Sherrill,  wrote:

>
>
> On Tue, Jun 5, 2018, 9:54 PM Chris Johns  wrote:
>
>>
>> On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
>> > On 31 May 2018 at 02:02, Joel Sherrill > j...@rtems.org>>
>> > wrote:
>> > On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
>> > mailto:vijaykumar9...@gmail.com>> wrote:
>> >
>> > On 31 May 2018 at 00:28, Joel Sherrill > > > wrote:
>> > I may not understand correctly but there is test_run and
>> > coverage_run. Someone
>> > suggested making coverage_running an option to test_run. If
>> that's
>> > what's being
>> > asked for, then I think doing it in a follow up patch is OK.
>> >
>> > If that's the intended request, perhaps a ticket should be
>> filed.
>> >
>> >
>> > Sorry for all the confusion.
>> > This patch doesn't change the way test works. It only adds an
>> option to run
>> > the coverage script. coverage_run just runs the
>> coverage.coverage_run
>> >
>> >
>> > :) And I am saying if we want to have one test_run with an
>> argument, do it as
>> > a future work iteration. File a ticket.
>> >
>> > We need to get the code working on the master.
>> >
>> > Okay, we can keep that as a future work (I haven't thought about it
>> though). :)
>> > Getting it to work on master is our primary objective.
>> >
>>
>> Was a ticket raised to removing 'coverage_run' and to use 'test_run'?
>>
>
> I haven't seen tickets for any of the issues we identified.
>
was there supposed to be tickets for each issue?

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

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Chris Johns]

On 1/6/18 9:13 am, Joel Sherrill wrote:
> Just chatted with Chris. The coverage BSP ini file was a temporary
> measure as I thought. 

I may have not understood the specific issue being discussed when we talked.

I separated the INI files because this is what we do else where (see the leon3
example below). I consider options as a way to vary the default behavior so the
less we have the better. A default run without extra options is preferred.

You cannot add --coverage to all supported BSPs and get coverage and for this
option to be useful this is what the option should do. To control coverage you
need to know it can be supported so the question becomes simple, if you can do
coverage why would you decide not too? In other words 'leon3-qemu-cov' should
not need a --coverage option unless you wish to change the sets used and that is
varying the default behavior.

For example you can run leon3 with:

 leon3
 leon3-qemu-cov
 leon3-qemu
 leon3-run
 leon3-sis
 leon3_tsim
 leon3_tsim-run
 leon3-tsim-cmds

and we do not have options to manage any of these differences line 'tsim' so why
is coverage being treated as something special? To me it is not.

The separation was on purpose and for this reason and not temporary. The changes
needed to have this happen may require some refactoring, I am not sure yet.

> Make a list of all the ideas we have had for improvements. We want
> the code to get onto master.  
> 
> The list should be converted to Trac tickets very soon. Then we can
> decide which are critical for GSoC, which Chris or I will work on, and
> which are part of your GSoC.

Have these tickets been created?

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

Re: [PATCH] Generate coverage analysis Report

[Joel Sherrill]

On Tue, Jun 5, 2018, 9:54 PM Chris Johns  wrote:

>
> On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
> > On 31 May 2018 at 02:02, Joel Sherrill  j...@rtems.org>>
> > wrote:
> > On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>> wrote:
> >
> > On 31 May 2018 at 00:28, Joel Sherrill  > > wrote:
> > I may not understand correctly but there is test_run and
> > coverage_run. Someone
> > suggested making coverage_running an option to test_run. If
> that's
> > what's being
> > asked for, then I think doing it in a follow up patch is OK.
> >
> > If that's the intended request, perhaps a ticket should be
> filed.
> >
> >
> > Sorry for all the confusion.
> > This patch doesn't change the way test works. It only adds an
> option to run
> > the coverage script. coverage_run just runs the
> coverage.coverage_run
> >
> >
> > :) And I am saying if we want to have one test_run with an argument,
> do it as
> > a future work iteration. File a ticket.
> >
> > We need to get the code working on the master.
> >
> > Okay, we can keep that as a future work (I haven't thought about it
> though). :)
> > Getting it to work on master is our primary objective.
> >
>
> Was a ticket raised to removing 'coverage_run' and to use 'test_run'?
>

I haven't seen tickets for any of the issues we identified.

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

Re: [PATCH] Generate coverage analysis Report

[Chris Johns]

On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
> On 31 May 2018 at 02:02, Joel Sherrill  >
> wrote:
> On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> On 31 May 2018 at 00:28, Joel Sherrill  > wrote:
> I may not understand correctly but there is test_run and
> coverage_run. Someone
> suggested making coverage_running an option to test_run. If that's
> what's being
> asked for, then I think doing it in a follow up patch is OK.
> 
> If that's the intended request, perhaps a ticket should be filed.
>  
> 
> Sorry for all the confusion.
> This patch doesn't change the way test works. It only adds an option 
> to run 
> the coverage script. coverage_run just runs the coverage.coverage_run
> 
> 
> :) And I am saying if we want to have one test_run with an argument, do 
> it as
> a future work iteration. File a ticket. 
> 
> We need to get the code working on the master.
> 
> Okay, we can keep that as a future work (I haven't thought about it though). 
> :)
> Getting it to work on master is our primary objective. 
> 

Was a ticket raised to removing 'coverage_run' and to use 'test_run'?

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

Re: (release notes generator) Do we need to worry about attachment?

[Chris Johns]

Hi,

For the record this topic was resolved in our meeting.

Attachments will not be inlined in the release notes and a link where possible
will be provided. Expansion of links to inline them is problematic because of
dependencies, size and varying formats, for example how do you place a
compressed tar file in release notes.

Chris

On 31/5/18 6:17 am, Joel Sherrill wrote:
> 
> 
> On Wed, May 30, 2018 at 9:00 AM, Gedare Bloom  > wrote:
> 
> On Tue, May 29, 2018 at 5:14 PM, Chris Johns  > wrote:
> > On 30/5/18 5:30 am, Dannie Huang wrote:
> >> I am now able to grab most of needed information from ticket's page by 
> using
> >> python (like ticket id, description, comments, etc).
> >
> > Fantastic.
> >
> >> There is a place for
> >> attachment on a ticket's page, do we also need to get the information 
> of
> >> attached files? If we need to, how can I implement?
> >
> > I suggest we include a link a reader of the Release Notes can click on. 
> I
> > suppose this means recording a link when parsing the data from the feed.
> >
> 
> Usually, the attachment is a patch. If the ticket is closed, it should
> mean there is a commit available correspondingly. I'm not sure what
> use the attachment would be in release notes. Making it a link
> shouldn't hurt anything though, I suppose.
> 
> 
> Putting on my user hat, I wouldn't want a patch itself in the release notes.
> A link would be more useful.
> 
> I am thinking there are at least four URL patterns. 
> 
> A URL included in the text like a link to the Open Group.
> One is a git hash that's a clickable link 
> Another is {{...}} with some git stuff in it. 
> And links to attachments.
> 
> Are there other places URLs show up?
> 
> --joel
>  
> 
> 
> > 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
> 
> 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Chris Johns]

On 4/6/18 7:49 pm, Amaan Cheval wrote:
> Please let me know if that approach doesn't make sense - given that
> there is no dynamic loader in the RTEMS kernel as far as I know,

There is a dynamic loader in RTEMS called libdl. It is not based around the ELF
standard loader used for shared libraries and will not be. GOT and PLT do not
add value to RTEMS because we do not have an active virtual address space with
paging.

The libdl code is currently supported with the i386 static builds. I would hope
this would continue to be supported without major refactoring of that code.
There are tests in the testsuite under libtests.

> what
> we really want _is_ a static file, but for it to be a relocatable PE,
> we need to convince GCC to spit out a relocatable but fully resolved
> shared library.

It is not clear to me yet making the kernel relocatable is free of other
possible issues. I will need to find time to review all the low level parts here
and my time is currently limited.

Does this UEFI work effect the score context switcher, interrupts, etc? If is
does we will need to resolve what happens and if not should we consider leaving
it if we can? For example can iPXE chain load a multiboot image?

Sorry to have disappeared for a period at a critical time in this discussion, it
was beyond my control.

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

Re: configure/make with multiple jobs error?

[Chris Johns]

On 31/5/18 2:56 am, Gedare Bloom wrote:
> On Wed, May 30, 2018 at 12:15 PM, Gedare Bloom  wrote:
>> On Wed, May 30, 2018 at 12:10 PM, Gedare Bloom  wrote:
>>> Hello all,
>>>
>>> I got a strange error just now with a fresh toolchain and current master.
>>>
>>> I did:
>>> $ ../../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=erc32
>>> --enable-tests
>>> This was OK.
>>>
>>> $ make -j4
>>> This errored out with:
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking whether to enable maintainer-specific portions of Makefiles... no
>>> checking for RTEMS_BSP... erc32
>>> checking for perl... /usr/bin/perl
>>> configure: error: Invalid BSP
>>> configure: error:
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
>>> for lib/libbsp/sparc
>>> Makefile:731: recipe for target 'erc32' failed
>>> make[2]: *** [erc32] Error 1
>>> make[2]: Leaving directory '/media/gedare/Seagate Expansion
>>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
>>> Makefile:289: recipe for target 'all-recursive' failed
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory '/media/gedare/Seagate Expansion
>>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
>>> Makefile:414: recipe for target 'all-recursive' failed
>>> make: *** [all-recursive] Error 1
>>>
> 
> This error about Invalid BSP still occurs for me with a cleaned local
> repo where I removed all the old files/directories. Maybe I missed a
> change in developer workflow, but I think I am tripped a concurrency
> bug in configure script still, because 'make' proceeds
> 
>>> $ make
>>> This works.
>>>
>>
>> Actually, this did not work all the way, it broke later. I think I
>> have leftover files/directories in my libbsp (I haven't built since
>> the cleanup/move was done) that could be causing me problems. I'll
>> report back in a bit after I clean this stuff out.
>>
> 
> But I still get an error eventually here, too:

Is this still only with a concurrent build?

> make[4]: Entering directory '/media/gedare/Seagate Expansion
> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp'

I wonder if some of the internal shell script processing we have is safe with a
space in a path?

What type of bus is this drive connected too?

Is this a VM or native on a host?

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

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On Wed, 6 Jun 2018, 06:22 Joel Sherrill,  wrote:

>
>
> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>>
>>> I think everything is pushed. Is there any patch outstanding?
>>>
>>
>>> Thank you.
>> No outstanding patch, everything on my side is squashed into it. :)
>>
>
> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>
Yes, finally!

>
> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Add support in tester to run covoar and generate an html report to
 display
 the summary of the coverage reports generated from covoar.

 Co-authored-by : Cillian O'Donnell 
 ---
  .gitignore|   1 +
  tester/rt/coverage.py | 385
 ++
  tester/rt/test.py |  34 ++-
  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
  tester/rtems/testing/qemu.cfg |   4 +-
  6 files changed, 450 insertions(+), 13 deletions(-)
  create mode 100644 tester/rt/coverage.py
  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini

 diff --git a/.gitignore b/.gitignore
 index 6ab3709..93cb5d2 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -9,3 +9,4 @@ waf3-*
  .lock-waf*
  build
  VERSION*
 +*symbols.ini
 diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
 new file mode 100644
 index 000..54933d5
 --- /dev/null
 +++ b/tester/rt/coverage.py
 @@ -0,0 +1,385 @@
 +#
 +# RTEMS Tools Project (http://www.rtems.org/)
 +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
 +# All rights reserved.
 +#
 +# This file is part of the RTEMS Tools package in 'rtems-tools'.
 +#
 +# Redistribution and use in source and binary forms, with or without
 +# modification, are permitted provided that the following conditions
 are met:
 +#
 +# 1. Redistributions of source code must retain the above copyright
 notice,
 +# this list of conditions and the following disclaimer.
 +#
 +# 2. Redistributions in binary form must reproduce the above copyright
 notice,
 +# this list of conditions and the following disclaimer in the
 documentation
 +# and/or other materials provided with the distribution.
 +#
 +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 'AS IS'
 +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 TO, THE
 +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 PURPOSE
 +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
 CONTRIBUTORS BE
 +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
 BUSINESS
 +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
 IN
 +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 OTHERWISE)
 +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 OF THE
 +# POSSIBILITY OF SUCH DAMAGE.
 +#
 +
 +from rtemstoolkit import error
 +from rtemstoolkit import path
 +from rtemstoolkit import log
 +from rtemstoolkit import execute
 +from rtemstoolkit import macros
 +
 +from datetime import datetime
 +
 +from . import options
 +
 +import shutil
 +import os
 +
 +try:
 +import configparser
 +except:
 +import ConfigParser as configparser
 +
 +class summary:
 +def __init__(self, p_summary_dir):
 +self.summary_file_path = path.join(p_summary_dir,
 'summary.txt')
 +self.index_file_path = path.join(p_summary_dir, 'index.html')
 +self.bytes_analyzed = 0
 +self.bytes_not_executed = 0
 +self.percentage_executed = 0.0
 +self.percentage_not_executed = 100.0
 +self.ranges_uncovered = 0
 +self.branches_uncovered = 0
 +self.branches_total = 0
 +self.branches_always_taken = 0
 +self.branches_never_taken = 0
 +self.percentage_branches_covered = 0.0
 +self.is_failure = False
 +
 +def parse(self):
 +if(not path.exists(self.summary_file_path)):
 +log.notice('summary file %s does not exist!' %
 (self.summary_file_path))
 +self.is_failure = True
 +return
 +
 +with open(self.summary_file_path,'r') as summary_file:
 +   self.bytes_analyzed =
 

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Joel Sherrill]

On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee 
wrote:

> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>
>> I think everything is pushed. Is there any patch outstanding?
>>
>
>> Thank you.
> No outstanding patch, everything on my side is squashed into it. :)
>

So we can (finally) switch to the RTEMS.org repos to as the baseline?

On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Add support in tester to run covoar and generate an html report to
>>> display
>>> the summary of the coverage reports generated from covoar.
>>>
>>> Co-authored-by : Cillian O'Donnell 
>>> ---
>>>  .gitignore|   1 +
>>>  tester/rt/coverage.py | 385
>>> ++
>>>  tester/rt/test.py |  34 ++-
>>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>>  create mode 100644 tester/rt/coverage.py
>>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>
>>> diff --git a/.gitignore b/.gitignore
>>> index 6ab3709..93cb5d2 100644
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -9,3 +9,4 @@ waf3-*
>>>  .lock-waf*
>>>  build
>>>  VERSION*
>>> +*symbols.ini
>>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>> new file mode 100644
>>> index 000..54933d5
>>> --- /dev/null
>>> +++ b/tester/rt/coverage.py
>>> @@ -0,0 +1,385 @@
>>> +#
>>> +# RTEMS Tools Project (http://www.rtems.org/)
>>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>>> +# All rights reserved.
>>> +#
>>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>> +#
>>> +# Redistribution and use in source and binary forms, with or without
>>> +# modification, are permitted provided that the following conditions
>>> are met:
>>> +#
>>> +# 1. Redistributions of source code must retain the above copyright
>>> notice,
>>> +# this list of conditions and the following disclaimer.
>>> +#
>>> +# 2. Redistributions in binary form must reproduce the above copyright
>>> notice,
>>> +# this list of conditions and the following disclaimer in the
>>> documentation
>>> +# and/or other materials provided with the distribution.
>>> +#
>>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> 'AS IS'
>>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>>> THE
>>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>> PURPOSE
>>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>>> CONTRIBUTORS BE
>>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>>> BUSINESS
>>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>>> IN
>>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>>> OTHERWISE)
>>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
>>> OF THE
>>> +# POSSIBILITY OF SUCH DAMAGE.
>>> +#
>>> +
>>> +from rtemstoolkit import error
>>> +from rtemstoolkit import path
>>> +from rtemstoolkit import log
>>> +from rtemstoolkit import execute
>>> +from rtemstoolkit import macros
>>> +
>>> +from datetime import datetime
>>> +
>>> +from . import options
>>> +
>>> +import shutil
>>> +import os
>>> +
>>> +try:
>>> +import configparser
>>> +except:
>>> +import ConfigParser as configparser
>>> +
>>> +class summary:
>>> +def __init__(self, p_summary_dir):
>>> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
>>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
>>> +self.bytes_analyzed = 0
>>> +self.bytes_not_executed = 0
>>> +self.percentage_executed = 0.0
>>> +self.percentage_not_executed = 100.0
>>> +self.ranges_uncovered = 0
>>> +self.branches_uncovered = 0
>>> +self.branches_total = 0
>>> +self.branches_always_taken = 0
>>> +self.branches_never_taken = 0
>>> +self.percentage_branches_covered = 0.0
>>> +self.is_failure = False
>>> +
>>> +def parse(self):
>>> +if(not path.exists(self.summary_file_path)):
>>> +log.notice('summary file %s does not exist!' %
>>> (self.summary_file_path))
>>> +self.is_failure = True
>>> +return
>>> +
>>> +with open(self.summary_file_path,'r') as summary_file:
>>> +   self.bytes_analyzed = self._get_next_with_colon(summary_file)
>>> +   self.bytes_not_executed =
>>> self._get_next_with_colon(summary_file)
>>> +   self.percentage_executed =
>>> self._get_next_with_colon(summary_file)
>>> +   self.percentage_not_executed =
>>> 

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 6 June 2018 at 03:57, Joel Sherrill  wrote:

> I think everything is pushed. Is there any patch outstanding?
>
> Thank you.
No outstanding patch, everything on my side is squashed into it. :)

> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Add support in tester to run covoar and generate an html report to display
>> the summary of the coverage reports generated from covoar.
>>
>> Co-authored-by : Cillian O'Donnell 
>> ---
>>  .gitignore|   1 +
>>  tester/rt/coverage.py | 385
>> ++
>>  tester/rt/test.py |  34 ++-
>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>  tester/rtems/testing/qemu.cfg |   4 +-
>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>  create mode 100644 tester/rt/coverage.py
>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>
>> diff --git a/.gitignore b/.gitignore
>> index 6ab3709..93cb5d2 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -9,3 +9,4 @@ waf3-*
>>  .lock-waf*
>>  build
>>  VERSION*
>> +*symbols.ini
>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> new file mode 100644
>> index 000..54933d5
>> --- /dev/null
>> +++ b/tester/rt/coverage.py
>> @@ -0,0 +1,385 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions are
>> met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> 'AS IS'
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>> THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>> BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +from rtemstoolkit import error
>> +from rtemstoolkit import path
>> +from rtemstoolkit import log
>> +from rtemstoolkit import execute
>> +from rtemstoolkit import macros
>> +
>> +from datetime import datetime
>> +
>> +from . import options
>> +
>> +import shutil
>> +import os
>> +
>> +try:
>> +import configparser
>> +except:
>> +import ConfigParser as configparser
>> +
>> +class summary:
>> +def __init__(self, p_summary_dir):
>> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
>> +self.bytes_analyzed = 0
>> +self.bytes_not_executed = 0
>> +self.percentage_executed = 0.0
>> +self.percentage_not_executed = 100.0
>> +self.ranges_uncovered = 0
>> +self.branches_uncovered = 0
>> +self.branches_total = 0
>> +self.branches_always_taken = 0
>> +self.branches_never_taken = 0
>> +self.percentage_branches_covered = 0.0
>> +self.is_failure = False
>> +
>> +def parse(self):
>> +if(not path.exists(self.summary_file_path)):
>> +log.notice('summary file %s does not exist!' %
>> (self.summary_file_path))
>> +self.is_failure = True
>> +return
>> +
>> +with open(self.summary_file_path,'r') as summary_file:
>> +   self.bytes_analyzed = self._get_next_with_colon(summary_file)
>> +   self.bytes_not_executed = self._get_next_with_colon(summ
>> ary_file)
>> +   self.percentage_executed = self._get_next_with_colon(summ
>> ary_file)
>> +   self.percentage_not_executed = self._get_next_with_colon(summ
>> ary_file)
>> +   self.ranges_uncovered = self._get_next_with_colon(summ
>> ary_file)
>> +   self.branches_total = self._get_next_with_colon(summary_file)
>> +   self.branches_uncovered = self._get_next_with_colon(summ
>> ary_file)
>> + 

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Joel Sherrill]

I think everything is pushed. Is there any patch outstanding?

On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Add support in tester to run covoar and generate an html report to display
> the summary of the coverage reports generated from covoar.
>
> Co-authored-by : Cillian O'Donnell 
> ---
>  .gitignore|   1 +
>  tester/rt/coverage.py | 385
> ++
>  tester/rt/test.py |  34 ++-
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>  tester/rtems/testing/qemu.cfg |   4 +-
>  6 files changed, 450 insertions(+), 13 deletions(-)
>  create mode 100644 tester/rt/coverage.py
>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>
> diff --git a/.gitignore b/.gitignore
> index 6ab3709..93cb5d2 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -9,3 +9,4 @@ waf3-*
>  .lock-waf*
>  build
>  VERSION*
> +*symbols.ini
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> new file mode 100644
> index 000..54933d5
> --- /dev/null
> +++ b/tester/rt/coverage.py
> @@ -0,0 +1,385 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> met:
> +#
> +# 1. Redistributions of source code must retain the above copyright
> notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the
> documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS
> IS'
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +from rtemstoolkit import error
> +from rtemstoolkit import path
> +from rtemstoolkit import log
> +from rtemstoolkit import execute
> +from rtemstoolkit import macros
> +
> +from datetime import datetime
> +
> +from . import options
> +
> +import shutil
> +import os
> +
> +try:
> +import configparser
> +except:
> +import ConfigParser as configparser
> +
> +class summary:
> +def __init__(self, p_summary_dir):
> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
> +self.index_file_path = path.join(p_summary_dir, 'index.html')
> +self.bytes_analyzed = 0
> +self.bytes_not_executed = 0
> +self.percentage_executed = 0.0
> +self.percentage_not_executed = 100.0
> +self.ranges_uncovered = 0
> +self.branches_uncovered = 0
> +self.branches_total = 0
> +self.branches_always_taken = 0
> +self.branches_never_taken = 0
> +self.percentage_branches_covered = 0.0
> +self.is_failure = False
> +
> +def parse(self):
> +if(not path.exists(self.summary_file_path)):
> +log.notice('summary file %s does not exist!' %
> (self.summary_file_path))
> +self.is_failure = True
> +return
> +
> +with open(self.summary_file_path,'r') as summary_file:
> +   self.bytes_analyzed = self._get_next_with_colon(summary_file)
> +   self.bytes_not_executed = self._get_next_with_colon(
> summary_file)
> +   self.percentage_executed = self._get_next_with_colon(
> summary_file)
> +   self.percentage_not_executed = self._get_next_with_colon(
> summary_file)
> +   self.ranges_uncovered = self._get_next_with_colon(
> summary_file)
> +   self.branches_total = self._get_next_with_colon(summary_file)
> +   self.branches_uncovered = self._get_next_with_colon(
> summary_file)
> +   self.branches_always_taken = self._get_next_without_colon(
> summary_file)
> +   self.branches_never_taken = self._get_next_without_colon(
> summary_file)
> +if len(self.branches_uncovered) > 0 and len(self.branches_total)
> > 0:
> +   

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Joel Sherrill]

On Tue, Jun 5, 2018 at 4:27 PM, Amaan Cheval  wrote:

> Hi! Thanks for the guidance, both of you! I think we're quite close
> now to integrating gnu-efi in and finally having the stub port boot as
> a UEFI application image. All the test exe's generated on my local
> tree are now dynamic libraries, so both Newlib and crtbeginS/crtendS
> issues have been resolved (see point 2 below for the relevant WIP
> patches).
>
> Here's what I've done:
>
> - Updated amd64.cfg as Joel instructed earlier - here I put "-shared"
> in LDFLAGS instead of CPU_CFLAGS because of configure trying to use
> CPU_CFLAGS in general, running into unresolved symbols coming from
> GCC's stub crt0.c, and falling down. Putting it in LDFLAGS lets me
> work around this, but I'd appreciate a thumbs-up on this being okay:
>
> https://github.com/AmaanC/rtems-gsoc18/commit/
> 547ef85a7f176046b2cb06a34b1e312c4986e97f#diff-
> c64f46c71f828120e08bc4c8667f0525R18
>
>
This looks like the other BSPs.


> - Updated GCC as follows, building on top of Joel's WIP patch to
> minimize bsp_specs:
>
> https://github.com/AmaanC/gcc/pull/1


This doesn't have much code to review either. I think it is OK.


>
>
> I made it a PR on my fork so viewing it commit-wise or as a whole diff
> is easier for you to review. I'll look into how to make and use
> multilib variants next.
>
> Let me know what you think (about the LDFLAGS workaround, and the
> approach for the GCC patch so far).
>

The amd64.cfg file looks like I would expect. Not really a hack.

>
> On Mon, Jun 4, 2018 at 6:42 PM, Joel Sherrill  wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber
> >  wrote:
> >>
> >>
> >>
> >> - Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval
> amaan.che...@gmail.com:
> >>
> >> > That's a good idea. That way based on the multilib variant, Newlib
> would
> >> > be
> >> > compiled using fPIC, yes?
> >>
> >> Yes.
> >
> >
> > This would be desirable for the i386 as well. Having the RTEMS libraries
> as
> > dynamic libraries would be more natural under Deos.
> >
> > Just a statement. Not a requirement on the GSoC project.
> >>
> >>
> >> >
> >> > Then I could simply figure out how to solve the crtbegin and crtend
> >> > dilemma
> >> > (which I believe should be easier), and use those to have a
> >> > dynamic/shared
> >> > RTEMS kernel + user application.
> >>
> >> These files will be compiled with -fPIC as well.
> >
> >
> >
> >>
> >>
> >> >
> >> > If that sounds right, I'll look into that first. Not familiar with the
> >> > GCC
> >> > source yet, but it should be doable.
> >>
> >> Sorry, I have no idea how the x86_64 configuration of GCC works for
> RTEMS.
> >>
> >> >
> >> >
> >> > On Mon, Jun 4, 2018, 3:43 PM Sebastian Huber <
> >> > sebastian.hu...@embedded-brains.de> wrote:
> >> >
> >> >> Hello Amaan,
> >> >>
> >> >> can't you add a new multilib variant which includes -fPIC to the GCC
> >> >> configuration for RTEMS?
> >> ___
> >> 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: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Amaan Cheval]

Hi! Thanks for the guidance, both of you! I think we're quite close
now to integrating gnu-efi in and finally having the stub port boot as
a UEFI application image. All the test exe's generated on my local
tree are now dynamic libraries, so both Newlib and crtbeginS/crtendS
issues have been resolved (see point 2 below for the relevant WIP
patches).

Here's what I've done:

- Updated amd64.cfg as Joel instructed earlier - here I put "-shared"
in LDFLAGS instead of CPU_CFLAGS because of configure trying to use
CPU_CFLAGS in general, running into unresolved symbols coming from
GCC's stub crt0.c, and falling down. Putting it in LDFLAGS lets me
work around this, but I'd appreciate a thumbs-up on this being okay:

https://github.com/AmaanC/rtems-gsoc18/commit/547ef85a7f176046b2cb06a34b1e312c4986e97f#diff-c64f46c71f828120e08bc4c8667f0525R18

- Updated GCC as follows, building on top of Joel's WIP patch to
minimize bsp_specs:

https://github.com/AmaanC/gcc/pull/1

I made it a PR on my fork so viewing it commit-wise or as a whole diff
is easier for you to review. I'll look into how to make and use
multilib variants next.

Let me know what you think (about the LDFLAGS workaround, and the
approach for the GCC patch so far).

On Mon, Jun 4, 2018 at 6:42 PM, Joel Sherrill  wrote:
>
>
> On Mon, Jun 4, 2018 at 5:44 AM, Sebastian Huber
>  wrote:
>>
>>
>>
>> - Am 4. Jun 2018 um 12:20 schrieb Amaan Cheval amaan.che...@gmail.com:
>>
>> > That's a good idea. That way based on the multilib variant, Newlib would
>> > be
>> > compiled using fPIC, yes?
>>
>> Yes.
>
>
> This would be desirable for the i386 as well. Having the RTEMS libraries as
> dynamic libraries would be more natural under Deos.
>
> Just a statement. Not a requirement on the GSoC project.
>>
>>
>> >
>> > Then I could simply figure out how to solve the crtbegin and crtend
>> > dilemma
>> > (which I believe should be easier), and use those to have a
>> > dynamic/shared
>> > RTEMS kernel + user application.
>>
>> These files will be compiled with -fPIC as well.
>
>
>
>>
>>
>> >
>> > If that sounds right, I'll look into that first. Not familiar with the
>> > GCC
>> > source yet, but it should be doable.
>>
>> Sorry, I have no idea how the x86_64 configuration of GCC works for RTEMS.
>>
>> >
>> >
>> > On Mon, Jun 4, 2018, 3:43 PM Sebastian Huber <
>> > sebastian.hu...@embedded-brains.de> wrote:
>> >
>> >> Hello Amaan,
>> >>
>> >> can't you add a new multilib variant which includes -fPIC to the GCC
>> >> configuration for RTEMS?
>> ___
>> 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

[PATCH] x86_64/binutils: Add PEI target to build UEFI application images

[Amaan Cheval]

Original commit in binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=421acf18739edb54111b64d2b328ea2e7bf19889

Update #2898
---
 rtems/config/5/rtems-x86_64.bset | 5 +
 1 file changed, 5 insertions(+)

diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index 9b92538..6041971 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -14,4 +14,9 @@
 %patch add gcc --rsb-file=gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=libgcc/config.host;h=f8fd78279d353f6959e75ac25571c1b7b2dec110;hp=11b4acaff55e00ee6bd3c182e9da5dc597ac57c4;hb=ab55f7db3694293e4799d58f7e1a556c0eae863a;hpb=344c180cca810c50f38fd545bb9a102fb39306b7
 %hash sha512 gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
aef76f9d45a53096a021521375fc302a907f78545cc57683a7a00ec61608b8818115720f605a6b1746f479c8568963b380138520e259cbb9e8951882c2f1567f
 
+#
+# Binutils PEI target for UEFI support
+#
+%patch add binutils 
--rsb-file=binutils-f8ca72b332396939c7c04a8774ce4c54f5a82d42.patch 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff_plain;f=bfd/config.bfd;h=f8ca72b332396939c7c04a8774ce4c54f5a82d42;hp=0db8ed4562b2c11ce51e6a3b138c317f4014a1aa;hb=421acf18739edb54111b64d2b328ea2e7bf19889;hpb=f7c6f42310233479ea6339430b7c1ca1f9ec68e1
+%hash sha512 binutils-f8ca72b332396939c7c04a8774ce4c54f5a82d42.patch 
f8af6906871a95a6fb234d0c72c44e9b1823ed835ec91bd84b466aad1f2f5f021ff5fb37835e6132899dcaa6c7e52e3e73f5a2dc9f0efab97aa6fffce2f06d9e
 %include 5/rtems-default.bset
-- 
2.16.0.rc0

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

Compiler Explorer Website

[Joel Sherrill]

Hi

Came across this and thought the community would be interested.

https://gcc.godbolt.org/#

Play. :)

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

Re: [PATCH] Adding tracing documentation in user manual

[Gedare Bloom]

On Tue, Jun 5, 2018 at 11:40 AM, Vidushi Vashishth  wrote:
> ---
>  user/index.rst|  2 +
>  user/tracing/development.rst  | 12 ++
>  user/tracing/index.rst| 25 
>  user/tracing/introduction.rst | 90 
> +++
>  user/tracing/usecases.rst | 77 
>  5 files changed, 206 insertions(+)
>  create mode 100644 user/tracing/development.rst
>  create mode 100644 user/tracing/index.rst
>  create mode 100644 user/tracing/introduction.rst
>  create mode 100644 user/tracing/usecases.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 8cbcd1b..a764fe8 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
>
> tools/index
>
> +tracing/index
> +
> support/index
>
> glossary/index
> diff --git a/user/tracing/development.rst b/user/tracing/development.rst
> new file mode 100644
> index 000..ad74d8f
> --- /dev/null
> +++ b/user/tracing/development.rst
> @@ -0,0 +1,12 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _development:
> +
> +Tracing Development
> +***
> +
> +RTEMS trace is an open source project currently under development.
> +
> +This section can contain how to build the rtems-tools after making changes 
> to the trace linker.
> diff --git a/user/tracing/index.rst b/user/tracing/index.rst
> new file mode 100644
> index 000..ad22439
> --- /dev/null
> +++ b/user/tracing/index.rst
> @@ -0,0 +1,25 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _tracing-framework:
> +
> +RTEMS Tracing Framework
> +***
> +.. index:: Tracing Framework
> +
> +RTEMS Tracing Framework is an on-target software based system which helps 
> track
> +the ongoings inside applications, 3rd party packages and the kernel in real 
> time.
> +

I don't know how it is elsewhere, but I would prefer to see the Oxford
comma here, i.e., "3rd party packages, and the kernel"

> +Software based tracing is a complex process which requires components on 
> both the
> +target and the host to work together. However its portability across all 
> architectures
> +and board support packages makes it a useful asset. A key requirement in 
> RTEMS trace process
> +is to take existing code in compiled format (ELF) and instrument it in order 
> to log various events
> +and records in real time. However instrumenting of the code for tracing 
> should happen without rebuilding
> +the code from the source and without annotating the source with trace code.
> +
> +.. toctree::
> +
> +   introduction
> +   usecases
> +   development
> diff --git a/user/tracing/introduction.rst b/user/tracing/introduction.rst
> new file mode 100644
> index 000..3314447
> --- /dev/null
> +++ b/user/tracing/introduction.rst
> @@ -0,0 +1,90 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _introduction:
> +
> +Introduction to Tracing
> +***
> +
> +Tracing is an important function which has several applications including 
> identification of
> +complex threading, detection of deadlocks, tracing functions along with 
> their argument values,
> +and return values through progression of several function calls and audit 
> the performance of an
> +application according to required specifications.
> +
> +RTEMS tracing framework is under development and welcomes contribution by 
> users.
> +
> +RTEMS has the following trace components:
> +
> +- RTEMS Trace Linker
> +- Capture Engine
> +- Common Trace Format Integration
> +
> +.. note::
> +
> +I could create separate pages to explain the aforementioned 
> components in detail.
> +
Remove this note, and create/link the separate pages with the "TBD" stub.

> +
> +RTEMS trace framework can currently function using the following methods:
> +
> +RTEMS Trace Using Trace Buffering
> +=
> +
> +To be completed
> +
> +RTEMS Trace Using Printk
> +
> +
> +To be completed
> +
> +RTEMS Trace Using CTF
> +=
> +
> +`Common Trace Format `_ is a binary trace format 
> which is fast to write
> +and has great flexibility. It allows traces to be developed by bare-metal 
> applications or by any
> +other C/C++ system. RTEMS tracing framework can benefit from these features 
> of CTF.
> +
> +A typical CTF *trace* consists of multiple *streams* of binary *events*. It 
> is upto us how many
> +streams we want to divide our tracer generated events into. The *metadata* 
> stream is a mandatory

Delete "It is upto us ... events into." This is an unnecessary
statement in user documentation.

> +stream which describes the layout of all the other streams in a trace. This 
> metadata stream is written
> +using *Trace 

Re: [PATCH] Adding tracing documentation in user manual

[Vidushi Vashishth]

Hi!

This is a rough skeleton of the tracing chapter in the user manual
documentation with some incomplete bits. I have covered the "to be
completed bits" in some of my blogs and that should not take much time to
finish. Let me know if you have suggestions.

Thanks!
Vidushi

On Tue, Jun 5, 2018 at 9:10 PM, Vidushi Vashishth 
wrote:

> ---
>  user/index.rst|  2 +
>  user/tracing/development.rst  | 12 ++
>  user/tracing/index.rst| 25 
>  user/tracing/introduction.rst | 90 ++
> +
>  user/tracing/usecases.rst | 77 
>  5 files changed, 206 insertions(+)
>  create mode 100644 user/tracing/development.rst
>  create mode 100644 user/tracing/index.rst
>  create mode 100644 user/tracing/introduction.rst
>  create mode 100644 user/tracing/usecases.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 8cbcd1b..a764fe8 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/
> .
>
> tools/index
>
> +tracing/index
> +
> support/index
>
> glossary/index
> diff --git a/user/tracing/development.rst b/user/tracing/development.rst
> new file mode 100644
> index 000..ad74d8f
> --- /dev/null
> +++ b/user/tracing/development.rst
> @@ -0,0 +1,12 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _development:
> +
> +Tracing Development
> +***
> +
> +RTEMS trace is an open source project currently under development.
> +
> +This section can contain how to build the rtems-tools after making
> changes to the trace linker.
> diff --git a/user/tracing/index.rst b/user/tracing/index.rst
> new file mode 100644
> index 000..ad22439
> --- /dev/null
> +++ b/user/tracing/index.rst
> @@ -0,0 +1,25 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _tracing-framework:
> +
> +RTEMS Tracing Framework
> +***
> +.. index:: Tracing Framework
> +
> +RTEMS Tracing Framework is an on-target software based system which helps
> track
> +the ongoings inside applications, 3rd party packages and the kernel in
> real time.
> +
> +Software based tracing is a complex process which requires components on
> both the
> +target and the host to work together. However its portability across all
> architectures
> +and board support packages makes it a useful asset. A key requirement in
> RTEMS trace process
> +is to take existing code in compiled format (ELF) and instrument it in
> order to log various events
> +and records in real time. However instrumenting of the code for tracing
> should happen without rebuilding
> +the code from the source and without annotating the source with trace
> code.
> +
> +.. toctree::
> +
> +   introduction
> +   usecases
> +   development
> diff --git a/user/tracing/introduction.rst b/user/tracing/introduction.rst
> new file mode 100644
> index 000..3314447
> --- /dev/null
> +++ b/user/tracing/introduction.rst
> @@ -0,0 +1,90 @@
> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. comment: All rights reserved.
> +
> +.. _introduction:
> +
> +Introduction to Tracing
> +***
> +
> +Tracing is an important function which has several applications including
> identification of
> +complex threading, detection of deadlocks, tracing functions along with
> their argument values,
> +and return values through progression of several function calls and audit
> the performance of an
> +application according to required specifications.
> +
> +RTEMS tracing framework is under development and welcomes contribution by
> users.
> +
> +RTEMS has the following trace components:
> +
> +- RTEMS Trace Linker
> +- Capture Engine
> +- Common Trace Format Integration
> +
> +.. note::
> +
> +I could create separate pages to explain the aforementioned
> components in detail.
> +
> +
> +RTEMS trace framework can currently function using the following methods:
> +
> +RTEMS Trace Using Trace Buffering
> +=
> +
> +To be completed
> +
> +RTEMS Trace Using Printk
> +
> +
> +To be completed
> +
> +RTEMS Trace Using CTF
> +=
> +
> +`Common Trace Format `_ is a binary trace format
> which is fast to write
> +and has great flexibility. It allows traces to be developed by bare-metal
> applications or by any
> +other C/C++ system. RTEMS tracing framework can benefit from these
> features of CTF.
> +
> +A typical CTF *trace* consists of multiple *streams* of binary *events*.
> It is upto us how many
> +streams we want to divide our tracer generated events into. The
> *metadata* stream is a mandatory
> +stream which describes the layout of all the other streams in a trace.
> This metadata stream is written
> +using *Trace Stream Description Language* (TSDL).
> 

Re: RISC-V tool chain

[Joel Sherrill]

On Tue, Jun 5, 2018 at 9:07 AM, Gedare Bloom  wrote:

> On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
>  wrote:
> > Hello,
> >
> > the RISC-V is a new architecture and the tool chain is still under active
> > development. For example one bug which blocks the RTEMS support of the
> > 64-bit RISC-V was fixed this week:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=23244
> >
> > The GDB support is only available in the development branch of GDB. This
> > makes it a bit difficult to use release versions of the tools. We used
> > snapshots in the past, but the snapshots are removed from the FSF
> download
> > sites and mirrors after some time (e.g. half a year). This is not good if
> > you want to bisect a bug and need to build the tool chain used for a
> certain
> > RTEMS version.
> >
> > What do you think about adding snapshots used by RSB to the RTEMS FTP
> > server?
> >
> Hello Sebastian,
>
> I believe this has been discussed before although I can't find the
> thread. I have concerns about the maintenance of snapshots. How many
> target toolchains will we do this for, what frequency will snapshots
> be taken, and how long will we preserve them?
>
> Is there a different low-cost technical solution that can be used
> instead of a snapshot? For example, we can check-out a specific commit
> from a repository: wouldn't it work well enough to identify such
> commits and update them periodically instead of taking a full snapshot
> of the tool sources? I believe this is how we have dealt with qemu in
> the RSB, by picking one commit and sticking with it for awhile.
>

Using the git commit hash is better. If we have to stick with a snapshot
going into a release, the release procedure grabs a tar image as I recall.

--joel


>
> Gedare
>
> > --
> > 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
> ___
> 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: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Joel Sherrill]

Not sure why I haven't weighed in yet.

On Tue, Jun 5, 2018 at 8:56 AM, Gedare Bloom  wrote:

> Hi Sebastian, Joel:
>
> I am unsure about the placement of BSP guidance in the User Manual. I
> like the change overall it is positive to create high-quality BSP
> documentation.


Someone mentioned duplicating the TRM for the CPU or board. That's
a bit unavoidable on a topic level when you have an option which is
the initial value for a specific IO register or clock. You have to describe
that option well enough for a user to be able to set it. This will
necessarily
duplicate some information. We can reference the appropriate documentation
and source files.

This also applies at a board level when it comes to jumper, DIP switch,
or ROM monitor settings.

Since we leave U-Boot mkimage invocation to the user's imagination that's
another piece of the puzzle which the user needs to know.

Advice and set up on debug HW or target agents known to work.

The goal should be that they get all the info they need to configure their
hardware and RTEMS to match expectations. We don't have to duplicate
third party manuals but we should give the user a roadmap to get things
working.


> I have 2 concerns:
> 1. It should be clearly labelled as an incomplete set of the BSPs
> however. Right now, if someone picks up this example user.pdf, it
> would seem we have only one BSP in RTEMS if you only look at this new
> chapter. Maybe it makes sense to merge the text from 8.3 Board Support
> Packages (BSP) into the new chapter dedicated toward BSPs.
>

One solution to this is to fill in the outline with TBDs for at least all
the
architectures.

We need to figure out how to deal with BSP variants.

We also need to assume that core developers will have to write the
sections on simulator BSPs. I expect a fairly standard template for a
qemu or gdb based simulator.

I have wondered if we need a tracking spreadsheet for BSPs to show
what we think is missing or needs updating. For example, some BSPs
still don't have the linkcmds sections for per-function linking. Some older
BSPs are still in use and perhaps by pinging people we can get sections
filled in. But on the other hand, this could indicate a BSP is on a path to
deprecation. The lack of documentation is another brick in this wall.


> 2. The size of this Chapter 9 BSPs eventually is going to become much
> larger compared to the rest of the manual. It might make better sense
> to create it as a supplemental document that you refer to from 8.3
> Board Support Packages (BSP). As you say, it is different from the BSP
> Developer's Guide, but I think it will be sensible to create an "RTEMS
> User Manual BSP Supplement".
>

Depends on the length per BSP family or BSP variant. Five pages per
variant will end up in the 800-1000 page range. That would be a lovely
problem to have.

I hesitate to start another document that is tiny but if we start it with
a complete outline with TBD sections, it makes sense. It will be fairly
hefty even with TBDs.

--joel


>
> Gedare
>
> On Tue, Jun 5, 2018 at 2:52 AM, Sebastian Huber
>  wrote:
> > Ping.
> >
> >
> > On 30/04/18 08:26, Sebastian Huber wrote:
> >>
> >> On 17/04/18 12:30, Chris Johns wrote:
> >>>
> >>> On 26/3/18 7:09 pm, Sebastian Huber wrote:
> 
>  On 26/03/18 00:50, Chris Johns wrote:
> >
> > On 14/03/2018 17:20, Sebastian Huber wrote:
> >>
> >> On 13/03/18 22:58, Chris Johns wrote:
> >>>
> >>> On 09/03/2018 19:55, Sebastian Huber wrote:
> 
>  On 06/11/17 10:03, Sebastian Huber wrote:
> >
> > On 26/10/17 08:22, Sebastian Huber wrote:
> >>
> >> Please review this patch carefully. It adds a new chapter "ARM
> >> Board Support
> >> Packages" following the "ARM Specific Information" chapter. It
> >> adds a
> >> template structure for other BSPs.
> >>
> >> Where should we place common BSP configuration options like
> >> BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy
> and
> >> paste
> >> version to every BSP section.
> >>
> > Any comments with respect to the BSP documentation? It makes
> little
> > sense to
> > start with this work if the general direction is unclear.
> >
>  The insufficient and user unfriendly BSP documentation is still a
>  big issue
>  from
>  my point of view. I think it is one of be biggest obstacles to get
>  started
>  with
>  RTEMS. The BSP documentation should be part of a sphinx based
>  rtems-docs
>  manual.
> 
> >>> How do we get the large number of BSP_OPTS parameters out of the
> BSPs
> >>> and into
> >>> suitable documentation? I am reluctant to support fragmented or
> >>> partial
> >>> approaches to solving this problem, I feel the "project" or effect
> >>> needs to
> >>> accept _all_ BSPs need to be covered. 

Re: RISC-V tool chain

[Gedare Bloom]

On Tue, Jun 5, 2018 at 9:30 AM, Sebastian Huber
 wrote:
> Hello,
>
> the RISC-V is a new architecture and the tool chain is still under active
> development. For example one bug which blocks the RTEMS support of the
> 64-bit RISC-V was fixed this week:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=23244
>
> The GDB support is only available in the development branch of GDB. This
> makes it a bit difficult to use release versions of the tools. We used
> snapshots in the past, but the snapshots are removed from the FSF download
> sites and mirrors after some time (e.g. half a year). This is not good if
> you want to bisect a bug and need to build the tool chain used for a certain
> RTEMS version.
>
> What do you think about adding snapshots used by RSB to the RTEMS FTP
> server?
>
Hello Sebastian,

I believe this has been discussed before although I can't find the
thread. I have concerns about the maintenance of snapshots. How many
target toolchains will we do this for, what frequency will snapshots
be taken, and how long will we preserve them?

Is there a different low-cost technical solution that can be used
instead of a snapshot? For example, we can check-out a specific commit
from a repository: wouldn't it work well enough to identify such
commits and update them periodically instead of taking a full snapshot
of the tool sources? I believe this is how we have dealt with qemu in
the RSB, by picking one commit and sticking with it for awhile.

Gedare

> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Gedare Bloom]

Hi Sebastian, Joel:

I am unsure about the placement of BSP guidance in the User Manual. I
like the change overall it is positive to create high-quality BSP
documentation.  I have 2 concerns:
1. It should be clearly labelled as an incomplete set of the BSPs
however. Right now, if someone picks up this example user.pdf, it
would seem we have only one BSP in RTEMS if you only look at this new
chapter. Maybe it makes sense to merge the text from 8.3 Board Support
Packages (BSP) into the new chapter dedicated toward BSPs.
2. The size of this Chapter 9 BSPs eventually is going to become much
larger compared to the rest of the manual. It might make better sense
to create it as a supplemental document that you refer to from 8.3
Board Support Packages (BSP). As you say, it is different from the BSP
Developer's Guide, but I think it will be sensible to create an "RTEMS
User Manual BSP Supplement".

Gedare

On Tue, Jun 5, 2018 at 2:52 AM, Sebastian Huber
 wrote:
> Ping.
>
>
> On 30/04/18 08:26, Sebastian Huber wrote:
>>
>> On 17/04/18 12:30, Chris Johns wrote:
>>>
>>> On 26/3/18 7:09 pm, Sebastian Huber wrote:

 On 26/03/18 00:50, Chris Johns wrote:
>
> On 14/03/2018 17:20, Sebastian Huber wrote:
>>
>> On 13/03/18 22:58, Chris Johns wrote:
>>>
>>> On 09/03/2018 19:55, Sebastian Huber wrote:

 On 06/11/17 10:03, Sebastian Huber wrote:
>
> On 26/10/17 08:22, Sebastian Huber wrote:
>>
>> Please review this patch carefully. It adds a new chapter "ARM
>> Board Support
>> Packages" following the "ARM Specific Information" chapter. It
>> adds a
>> template structure for other BSPs.
>>
>> Where should we place common BSP configuration options like
>> BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy and
>> paste
>> version to every BSP section.
>>
> Any comments with respect to the BSP documentation? It makes little
> sense to
> start with this work if the general direction is unclear.
>
 The insufficient and user unfriendly BSP documentation is still a
 big issue
 from
 my point of view. I think it is one of be biggest obstacles to get
 started
 with
 RTEMS. The BSP documentation should be part of a sphinx based
 rtems-docs
 manual.

>>> How do we get the large number of BSP_OPTS parameters out of the BSPs
>>> and into
>>> suitable documentation? I am reluctant to support fragmented or
>>> partial
>>> approaches to solving this problem, I feel the "project" or effect
>>> needs to
>>> accept _all_ BSPs need to be covered. This is a community effort that
>>> needs
>>> some
>>> leadership and ownership.
>>>
>>> It is a difficult area because:
>>>
>>> 1. The overlap to device TRMs and yet wanting to provide some self
>>> contained
>>> information for a device knowledgeable user.
>>>
>>> 2. How is it maintained and checked? Reviews of patches require
>>> related doc
>>> patches?
>>>
>>> 3. Changing the build system, the waf build Amar created changes the
>>> way
>>> BSP_OPTS are handled requiring clear definition with ranges and other
>>> factors
>>> and that could be annotated with suitable documentation allowing
>>> automatic
>>> generation. Do we push for funding for this effort and deal with it
>>> then?
>>
>> For BSP documentation you need to know the hardware and the BSP in
>> detail. I
>> think we can only do this step by step and should focus on the BSPs
>> that are
>> still in use and maintained. We need a clear concept of the desired
>> BSP
>> documentation, so that it is easy for new contributors to fix the
>> documentation
>> of their BSP of interest. A build configuration command line help for
>> BSP
>> options would be nice, but I think this is optional. I would remove
>> the BSP
>> options documentation in configure.ac for BSPs which document the
>> options in a
>> manual. If we want to provide build configuration command line help,
>> then we
>> should generate it from some documentation master and use it for the
>> command
>> line help and the manual. This is some extra effort. It is probably in
>> the range
>> of several man weeks to update the documentation of all BSPs.
>
> Agreed and this will need to change any way. A waf build system would
> bring all
> these option out to the top level which is a important. They are hidden
> at the
> moment which is painful.
>
>> The manual should have one level for the architectures, one level for
>> the BSPs
>> and one for the BSP details. I would not use more than three levels in
>> a PDF
>> document. Do we want to create a dedicated BSP 

RISC-V tool chain

[Sebastian Huber]

Hello,

the RISC-V is a new architecture and the tool chain is still under 
active development. For example one bug which blocks the RTEMS support 
of the 64-bit RISC-V was fixed this week:


https://sourceware.org/bugzilla/show_bug.cgi?id=23244

The GDB support is only available in the development branch of GDB. This 
makes it a bit difficult to use release versions of the tools. We used 
snapshots in the past, but the snapshots are removed from the FSF 
download sites and mirrors after some time (e.g. half a year). This is 
not good if you want to bisect a bug and need to build the tool chain 
used for a certain RTEMS version.


What do you think about adding snapshots used by RSB to the RTEMS FTP 
server?


--
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: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Sebastian Huber]

Ping.

On 30/04/18 08:26, Sebastian Huber wrote:

On 17/04/18 12:30, Chris Johns wrote:

On 26/3/18 7:09 pm, Sebastian Huber wrote:

On 26/03/18 00:50, Chris Johns wrote:

On 14/03/2018 17:20, Sebastian Huber wrote:

On 13/03/18 22:58, Chris Johns wrote:

On 09/03/2018 19:55, Sebastian Huber wrote:

On 06/11/17 10:03, Sebastian Huber wrote:

On 26/10/17 08:22, Sebastian Huber wrote:
Please review this patch carefully. It adds a new chapter "ARM 
Board Support
Packages" following the "ARM Specific Information" chapter. It 
adds a

template structure for other BSPs.

Where should we place common BSP configuration options like
BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy 
and paste

version to every BSP section.

Any comments with respect to the BSP documentation? It makes 
little sense to

start with this work if the general direction is unclear.

The insufficient and user unfriendly BSP documentation is still 
a big issue

from
my point of view. I think it is one of be biggest obstacles to 
get started

with
RTEMS. The BSP documentation should be part of a sphinx based 
rtems-docs

manual.

How do we get the large number of BSP_OPTS parameters out of the 
BSPs and into
suitable documentation? I am reluctant to support fragmented or 
partial
approaches to solving this problem, I feel the "project" or 
effect needs to
accept _all_ BSPs need to be covered. This is a community effort 
that needs

some
leadership and ownership.

It is a difficult area because:

1. The overlap to device TRMs and yet wanting to provide some 
self contained

information for a device knowledgeable user.

2. How is it maintained and checked? Reviews of patches require 
related doc

patches?

3. Changing the build system, the waf build Amar created changes 
the way
BSP_OPTS are handled requiring clear definition with ranges and 
other factors
and that could be annotated with suitable documentation allowing 
automatic
generation. Do we push for funding for this effort and deal with 
it then?
For BSP documentation you need to know the hardware and the BSP in 
detail. I
think we can only do this step by step and should focus on the 
BSPs that are
still in use and maintained. We need a clear concept of the 
desired BSP
documentation, so that it is easy for new contributors to fix the 
documentation
of their BSP of interest. A build configuration command line help 
for BSP
options would be nice, but I think this is optional. I would 
remove the BSP
options documentation in configure.ac for BSPs which document the 
options in a
manual. If we want to provide build configuration command line 
help, then we
should generate it from some documentation master and use it for 
the command
line help and the manual. This is some extra effort. It is 
probably in the range

of several man weeks to update the documentation of all BSPs.
Agreed and this will need to change any way. A waf build system 
would bring all
these option out to the top level which is a important. They are 
hidden at the

moment which is painful.

The manual should have one level for the architectures, one level 
for the BSPs
and one for the BSP details. I would not use more than three 
levels in a PDF
document. Do we want to create a dedicated BSP manual or merge it 
into an

existing manual (which one and how)?
Can the BSP and Driver Guide be used or do you think we need 
something new?
The BSP and Driver Guide contains mostly information for a BSP and 
driver

developer.

If we use four levels, we could add this to the User Manual (it uses 
already

four levels), e.g.

Board Support Packages (BSPs)
 -> Architecture
     -> BSP
         -> Some stuff

See attached file.

The PDF file looks good. I am OK with this but I would like Joel to 
respond.


Joel, what is your point of view?



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