Re: SIS with coverage support

2019-01-24 Thread Jiri Gaisler

On 1/24/19 12:45 AM, Joel Sherrill wrote:
>
>
> On Wed, Jan 23, 2019 at 4:45 PM Chris Johns  > wrote:
>
> On 24/1/19 9:12 am, Jiri Gaisler wrote:
> > After some trial and error, I got covoar to run with:
>
> Great.
>
> > However, the coverage is always 0% in the summary report:
>
> Does adding -v to the command line provide any more detail? Repeating -v
> increases the level but things can become rather verbose and if you trip 
> full
> DWARF tracing there is a lot of output.
>
>
> I would be suspicious of the code that is invoked around
> CoverageReaderTSIM.cc:83 as a starting point. For some method you
> know you should be analyzed, there should be aCoverageMap. Since you
> are looking at only one executable, you could hard-code a test with
> address range of a single method under test to see what happens.
>

Well, the problem is that covoar in rtems-tools is hard-coded to use the QEMU 
format, and the -f switch to change format is not used. I have attached a patch 
to fix that. After that, covoar works fine with the coverage data from sis:

cat coverage/summary.txt
Bytes Analyzed   : 20034
Bytes Not Executed   : 11734
Percentage Executed  : 41.43
Percentage Not Executed  : 58.57
Uncovered ranges found   : 242
Total branches found : 443
Uncovered branches found : 167
   68 branches always taken
   99 branches never taken

If you approve to the patch, then I will check it in (now that I know how ... 
:-))


diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 36c24c3..c1e328b 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -359,6 +359,7 @@ int covoar(
 AllExplanations->load( explanations );
 
   // Create coverage map reader.
+  coverageFormat = Coverage::CoverageFormatToEnum(format);
   coverageReader = Coverage::CreateCoverageReader(coverageFormat);
   if (!coverageReader)
 throw rld::error( "Unable to create coverage file reader", "covoar" );
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 00/10] Rework quick start in user manual

2019-01-24 Thread Sebastian Huber
This patch set reworks the quick start chapter in the user manual. You
find a PDF with this patch set here:

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

It duplicates some information with the "Installation" chapter.  The
"Installation" chapter should be reworked to contain the details.

The "Build Your Application" is a TODO.

Sebastian Huber (10):
  user: Rework "Host Computer Setup" section
  user: Fix references to prefixes section
  user: Rework Prefixes section
  user: Add "Obtain the Sources" section
  user: Add "Install the Tool Suite" section
  user: Add "Bootstrap the RTEMS Sources"
  user: Add "Build a Board Support Package (BSP)"
  user: Add "Test a Board Support Package (BSP)"
  user: Add "Build Your Application"
  user: Remove obsolete content in quick start

 user/hardware/architectures.rst  |   3 +
 user/hosts/macos.rst |   2 +-
 user/hosts/posix.rst |   4 +-
 user/installation/project-sandboxing.rst |   5 +-
 user/installation/releases.rst   |   4 +-
 user/rsb/why-build-from-source.rst   |   2 +
 user/start/app.rst   |  11 +++
 user/start/bootstrap.rst |  55 
 user/start/bsp-build.rst | 146 +++
 user/start/bsp-test.rst  |  66 ++
 user/start/host.rst  |  20 +++--
 user/start/index.rst |  93 ++--
 user/start/prefixes.rst  |  79 +
 user/start/sources.rst   |  51 +++
 user/start/tools.rst | 126 ++
 user/testing/index.rst   |   2 +
 user/tools/index.rst |   2 +
 17 files changed, 526 insertions(+), 145 deletions(-)
 create mode 100644 user/start/app.rst
 create mode 100644 user/start/bootstrap.rst
 create mode 100644 user/start/bsp-build.rst
 create mode 100644 user/start/bsp-test.rst
 create mode 100644 user/start/sources.rst
 create mode 100644 user/start/tools.rst

-- 
2.16.4

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


[PATCH 01/10] user: Rework "Host Computer Setup" section

2019-01-24 Thread Sebastian Huber
Rename it to "Prepare Your Host Computer".
---
 user/rsb/why-build-from-source.rst |  2 ++
 user/start/host.rst| 20 +++-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/user/rsb/why-build-from-source.rst 
b/user/rsb/why-build-from-source.rst
index eefeade..d9cdcff 100644
--- a/user/rsb/why-build-from-source.rst
+++ b/user/rsb/why-build-from-source.rst
@@ -2,6 +2,8 @@
 
 .. Copyright (C) 2012, 2016 Chris Johns 
 
+.. _WhyBuildFromSource:
+
 Why Build from Source?
 ==
 
diff --git a/user/start/host.rst b/user/start/host.rst
index 1437290..23192a5 100644
--- a/user/start/host.rst
+++ b/user/start/host.rst
@@ -5,15 +5,17 @@
 
 .. _QuickStartHost:
 
-Host Computer Setup
-===
+Prepare Your Host Computer
+==
 
 The *host computer* is the thing you use to develop applications.  It runs all
 your tools, editors, documentation viewers, etc.  To get started with RTEMS
-development you need other tools.  This includes a native C, C++ and Python
-development environment.  Please make sure that you can build native C/C++
-applications on your host computer.  You must be able to build native Python C
-modules.  Usually you have to install a Python development package for this.
-Please have a look at the :ref:`Host Computer ` chapter for the
-glory details.  In particular :ref:`Microsoft Windows ` user
-should do this.
+development you need other tools to build the RTEMS tool suite from source.
+This is not a one-click installation process, but there are
+:ref:`good reasons ` to build everything from source. You
+need a native C, C++ and Python development environment.  Please make sure that
+you can build native C/C++ applications on your host computer.  You must be
+able to build native Python C modules.  Usually, you have to install a Python
+development package for this.  Please have a look at the
+:ref:`Host Computer ` chapter for the glory details.  In
+particular :ref:`Microsoft Windows ` user should do this.
-- 
2.16.4

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


[PATCH 04/10] user: Add "Obtain the Sources" section

2019-01-24 Thread Sebastian Huber
---
 user/start/index.rst   |  1 +
 user/start/sources.rst | 51 ++
 2 files changed, 52 insertions(+)
 create mode 100644 user/start/sources.rst

diff --git a/user/start/index.rst b/user/start/index.rst
index 96388f2..d5f21e7 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -18,6 +18,7 @@ applications on top of RTEMS.
 
 host
 prefixes
+sources
 
 The following is a quick start guide that provides a basic set of commands to
 build the RTEMS Tools and Kernel. The quick start guide provides links to the
diff --git a/user/start/sources.rst b/user/start/sources.rst
new file mode 100644
index 000..6fee109
--- /dev/null
+++ b/user/start/sources.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartSources:
+
+Obtain the Sources
+==
+
+You chose an installation prefix previous section.  We chose
+:file:`$HOME/quick-start/rtems/5` as the installation prefix.
+
+You need at least two source archives or Git repositories to work with RTEMS.
+You can download the source archives for a released RTEMS version or you can
+clone Git repositories to get all versions of RTEMS including the development
+head.
+
+We will clone the Git repositories into :file:`$HOME/quick-start/src`.
+
+.. code-block:: none
+
+mkdir -p $HOME/quick-start/src
+cd $HOME/quick-start/src
+git clone https://github.com/RTEMS/rtems-source-builder.git rsb
+git clone https://github.com/RTEMS/rtems.git
+
+The :file:`rsb` repository clone contains the
+:ref:`RTEMS Source Builder (RSB) `.  We clone it into
+:file:`rsb` to get shorter paths during the tool suite build.  The
+:file:`rtems` repository clone contains the RTEMS sources.  These two
+repositories are enough to get started.  There are
+`more repositories `_ available.
+
+Alternatively, you can download the source archives of a released RTEMS
+version.
+
+.. code-block:: none
+
+mkdir -p $HOME/quick-start/src
+cd $HOME/quick-start/src
+curl 
https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3.tar.xz | tar 
xJf -
+curl 
https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-source-builder-4.11.3.tar.xz
 | tar xJf -
+
+This quick start chapter focuses on working with the Git repository clones
+since this gives you some flexibility.  You can switch between branches to try
+out different RTEMS versions.  You have access to the RTEMS source history.
+The RTEMS Project welcomes contributions.  The Git repositories enable you to
+easily create patches and track local changes.  If you prefer to work with
+archives of a released RTEMS version, then simply replace the version number 5
+used throughout this chapter with the version number you selected, e.g. 4.11.
-- 
2.16.4

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


[PATCH 03/10] user: Rework Prefixes section

2019-01-24 Thread Sebastian Huber
Rename it to "Choose an Installation Prefix".

Update #3675.
---
 user/hosts/posix.rst |  2 +-
 user/installation/project-sandboxing.rst |  2 +-
 user/start/index.rst |  2 +-
 user/start/prefixes.rst  | 74 
 user/tools/index.rst |  2 +
 5 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 365194e..063ebe2 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -35,7 +35,7 @@ machine. If the machine is a centralised build server the 
prefix may be used to
 separate production versions from the test versions and the prefix paths may
 have restricted access rights to only those who manage and have configuration
 control of the machine. We call this project sandboxing and
-:ref:`project-sandboxing` explains this in more detail.
+:ref:`ProjectSandboxing` explains this in more detail.
 
 Linux
 -
diff --git a/user/installation/project-sandboxing.rst 
b/user/installation/project-sandboxing.rst
index 6c90926..248a136 100644
--- a/user/installation/project-sandboxing.rst
+++ b/user/installation/project-sandboxing.rst
@@ -2,7 +2,7 @@
 
 .. Copyright (C) 2016 Chris Johns 
 
-.. _project-sandboxing:
+.. _ProjectSandboxing:
 
 Project Sandboxing
 --
diff --git a/user/start/index.rst b/user/start/index.rst
index d4b6cf2..96388f2 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -57,7 +57,7 @@ place you have suitable storage. Another is permissions.  
There is no
 need to become root or the administrator and we recommend you avoid
 doing this. You can build and install the tools anywhere on the host's
 file system you, as a standard user, have read and write access too.
-:ref:`Prefixes` and :ref:`project-sandboxing` provide detailed examples
+:ref:`Prefixes` and :ref:`ProjectSandboxing` provide detailed examples
 of possible locations and set ups.
 
 Simple Example
diff --git a/user/start/prefixes.rst b/user/start/prefixes.rst
index 87e76a1..e543f7d 100644
--- a/user/start/prefixes.rst
+++ b/user/start/prefixes.rst
@@ -1,48 +1,46 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
 .. Copyright (C) 2016 Chris Johns 
 
 .. _QuickStartPrefixes:
 
-Prefixes
-
+Choose an Installation Prefix
+=
 
 .. index:: prefix
 
-You will see the term :ref:term:`prefix` referred to thoughout this
+You will see the term :ref:term:`prefix` referred to throughout this
 documentation and in a wide number of software packages you can download from
-the internet. A **prefix** is the path on your computer a software package is
-built and installed under. Packages that have a **prefix** will place all parts
-under the **prefix** path. On a host computer like Linux the packages you
-install from your distribution typically use a platform specific standard
-**prefix**. For example on Linux it is :file:`/usr` and on FreeBSD it is
-:file:`/usr/local`.
-
-We recommend you *DO NOT* use the standard **prefix** when installing the RTEMS
-Tools. The standard **prefix** is the default **prefix** each package built by
-the RSB contains. If you are building the tools when logged in as a *Standard
-User* and not as the *Super User* (``root``) or *Administrator* the RTEMS
-Source Builder (RSB) *will* fail and report an error if the default **prefix**
-is not writable. We recommend you leave the standand **prefix** for the
-packages your operating system installs or software you manually install such
-as applications.
-
-A further reason not to use the standard **prefix** is to allow more than one
-version of RTEMS to exist on your host machine at a time. The ``autoconf`` and
-``automake`` tools required by RTEMS are not versioned and vary between the
-various versions of RTEMS. If you use a single **prefix** such as the standard
-**prefix** there is a chance parts from a package of different versions may
-interact. This should not happen but it can.
-
-For POSIX or Unix hosts, the RTEMS Project uses :file:`/opt/rtems` as it's
-standard **prefix**. We view this **prefix** as a production level path, and we
-prefer to place development versions under a different **prefix** away from the
-production versions. Under this top level **prefix** we place the various
-versions we need for development. For example the version 4.11.0 **prefix**
-would be :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the
-**prefix** would be :file:`/opt/rtems/4.11.1`. These are recommendations and
-the choice of what you use is entirely yours. You may decide to have a single
-path for all RTEMS 4.11 releases of :file:`/opt/rtems/4.11`.
-
-For Windows a typical **prefix** is :file:`C:\\opt\\rtems` and as an MSYS2 path
-this is :file:`/c/opt/rtems`.
+the internet.  It is also used in the
+`GNU Coding Standard 


[PATCH 08/10] user: Add "Test a Board Support Package (BSP)"

2019-01-24 Thread Sebastian Huber
---
 user/start/bsp-test.rst | 66 +
 user/start/index.rst|  1 +
 user/testing/index.rst  |  2 ++
 3 files changed, 69 insertions(+)
 create mode 100644 user/start/bsp-test.rst

diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
new file mode 100644
index 000..5278375
--- /dev/null
+++ b/user/start/bsp-test.rst
@@ -0,0 +1,66 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartBSPTest:
+
+Test a Board Support Package (BSP)
+==
+
+You built a BSP with tests in the previous section.  We built the ``erc32`` BSP
+in :file:`$HOME/quick-start/build/b-erc32`.
+
+You should run the RTEMS test suite on your target hardware.  The RTEMS Project
+provides some support to do this, see the :ref:`Testing ` chapter for
+the details.
+
+On the ``erc32`` BSP we selected for this quick start chapter this is easy.
+Just run this command:
+
+.. code-block:: none
+
+cd $HOME/quick-start/build/b-erc32
+rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5 .
+
+This command should output something like this (omitted lines are denoted by
+...).  In this output the base directory :file:`$HOME/quick-start` was replaced
+by ``$BASE``.
+
+.. code-block:: none
+
+RTEMS Testing - Tester, 5.0.not_released
+ Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32 
--rtems-tools=$BASE/rtems/5 .
+ Python: 2.7.15 (default, Jan 10 2019, 01:14:47) [GCC 4.2.1 Compatible 
FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
+Host: FreeBSD-12.0-RELEASE-p2-amd64-64bit-ELF (FreeBSD Build_FreeBSD12 
12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC amd64 amd64)
+[  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: dhrystone.exe
+...
+[589/589] p:574 f:0   u:5   e:0   I:0   B:3   t:0   i:0   W:0   | 
sparc/erc32: tmtimer01.exe
+
+Passed:580
+Failed:  0
+User Input:  5
+Expected Fail:   0
+Indeterminate:   0
+Benchmark:   3
+Timeout: 1
+Invalid: 0
+Wrong Version:   0
+Wrong Build: 0
+Wrong Tools: 0
+--
+Total: 589
+User Input:
+ monitor.exe
+ termios.exe
+ top.exe
+ fileio.exe
+ capture.exe
+Benchmark:
+ whetstone.exe
+ linpack.exe
+ dhrystone.exe
+Timeouts:
+ pppd.exe
+Average test time: 0:00:00.437773
+Testing time : 0:04:17.848557
diff --git a/user/start/index.rst b/user/start/index.rst
index 00a3644..a9c9a6a 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -22,6 +22,7 @@ applications on top of RTEMS.
 tools
 bootstrap
 bsp-build
+bsp-test
 
 The following is a quick start guide that provides a basic set of commands to
 build the RTEMS Tools and Kernel. The quick start guide provides links to the
diff --git a/user/testing/index.rst b/user/testing/index.rst
index 4596339..7eefff1 100644
--- a/user/testing/index.rst
+++ b/user/testing/index.rst
@@ -2,6 +2,8 @@
 
 .. Copyright (C) 2018 Chris Johns 
 
+.. _Testing:
+
 Testing
 ***
 
-- 
2.16.4

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


[PATCH 09/10] user: Add "Build Your Application"

2019-01-24 Thread Sebastian Huber
---
 user/start/app.rst   | 11 +++
 user/start/index.rst |  1 +
 2 files changed, 12 insertions(+)
 create mode 100644 user/start/app.rst

diff --git a/user/start/app.rst b/user/start/app.rst
new file mode 100644
index 000..fdf6bb7
--- /dev/null
+++ b/user/start/app.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartAPP:
+
+Build Your Application
+==
+
+TODO
diff --git a/user/start/index.rst b/user/start/index.rst
index a9c9a6a..e7ce133 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -23,6 +23,7 @@ applications on top of RTEMS.
 bootstrap
 bsp-build
 bsp-test
+app
 
 The following is a quick start guide that provides a basic set of commands to
 build the RTEMS Tools and Kernel. The quick start guide provides links to the
-- 
2.16.4

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


[PATCH 02/10] user: Fix references to prefixes section

2019-01-24 Thread Sebastian Huber
---
 user/hosts/macos.rst | 2 +-
 user/hosts/posix.rst | 2 +-
 user/installation/project-sandboxing.rst | 3 ---
 user/installation/releases.rst   | 4 ++--
 user/start/prefixes.rst  | 5 +++--
 5 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/user/hosts/macos.rst b/user/hosts/macos.rst
index ecc2617..c68e627 100644
--- a/user/hosts/macos.rst
+++ b/user/hosts/macos.rst
@@ -17,7 +17,7 @@ The normal prefix when working on OS X as a user is under 
your home directory.
 Prefixes of :file:`$HOME/development/rtems` or :file:`$HOME/rtems` are
 suitable.
 
-:ref:`prefixes` details using Prefixes to manage the installation.
+:ref:`QuickStartPrefixes` details using Prefixes to manage the installation.
 
 MacOS
 .. _Mavericks:
diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 38f4b30..365194e 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -22,7 +22,7 @@ directory. You could use a prefix of 
:file:`$HOME/development/rtems` or
 :file:`$HOME/rtems`. Note, the ``$HOME`` environment variable can be
 substituted with ``~``.
 
-:ref:`prefixes` details using Prefixes to manage the installation.
+:ref:`QuickStartPrefixes` details using Prefixes to manage the installation.
 
 RTEMS Tools and packages do not require ``root`` access
 to be built and we encourage you to not build the tools as ``root``. If you
diff --git a/user/installation/project-sandboxing.rst 
b/user/installation/project-sandboxing.rst
index 2c5e508..6c90926 100644
--- a/user/installation/project-sandboxing.rst
+++ b/user/installation/project-sandboxing.rst
@@ -2,9 +2,6 @@
 
 .. Copyright (C) 2016 Chris Johns 
 
-.. index:: Prefixes
-.. _prefixes:
-
 .. _project-sandboxing:
 
 Project Sandboxing
diff --git a/user/installation/releases.rst b/user/installation/releases.rst
index 17d4e04..10ef30e 100644
--- a/user/installation/releases.rst
+++ b/user/installation/releases.rst
@@ -27,8 +27,8 @@ use a home directory, If building on Windows use 
:file:`/c/opt/rtems` to keep
 the top level paths as short as possible. :ref:`windows-path-length` provides
 more detail about path lengths on Windows.
 
-The location used to install the tools and kernel is called the
-`prefix`. :ref:`prefixes` explains prefixes and how to use them. It is best to
+The location used to install the tools and kernel is called the `prefix`.
+:ref:`QuickStartPrefixes` explains prefixes and how to use them. It is best to
 have a `prefix` for each different version of RTEMS you are using. If you are
 using RTEMS 4.11 in production it is **not** a good idea to install a
 development version of 5 over the top by using the same `prefix` as the 4.11
diff --git a/user/start/prefixes.rst b/user/start/prefixes.rst
index e9dad29..87e76a1 100644
--- a/user/start/prefixes.rst
+++ b/user/start/prefixes.rst
@@ -2,12 +2,13 @@
 
 .. Copyright (C) 2016 Chris Johns 
 
-.. index:: prefix
-.. _prefixes:
+.. _QuickStartPrefixes:
 
 Prefixes
 
 
+.. index:: prefix
+
 You will see the term :ref:term:`prefix` referred to thoughout this
 documentation and in a wide number of software packages you can download from
 the internet. A **prefix** is the path on your computer a software package is
-- 
2.16.4

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


[PATCH 07/10] user: Add "Build a Board Support Package (BSP)"

2019-01-24 Thread Sebastian Huber
---
 user/start/bsp-build.rst | 146 +++
 user/start/index.rst |   1 +
 2 files changed, 147 insertions(+)
 create mode 100644 user/start/bsp-build.rst

diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
new file mode 100644
index 000..3b9eb15
--- /dev/null
+++ b/user/start/bsp-build.rst
@@ -0,0 +1,146 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartBSPBuild:
+
+Build a Board Support Package (BSP)
+===
+
+You installed the tool suite in your installation prefix, cloned two RTEMS
+repositories and bootstrapped the RTEMS sources in the previous sections.  We
+installed the tool suite in :file:`$HOME/quick-start/rtems/5` and cloned the
+repositories in :file:`$HOME/quick-start/src`.  We also bootstrapped the RTEMS
+sources.
+
+You are now able to build :ref:`Board Support Packages (BSPs) ` for all
+architectures where you have an RTEMS tool suite installed.  To build
+applications on top of RTEMS, you have to configure, build and install a BSP
+for your target hardware.  To select a proper BSP for your target hardware
+consult the :ref:`BSPs ` chapter.  We select the `erc32` BSP.
+
+We configure, build and install the BSP in four steps.  The first step is to
+create a build directory.  It must be separate from the RTEMS source directory.
+We use :file:`$HOME/quick-start/build/b-erc32`.
+
+.. code-block:: none
+
+mkdir -p $HOME/quick-start/build/b-erc32
+
+The second step is to configure the BSP.  There are various configuration
+options available.  Some configuration options are BSP-specific.  Prepend the
+RTEMS tool suite binary directory to your ``$PATH`` throughout the remaining
+steps.
+
+.. code-block:: none
+
+cd $HOME/quick-start/build/b-erc32
+export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
+$HOME/quick-start/src/rtems/configure \
+--prefix=$HOME/quick-start/rtems/5 \
+--enable-maintainer-mode \
+--target=sparc-rtems5 \
+--enable-rtemsbsp=erc32 \
+--enable-tests
+
+This command should output something like this (omitted lines are denoted by
+...):
+
+.. code-block:: none
+
+checking for gmake... gmake
+checking for RTEMS Version... 5.0.0
+checking build system type... x86_64-unknown-freebsd12.0
+checking host system type... x86_64-unknown-freebsd12.0
+checking target system type... sparc-unknown-rtems5
+...
+config.status: creating Makefile
+
+target architecture: sparc.
+available BSPs: erc32.
+'gmake all' will build the following BSPs: erc32.
+other BSPs can be built with 'gmake RTEMS_BSP="bsp1 bsp2 ..."'
+
+config.status: creating Makefile
+
+Building the BSP is the third step.
+
+.. code-block:: none
+
+cd $HOME/quick-start/build/b-erc32
+make
+
+This command should output something like this (omitted lines are denoted by
+...).  In this output the base directory :file:`$HOME/quick-start` was replaced
+by ``$BASE``.
+
+.. code-block:: none
+
+Configuring RTEMS_BSP=erc32
+checking for gmake... gmake
+checking build system type... x86_64-unknown-freebsd12.0
+checking host system type... sparc-unknown-rtems5
+checking rtems target cpu... sparc
+checking for a BSD-compatible install... /usr/bin/install -c
+checking whether build environment is sane... yes
+checking for sparc-rtems5-strip... sparc-rtems5-strip
+checking for a thread-safe mkdir -p... 
$BASE/src/rtems/c/src/../../install-sh -c -d
+checking for gawk... no
+checking for mawk... no
+checking for nawk... nawk
+checking whether gmake sets $(MAKE)... yes
+checking whether to enable maintainer-specific portions of Makefiles... yes
+checking for RTEMS_BSP... erc32
+checking whether CPU supports libposix... yes
+configure: setting up make/custom
+configure: creating make/erc32.cache
+gmake[3]: Entering directory '$BASE/build/b-erc32/sparc-rtems5/c/erc32'
+...
+sparc-rtems5-gcc  -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections 
-Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes 
-Wnested-externs -B./../../lib/libbsp/sparc/erc32 
-B$BASE/src/rtems/bsps/sparc/erc32/start -specs bsp_specs -qrtems 
-L./../../cpukit -L$BASE/src/rtems/bsps/sparc/shared/start -Wl,--wrap=printf 
-Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections -o spwkspace.exe 
spwkspace/spwkspace-init.o ./../../lib/libbsp/sparc/erc32/librtemsbsp.a 
./../../cpukit/librtemscpu.a 
+gmake[5]: Leaving directory 
'$BASE/build/b-erc32/sparc-rtems5/c/erc32/testsuites/sptests'
+gmake[4]: Leaving directory 
'$BASE/build/b-erc32/sparc-rtems5/c/erc32/testsuites'
+gmake[3]: Leaving directory '$BASE/build/b-erc32/sparc-rtems5/c/erc32'
+gmake[2]: Leaving directory '$BASE/build/b-erc32/sparc-rtems5/c/erc32'
+gmake[1]: Leaving directory '$BASE/build/b-erc32/s

[PATCH 10/10] user: Remove obsolete content in quick start

2019-01-24 Thread Sebastian Huber
---
 user/start/index.rst | 87 
 1 file changed, 87 deletions(-)

diff --git a/user/start/index.rst b/user/start/index.rst
index e7ce133..d5aa1be 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -24,90 +24,3 @@ applications on top of RTEMS.
 bsp-build
 bsp-test
 app
-
-The following is a quick start guide that provides a basic set of commands to
-build the RTEMS Tools and Kernel. The quick start guide provides links to the
-detailed sections if any problems are encountered.
-
-The detailed procedure for installing an RTEMS Workspace and installing
-all tools can be found in :ref:`installation`. This includes information
-on installation points, developer versions, and the RTEMS kernel.
-
-The short version of this procedure is as follows
-(:ref:`posix-host-tools-chain`):
-
-#. Create a workspace (:ref:`installation`),
-
-#. Download the RTEMS Source Builder (RSB),
-
-#. Build an RTEMS tool chain for a specific target architecture,
-
-#. Download RTEMS, and then
-
-#. Build RTEMS for a specific Board Support Package (BSP).
-
-Each of these steps is described in a section in this guide.
-
-Creating a Workspace
-
-
-Before beginning, the development host computer needs to be set up for
-this quick start procedure to complete successfully. :ref:`host-computer`
-details what is needed for the supported host operating systems. If
-Windows is being used it is recommended following the procedure in
-:ref:`microsoft-windows` first.
-
-There are many ways and locations a suitable environment can be set up. A
-common factor that defines the final location of tools and projects is the
-place you have suitable storage. Another is permissions.  There is no
-need to become root or the administrator and we recommend you avoid
-doing this. You can build and install the tools anywhere on the host's
-file system you, as a standard user, have read and write access too.
-:ref:`Prefixes` and :ref:`ProjectSandboxing` provide detailed examples
-of possible locations and set ups.
-
-Simple Example
-==
-
-.. code-block:: shell
-
-  $ cd
-  $ mkdir -p development/rtems
-  $ cd development/rtems
-  $ git clone git://git.rtems.org/rtems-source-builder.git rsb
-...
-  $ cd rsb
-  $ ./source-builder/sb-check
-...
-  $ cd rtems
-  $ ../source-builder/sb-set-builder \
-  --prefix=/usr/home/chris/development/rtems/5 5/rtems-sparc
-...
-
-Build the RTEMS Kernel (:ref:`rtems-kernel-install`) by cloning the repository,
-running the ``bootstrap`` procecure, building and finally installing the
-kernel:
-
-.. code-block:: shell
-
-  $ export PATH=$HOME/development/rtems/5/bin:$PATH
-  $ cd
-  $ cd development/rtems
-  $ mkdir kernel
-  $ cd kernel
-  $ git clone git://git.rtems.org/rtems.git rtems
-...
-  $ cd rtems
-  $ ./bootstrap -c && $HOME/development/rtems/rsb/source-builder/sb-bootstrap
-...
-  $ cd ..
-  $ mkdir erc32
-  $ cd erc32
-  $ $HOME/development/rtems/kernel/rtems/configure 
--prefix=$HOME/development/rtems/5 \
- --target=sparc-rtems5 --enable-rtemsbsp=erc32 
--enable-posix
-...
-  $ make -j 8
-...
-  $ make install
-
-You can now build a third-party library or an application.
-- 
2.16.4

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


[PATCH 05/10] user: Add "Install the Tool Suite" section

2019-01-24 Thread Sebastian Huber
---
 user/hardware/architectures.rst |   3 +
 user/start/index.rst|   1 +
 user/start/tools.rst| 126 
 3 files changed, 130 insertions(+)
 create mode 100644 user/start/tools.rst

diff --git a/user/hardware/architectures.rst b/user/hardware/architectures.rst
index 5328db8..761258f 100644
--- a/user/hardware/architectures.rst
+++ b/user/hardware/architectures.rst
@@ -4,8 +4,11 @@
 .. Copyright (C) 2019 Sebastian Huber
 .. Copyright (C) 2016 Chris Johns 
 
+.. _TargetArchitectures:
+
 Architectures
 =
+
 .. index:: Architectures
 
 An RTEMS architecture is a class or family of a processor architecture that
diff --git a/user/start/index.rst b/user/start/index.rst
index d5f21e7..2bee850 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -19,6 +19,7 @@ applications on top of RTEMS.
 host
 prefixes
 sources
+tools
 
 The following is a quick start guide that provides a basic set of commands to
 build the RTEMS Tools and Kernel. The quick start guide provides links to the
diff --git a/user/start/tools.rst b/user/start/tools.rst
new file mode 100644
index 000..1be229a
--- /dev/null
+++ b/user/start/tools.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartTools:
+
+Install the Tool Suite
+==
+
+You chose an installation prefix and cloned two RTEMS repositories in the
+previous sections.  We chose :file:`$HOME/quick-start/rtems/5` as the
+installation prefix and cloned the repositories in
+:file:`$HOME/quick-start/src`.
+
+You must select the
+:ref:`target architecture ` for which you need a tool
+suite.  In this quick start chapter we choose `sparc-rtems5`.  The
+`sparc-rtems5` is the tool suite name for the SPARC architecture and RTEMS
+version 5.  The tool suite for RTEMS and the RTEMS sources are tightly coupled.
+For example, do not use a RTEMS version 5 tool suite with RTEMS version 4.11
+sources and vice versa.  We use the RSB in two steps.  The first step is to
+download additional sources and patches.  Afterwards, you could disconnect your
+host computer from the internet.  It is no longer required to work with RTEMS.
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rsb/rtems
+../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
+
+This command should output something like this (omitted lines are denoted by
+...):
+
+.. code-block:: none
+
+RTEMS Source Builder - Set Builder, 5 (f07504d27192)
+warning: exe: absolute exe found in path: (__unzip) /usr/local/bin/unzip
+Build Set: 5/rtems-sparc
+...
+download: https://ftp.gnu.org/gnu/gcc/gcc-7.4.0/gcc-7.4.0.tar.xz -> 
sources/gcc-7.4.0.tar.xz
+...
+Build Sizes: usage: 0.000B total: 140.576MB (sources: 140.230MB, patches: 
353.696KB, installed 0.000B)
+Build Set: Time 0:02:24.309020
+
+If you encounter errors in the first step, check your internet connection,
+firewall settings, virus scanners and the availability of the download servers.
+The seconds step is to build and install the tool suite.
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rsb/rtems
+../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 
5/rtems-sparc
+
+This command should output something like this (omitted lines are denoted by
+...):
+
+.. code-block:: none
+
+RTEMS Source Builder - Set Builder, 5 (f07504d27192)
+warning: exe: absolute exe found in path: (__unzip) /usr/local/bin/unzip
+Build Set: 5/rtems-sparc
+...
+config: 
tools/rtems-gcc-7.4.0-newlib-dc6e94551f09d3a983afd571478d63a09d6f66fa.cfg
+package: 
sparc-rtems5-gcc-7.4.0-newlib-dc6e94551f09d3a983afd571478d63a09d6f66fa-x86_64-freebsd12.0-1
+building: 
sparc-rtems5-gcc-7.4.0-newlib-dc6e94551f09d3a983afd571478d63a09d6f66fa-x86_64-freebsd12.0-1
+sizes: 
sparc-rtems5-gcc-7.4.0-newlib-dc6e94551f09d3a983afd571478d63a09d6f66fa-x86_64-freebsd12.0-1:
 4.714GB (installed: 890.736MB)
+cleaning: 
sparc-rtems5-gcc-7.4.0-newlib-dc6e94551f09d3a983afd571478d63a09d6f66fa-x86_64-freebsd12.0-1
+...
+Build Sizes: usage: 5.692GB total: 1.116GB (sources: 140.230MB, patches: 
353.696KB, installed 1001.778MB)
+Build Set: Time 0:22:00.360146
+
+In case the seconds step was successful, you can check if for example the cross
+C compiler works with the following command:
+
+.. code-block:: none
+
+$HOME/quick-start/rtems/5/bin/sparc-rtems5-gcc --version --verbose
+
+This command should output something like below.  In this output the actual
+prefix path was replaced by ``$PREFIX``.  The ``compiled by`` line depends on
+the native C++ compiler of your host computer.  In the output you see the Git
+hash of the RSB.  This helps you to identify the exact sources which were used
+to build the cross compiler of your RTEMS tool suite.
+
+.. code-block:: none
+
+Using built-in specs.
+  

[PATCH 06/10] user: Add "Bootstrap the RTEMS Sources"

2019-01-24 Thread Sebastian Huber
---
 user/start/bootstrap.rst | 55 
 user/start/index.rst |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 user/start/bootstrap.rst

diff --git a/user/start/bootstrap.rst b/user/start/bootstrap.rst
new file mode 100644
index 000..9fcf79b
--- /dev/null
+++ b/user/start/bootstrap.rst
@@ -0,0 +1,55 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+
+.. _QuickStartBootstrap:
+
+Bootstrap the RTEMS Sources
+===
+
+You installed the tool suite in your installation prefix and cloned two RTEMS
+repositories in the previous sections.  We installed the tool suite in
+:file:`$HOME/quick-start/rtems/5` and cloned the repositories in
+:file:`$HOME/quick-start/src`.
+
+If you use source archives of a released RTEMS version, then you can skip this
+section.
+
+Before you can build a :ref:`Board Support Package (BSP) ` for your
+target hardware, you have to bootstrap the build system in the RTEMS sources.
+This is only necessary, if you use a Git repository clone of the RTEMS sources.
+You have to do this after a fresh repository clone and sometimes after build
+system file updates (e.g.  after a ``git pull``).  If you are not a build
+system expert, then do the bootstrap after each update of build system files.
+This is a bit annoying, but improving the build system is a complex and time
+consuming undertaking.  Feel free to help the RTEMS Project to improve it.  For
+the bootstrap it is important that the right version of Autotools
+(:file:`autoconf` and :file:`automake`) are in your ``$PATH``.  The right
+version of Autotools is shipped with the RTEMS tool suite you already
+installed.
+
+.. code-block:: none
+
+cd $HOME/quick-start/src/rtems
+export PATH=$HOME/quick-start/rtems/5/bin:"$PATH"
+./bootstrap -c
+$HOME/quick-start/src/rsb/source-builder/sb-bootstrap
+
+These commands should output something like this (omitted lines are denoted by
+...):
+
+.. code-block:: none
+
+removing automake generated Makefile.in files
+removing configure files
+removing aclocal.m4 files
+$ $HOME/quick-start/src/rsb/source-builder/sb-bootstrap
+RTEMS Source Builder - RTEMS Bootstrap, 5 (f07504d27192)
+  1/120: autoreconf: configure.ac
+  2/120: autoreconf: c/configure.ac
+  3/120: autoreconf: c/src/configure.ac
+  4/120: autoreconf: c/src/lib/libbsp/arm/configure.ac
+...
+120/120: autoreconf: testsuites/tmtests/configure.ac
+Bootstrap time: 0:00:48.744222
diff --git a/user/start/index.rst b/user/start/index.rst
index 2bee850..c4bb1ed 100644
--- a/user/start/index.rst
+++ b/user/start/index.rst
@@ -20,6 +20,7 @@ applications on top of RTEMS.
 prefixes
 sources
 tools
+bootstrap
 
 The following is a quick start guide that provides a basic set of commands to
 build the RTEMS Tools and Kernel. The quick start guide provides links to the
-- 
2.16.4

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


Re: SIS with coverage support

2019-01-24 Thread Jiri Gaisler

On 1/24/19 9:33 AM, Jiri Gaisler wrote:
>
> On 1/24/19 12:45 AM, Joel Sherrill wrote:
>>
>>
>> On Wed, Jan 23, 2019 at 4:45 PM Chris Johns > > wrote:
>>
>> On 24/1/19 9:12 am, Jiri Gaisler wrote:
>> > After some trial and error, I got covoar to run with:
>>
>> Great.
>>
>> > However, the coverage is always 0% in the summary report:
>>
>> Does adding -v to the command line provide any more detail? Repeating -v
>> increases the level but things can become rather verbose and if you trip 
>> full
>> DWARF tracing there is a lot of output.
>>
>>
>> I would be suspicious of the code that is invoked around
>> CoverageReaderTSIM.cc:83 as a starting point. For some method you
>> know you should be analyzed, there should be aCoverageMap. Since you
>> are looking at only one executable, you could hard-code a test with
>> address range of a single method under test to see what happens.
>>
>
> Well, the problem is that covoar in rtems-tools is hard-coded to use the QEMU 
> format, and the -f switch to change format is not used. I have attached a 
> patch to fix that. After that, covoar works fine with the coverage data from 
> sis:
>
> cat coverage/summary.txt
> Bytes Analyzed   : 20034
> Bytes Not Executed   : 11734
> Percentage Executed  : 41.43
> Percentage Not Executed  : 58.57
> Uncovered ranges found   : 242
> Total branches found : 443
> Uncovered branches found : 167
>    68 branches always taken
>    99 branches never taken
>
> If you approve to the patch, then I will check it in (now that I know how ... 
> :-))
>
Here is a better patch that maintains the old behavior of QEMU as default, 
while honoring the -f switch if provided.

Jiri.

diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 36c24c3..cbb0e4f 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -163,7 +163,7 @@ int covoar(
   char  gcdaFileName[FILE_NAME_LENGTH];
   char  gcovBashCommand[256];
   std::string   target;
-  const char*   format = "html";
+  const char*   format = "QEMU";
   FILE* gcnosFile = NULL;
   Gcov::GcovData*   gcovFile;
   const char*   singleExecutable = NULL;
@@ -359,6 +359,7 @@ int covoar(
 AllExplanations->load( explanations );
 
   // Create coverage map reader.
+  coverageFormat = Coverage::CoverageFormatToEnum(format);
   coverageReader = Coverage::CreateCoverageReader(coverageFormat);
   if (!coverageReader)
 throw rld::error( "Unable to create coverage file reader", "covoar" );
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Do we really want to install the tests during a BSP install?

2019-01-24 Thread Chris Johns
On 24/1/19 6:58 pm, Sebastian Huber wrote:
> I rework currently the quick start chapter of the user manual. I think we 
> should
> recommend to build the tests for a BSP and run them. To build applications on
> top of RTEMS you have to install the BSP. If you build the BSP with
> --enable-tests, then the test executables are installed. This requires a lot 
> of
> storage space:
> 
> du -sh erc32/
> 2.5G    erc32/
> 
> Compare this without the executables:
> 
> find erc32/ -name '*.exe' | xargs rm
> du -sh erc32/
> 65M erc32/
> 
> Is this really what the normal user wants?

I doubt it is. I never run the tests from the install tree and I have never seen
it documented.

> If you want to archive thinks, then
> you probably also archive the build tree. 

Agreed.

> If the tests are successful, then you
> probably delete the build tree and no longer care about the tests.

If your project deploys a golden RTEMS you may want to have the executables
available to test on hardware as part of a set of conformance tests. In this
case it is not just RTEMS that is being tested it is RTEMS and the hardware or a
new revision of the hardware.

Could a top level Makefile target that packages the .exe files, a sort of tar of
`find . -name \*.exe` work?

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

Re: [PATCH 1/2] user: Spell out third-party

2019-01-24 Thread Chris Johns
On 24/1/19 5:30 pm, Sebastian Huber wrote:
> Yes, this makes sense, but this patch is a spell change.

Sure, it was just something that came up and I though I would let you know.

> I would like to use the wording in Wikepedia
> 
> https://en.wikipedia.org/wiki/Third-party_software_component
> 

As in we use the term 'component' rather than 'package'?

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


Re: [PATCH 1/2] user: Spell out third-party

2019-01-24 Thread Sebastian Huber

On 24/01/2019 10:22, Chris Johns wrote:

On 24/1/19 5:30 pm, Sebastian Huber wrote:

Yes, this makes sense, but this patch is a spell change.

Sure, it was just something that came up and I though I would let you know.


Ok, and is the change ok for you?




I would like to use the wording in Wikepedia

https://en.wikipedia.org/wiki/Third-party_software_component


As in we use the term 'component' rather than 'package'?


At the moment I don't want to have too many balls in the air. I am still 
busy with the quick start chapter and the kernel/executive stuff.


--
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 1/2] user: Spell out third-party

2019-01-24 Thread Chris Johns
On 24/1/19 8:51 pm, Sebastian Huber wrote:
> On 24/01/2019 10:22, Chris Johns wrote:
>> On 24/1/19 5:30 pm, Sebastian Huber wrote:
>>> Yes, this makes sense, but this patch is a spell change.
>> Sure, it was just something that came up and I though I would let you know.
> 
> Ok, and is the change ok for you?
> 

Yes.

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


Re: [PATCH 01/10] user: Rework "Host Computer Setup" section

2019-01-24 Thread Chris Johns



On 24/1/19 7:55 pm, Sebastian Huber wrote:
> Rename it to "Prepare Your Host Computer".
> ---
>  user/rsb/why-build-from-source.rst |  2 ++
>  user/start/host.rst| 20 +++-
>  2 files changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/user/rsb/why-build-from-source.rst 
> b/user/rsb/why-build-from-source.rst
> index eefeade..d9cdcff 100644
> --- a/user/rsb/why-build-from-source.rst
> +++ b/user/rsb/why-build-from-source.rst
> @@ -2,6 +2,8 @@
>  
>  .. Copyright (C) 2012, 2016 Chris Johns 
>  
> +.. _WhyBuildFromSource:
> +
>  Why Build from Source?
>  ==
>  
> diff --git a/user/start/host.rst b/user/start/host.rst
> index 1437290..23192a5 100644
> --- a/user/start/host.rst
> +++ b/user/start/host.rst
> @@ -5,15 +5,17 @@
>  
>  .. _QuickStartHost:
>  
> -Host Computer Setup
> -===
> +Prepare Your Host Computer
> +==
>  
>  The *host computer* is the thing you use to develop applications.  It runs 
> all

I know this is not in your patch but reading the patch this could change ..

 The *host computer* is a computer you use to develop applications.

>  your tools, editors, documentation viewers, etc.  To get started with RTEMS
> -development you need other tools.  This includes a native C, C++ and Python
> -development environment.  Please make sure that you can build native C/C++
> -applications on your host computer.  You must be able to build native Python 
> C
> -modules.  Usually you have to install a Python development package for this.
> -Please have a look at the :ref:`Host Computer ` chapter for 
> the
> -glory details.  In particular :ref:`Microsoft Windows ` 
> user
> -should do this.
> +development you need other tools to build the RTEMS tool suite from source.

What about ..

development you need tools from your host's operating system to build the RTEMS
tool suite from source.

?

> +This is not a one-click installation process, but there are
> +:ref:`good reasons ` to build everything from source. You
> +need a native C, C++ and Python development environment.  Please make sure 
> that
> +you can build native C/C++ applications on your host computer.  You must be
> +able to build native Python C modules.  Usually, you have to install a Python
> +development package for this.  Please have a look at the
> +:ref:`Host Computer ` chapter for the glory details.  In
> +particular :ref:`Microsoft Windows ` user should do this.

Nice.

Chris

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


Re: [PATCH 03/10] user: Rework Prefixes section

2019-01-24 Thread Sebastian Huber

On 24/01/2019 11:47, Chris Johns wrote:

+:file:`/usr/local` on FreeBSD and Linux.
+
+You have to select a prefix for your RTEMS tool suite installation.  The RTEMS
+tool suite consists of a cross tool chain (Binutils, GCC, GDB, Newlib, etc.)
+for your target architecture and :ref:`other tools ` provided by the
+RTEMS Project.  You build and install the tool suite with the
+:ref:`RTEMS Source Builder (RSB) `.  By default, the RSB will use an
+operating system specific part plus :file:`rtems` plus the RTEMS version, e.g.

  Specific part or path?


Ok, it is path, e.g. /usr/local on FreeBSD.

--
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 03/10] user: Rework Prefixes section

2019-01-24 Thread Chris Johns
On 24/1/19 7:55 pm, Sebastian Huber wrote:
> Rename it to "Choose an Installation Prefix".
> 
> Update #3675.
> ---
>  user/hosts/posix.rst |  2 +-
>  user/installation/project-sandboxing.rst |  2 +-
>  user/start/index.rst |  2 +-
>  user/start/prefixes.rst  | 74 
> 
>  user/tools/index.rst |  2 +
>  5 files changed, 41 insertions(+), 41 deletions(-)
> 
> diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
> index 365194e..063ebe2 100644
> --- a/user/hosts/posix.rst
> +++ b/user/hosts/posix.rst
> @@ -35,7 +35,7 @@ machine. If the machine is a centralised build server the 
> prefix may be used to
>  separate production versions from the test versions and the prefix paths may
>  have restricted access rights to only those who manage and have configuration
>  control of the machine. We call this project sandboxing and
> -:ref:`project-sandboxing` explains this in more detail.
> +:ref:`ProjectSandboxing` explains this in more detail.
>  
>  Linux
>  -
> diff --git a/user/installation/project-sandboxing.rst 
> b/user/installation/project-sandboxing.rst
> index 6c90926..248a136 100644
> --- a/user/installation/project-sandboxing.rst
> +++ b/user/installation/project-sandboxing.rst
> @@ -2,7 +2,7 @@
>  
>  .. Copyright (C) 2016 Chris Johns 
>  
> -.. _project-sandboxing:
> +.. _ProjectSandboxing:
>  
>  Project Sandboxing
>  --
> diff --git a/user/start/index.rst b/user/start/index.rst
> index d4b6cf2..96388f2 100644
> --- a/user/start/index.rst
> +++ b/user/start/index.rst
> @@ -57,7 +57,7 @@ place you have suitable storage. Another is permissions.  
> There is no
>  need to become root or the administrator and we recommend you avoid
>  doing this. You can build and install the tools anywhere on the host's
>  file system you, as a standard user, have read and write access too.
> -:ref:`Prefixes` and :ref:`project-sandboxing` provide detailed examples
> +:ref:`Prefixes` and :ref:`ProjectSandboxing` provide detailed examples
>  of possible locations and set ups.
>  
>  Simple Example
> diff --git a/user/start/prefixes.rst b/user/start/prefixes.rst
> index 87e76a1..e543f7d 100644
> --- a/user/start/prefixes.rst
> +++ b/user/start/prefixes.rst
> @@ -1,48 +1,46 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> +.. Copyright (C) 2019 embedded brains GmbH
> +.. Copyright (C) 2019 Sebastian Huber
>  .. Copyright (C) 2016 Chris Johns 
>  
>  .. _QuickStartPrefixes:
>  
> -Prefixes
> -
> +Choose an Installation Prefix
> +=
>  
>  .. index:: prefix
>  
> -You will see the term :ref:term:`prefix` referred to thoughout this
> +You will see the term :ref:term:`prefix` referred to throughout this
>  documentation and in a wide number of software packages you can download from
> -the internet. A **prefix** is the path on your computer a software package is
> -built and installed under. Packages that have a **prefix** will place all 
> parts
> -under the **prefix** path. On a host computer like Linux the packages you
> -install from your distribution typically use a platform specific standard
> -**prefix**. For example on Linux it is :file:`/usr` and on FreeBSD it is
> -:file:`/usr/local`.
> -
> -We recommend you *DO NOT* use the standard **prefix** when installing the 
> RTEMS
> -Tools. The standard **prefix** is the default **prefix** each package built 
> by
> -the RSB contains. If you are building the tools when logged in as a *Standard
> -User* and not as the *Super User* (``root``) or *Administrator* the RTEMS
> -Source Builder (RSB) *will* fail and report an error if the default 
> **prefix**
> -is not writable. We recommend you leave the standand **prefix** for the
> -packages your operating system installs or software you manually install such
> -as applications.
> -
> -A further reason not to use the standard **prefix** is to allow more than one
> -version of RTEMS to exist on your host machine at a time. The ``autoconf`` 
> and
> -``automake`` tools required by RTEMS are not versioned and vary between the
> -various versions of RTEMS. If you use a single **prefix** such as the 
> standard
> -**prefix** there is a chance parts from a package of different versions may
> -interact. This should not happen but it can.
> -
> -For POSIX or Unix hosts, the RTEMS Project uses :file:`/opt/rtems` as it's
> -standard **prefix**. We view this **prefix** as a production level path, and 
> we
> -prefer to place development versions under a different **prefix** away from 
> the
> -production versions. Under this top level **prefix** we place the various
> -versions we need for development. For example the version 4.11.0 **prefix**
> -would be :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released 
> the
> -**prefix** would be :file:`/opt/rtems/4.11.1`. These are recommendations and
> -the choice of what you use is entirely yours. You may decide to have 

Re: [PATCH 03/10] user: Rework Prefixes section

2019-01-24 Thread Chris Johns
On 24/1/19 9:49 pm, Sebastian Huber wrote:
> On 24/01/2019 11:47, Chris Johns wrote:
>>> +:file:`/usr/local` on FreeBSD and Linux.
>>> +
>>> +You have to select a prefix for your RTEMS tool suite installation.  The 
>>> RTEMS
>>> +tool suite consists of a cross tool chain (Binutils, GCC, GDB, Newlib, 
>>> etc.)
>>> +for your target architecture and :ref:`other tools ` provided 
>>> by the
>>> +RTEMS Project.  You build and install the tool suite with the
>>> +:ref:`RTEMS Source Builder (RSB) `.  By default, the RSB will use an
>>> +operating system specific part plus :file:`rtems` plus the RTEMS version, 
>>> e.g.
>>   Specific part or path?
> 
> Ok, it is path, e.g. /usr/local on FreeBSD.
Oh, what about:

 by default, the RSB will start the prefix path with your host's default
 operating system install path plus ...

?

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

Re: [PATCH 04/10] user: Add "Obtain the Sources" section

2019-01-24 Thread Chris Johns



On 24/1/19 7:55 pm, Sebastian Huber wrote:
> ---
>  user/start/index.rst   |  1 +
>  user/start/sources.rst | 51 
> ++
>  2 files changed, 52 insertions(+)
>  create mode 100644 user/start/sources.rst
> 
> diff --git a/user/start/index.rst b/user/start/index.rst
> index 96388f2..d5f21e7 100644
> --- a/user/start/index.rst
> +++ b/user/start/index.rst
> @@ -18,6 +18,7 @@ applications on top of RTEMS.
>  
>  host
>  prefixes
> +sources
>  
>  The following is a quick start guide that provides a basic set of commands to
>  build the RTEMS Tools and Kernel. The quick start guide provides links to the
> diff --git a/user/start/sources.rst b/user/start/sources.rst
> new file mode 100644
> index 000..6fee109
> --- /dev/null
> +++ b/user/start/sources.rst
> @@ -0,0 +1,51 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2019 embedded brains GmbH
> +.. Copyright (C) 2019 Sebastian Huber
> +
> +.. _QuickStartSources:
> +
> +Obtain the Sources
> +==
> +
> +You chose an installation prefix previous section.  We chose
> +:file:`$HOME/quick-start/rtems/5` as the installation prefix.
> +
> +You need at least two source archives or Git repositories to work with RTEMS.
> +You can download the source archives for a released RTEMS version or you can
> +clone Git repositories to get all versions of RTEMS including the development
> +head.
> +
> +We will clone the Git repositories into :file:`$HOME/quick-start/src`.
> +
> +.. code-block:: none
> +
> +mkdir -p $HOME/quick-start/src
> +cd $HOME/quick-start/src
> +git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> +git clone https://github.com/RTEMS/rtems.git

Please do not document github as _the_ way to get the code.

I understand this is an https path which some users need due to corporate
firewalls so maybe provide github as an alternative with an explanation in a
sidebar and explain github is read-only and the projects repos are in the
rtems.org domain.

> +
> +The :file:`rsb` repository clone contains the
> +:ref:`RTEMS Source Builder (RSB) `.  We clone it into
> +:file:`rsb` to get shorter paths during the tool suite build.  The
> +:file:`rtems` repository clone contains the RTEMS sources.  These two
> +repositories are enough to get started.  There are
> +`more repositories `_ available.
> +
> +Alternatively, you can download the source archives of a released RTEMS
> +version.
> +
> +.. code-block:: none
> +
> +mkdir -p $HOME/quick-start/src
> +cd $HOME/quick-start/src
> +curl 
> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-4.11.3.tar.xz | 
> tar xJf -
> +curl 
> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/rtems-source-builder-4.11.3.tar.xz
>  | tar xJf -
> +
> +This quick start chapter focuses on working with the Git repository clones
> +since this gives you some flexibility.  You can switch between branches to 
> try
> +out different RTEMS versions.  You have access to the RTEMS source history.
> +The RTEMS Project welcomes contributions.  The Git repositories enable you to
> +easily create patches and track local changes. 

Using git does not give you are formal version number. This is only provided by
the release tarballs. I think this is worth noting.

> If you prefer to work with
> +archives of a released RTEMS version, then simply replace the version number 
> 5
> +used throughout this chapter with the version number you selected, e.g. 
> 4.11. 

This is looking good so far.

I will continue tomorrow, the tennis is over for the evening.

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


[PATCH] rtems-tools/covoar: -f switch was not used to select coverage format

2019-01-24 Thread Jiri Gaisler
Small patch to fix covoar to work with TSIM coverage files. It should be noted 
that covoar erroneously marks some code as uncovered while it is marked as 
covered in the coverage file. This seems to be due to incorrect parsing of the 
symbol table in the exec file. I will file a ticket for this on trac ..


>From ec0a006871e9b616212d7a4586973715d9e724b5 Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Thu, 24 Jan 2019 09:44:48 +0100
Subject: [PATCH] covoar: -f switch was not used to select coverage format

	* Also fix debug printout of hex addresses
---
 tester/covoar/DesiredSymbols.cc | 1 +
 tester/covoar/covoar.cc | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/DesiredSymbols.cc
index 7def2ce..b9a5bb7 100644
--- a/tester/covoar/DesiredSymbols.cc
+++ b/tester/covoar/DesiredSymbols.cc
@@ -296,6 +296,7 @@ namespace Coverage {
 );
   if (Verbose)
 std::cerr << "Branch never taken found in " << s.first
+  << std::hex
   << " (0x" << s.second.baseAddress + la
   << " - 0x" << s.second.baseAddress + ha
   << ")"
diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 36c24c3..cbb0e4f 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -163,7 +163,7 @@ int covoar(
   char  gcdaFileName[FILE_NAME_LENGTH];
   char  gcovBashCommand[256];
   std::string   target;
-  const char*   format = "html";
+  const char*   format = "QEMU";
   FILE* gcnosFile = NULL;
   Gcov::GcovData*   gcovFile;
   const char*   singleExecutable = NULL;
@@ -359,6 +359,7 @@ int covoar(
 AllExplanations->load( explanations );
 
   // Create coverage map reader.
+  coverageFormat = Coverage::CoverageFormatToEnum(format);
   coverageReader = Coverage::CreateCoverageReader(coverageFormat);
   if (!coverageReader)
 throw rld::error( "Unable to create coverage file reader", "covoar" );
-- 
2.17.1

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

Re: [PATCH] rtems-tools/covoar: -f switch was not used to select coverage format

2019-01-24 Thread Joel Sherrill
On Thu, Jan 24, 2019, 6:38 AM Jiri Gaisler  Small patch to fix covoar to work with TSIM coverage files. It should be
> noted that covoar erroneously marks some code as uncovered while it is
> marked as covered in the coverage file. This seems to be due to incorrect
> parsing of the symbol table in the exec file. I will file a ticket for this
> on trac ..
>

Is this the entry and exit code of a method or something else? The switch
to dwarf info seems to have caused that and not marking assembly from
inlined methods.

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

Xilinx License Acceptable for RTEMS?

2019-01-24 Thread Sebastian Huber

Hello,

some Xilinx drivers use this license:

/**
*
* Copyright (C) 2014 Xilinx, Inc.  All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining 
a copy
* of this software and associated documentation files (the "Software"), 
to deal
* in the Software without restriction, including without limitation the 
rights

* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* Use of the Software is limited solely to applications:
* (a) running on a Xilinx device, or
* (b) that interact with a Xilinx device through a bus or interconnect.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* XILINX  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Except as contained in this notice, the name of the Xilinx shall not 
be used

* in advertising or otherwise to promote the sale, use or other dealings in
* this Software without prior written authorization from Xilinx.
*
**/

It is an open source license, but it is has the following limitations:

"* Use of the Software is limited solely to applications:
* (a) running on a Xilinx device, or
* (b) that interact with a Xilinx device through a bus or interconnect."

This is not a big deal for driver code intended for Xilinx devices. 
Would it be acceptable for the RTEMS repository?


--
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: Xilinx License Acceptable for RTEMS?

2019-01-24 Thread Joel Sherrill
On Thu, Jan 24, 2019 at 8:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> some Xilinx drivers use this license:
>
>
> /**
> *
> * Copyright (C) 2014 Xilinx, Inc.  All rights reserved.
> *
> * Permission is hereby granted, free of charge, to any person obtaining
> a copy
> * of this software and associated documentation files (the "Software"),
> to deal
> * in the Software without restriction, including without limitation the
> rights
> * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> * copies of the Software, and to permit persons to whom the Software is
> * furnished to do so, subject to the following conditions:
> *
> * The above copyright notice and this permission notice shall be included
> in
> * all copies or substantial portions of the Software.
> *
> * Use of the Software is limited solely to applications:
> * (a) running on a Xilinx device, or
> * (b) that interact with a Xilinx device through a bus or interconnect.
> *
> * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR
> * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> * XILINX  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
> * OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> * SOFTWARE.
> *
> * Except as contained in this notice, the name of the Xilinx shall not
> be used
> * in advertising or otherwise to promote the sale, use or other dealings in
> * this Software without prior written authorization from Xilinx.
> *
>
> **/
>
> It is an open source license, but it is has the following limitations:
>
> "* Use of the Software is limited solely to applications:
> * (a) running on a Xilinx device, or
> * (b) that interact with a Xilinx device through a bus or interconnect."
>
> This is not a big deal for driver code intended for Xilinx devices.
> Would it be acceptable for the RTEMS repository?
>

We have never thought that was acceptable in the past. There is code for
Intel
flash and if there were flash chips with the same interface (likely), then
we would
have encouraged license infringement. The overarching argument is whether
inclusion of this code goes against the rule that we are promising users
that
no code imposes an obligation on them.

In this case, my biggest concern is whether this code is truly for things
unique to Xilinx parts or is it for IP modules from ARM and Synopsys.
If for Xilinx specific IP modules, then we can debate that.

If the code if for ARM or Synopsys IP modules, then I am going to
come down firmly on the no side. The SoC we are working with
is a complex integration of IP from ARM, Synopsys and other
IP vendors. If the two parts we are working with share the same
IP module, then RTEMS protocol calls for it to be in shared and
used by both BSPs. We would end up with two copies of the code
with one shareable across BSPs and one locked to the Xilinx.
In this case, we are violating our guiding principle.

--joel

>
> --
> 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] rtems-tools/covoar: -f switch was not used to select coverage format

2019-01-24 Thread Jiri Gaisler

On 1/24/19 2:19 PM, Joel Sherrill wrote:
>
>
> On Thu, Jan 24, 2019, 6:38 AM Jiri Gaisler   wrote:
>
> Small patch to fix covoar to work with TSIM coverage files. It
> should be noted that covoar erroneously marks some code as
> uncovered while it is marked as covered in the coverage file. This
> seems to be due to incorrect parsing of the symbol table in the
> exec file. I will file a ticket for this on trac ..
>
>
> Is this the entry and exit code of a method or something else? The
> switch to dwarf info seems to have caused that and not marking
> assembly from inlined methods.

I notice two problems: the first instruction in a range is sometimes
marked as uncovered:

4000807c <_Freechain_Get>:
  Freechain_Control   *freechain,
  Freechain_Allocator  allocator,
  size_t   number_nodes_to_extend,
  size_t   node_size
)
{
4000807c:   9d e3 bf a0 save  %sp, -96, %sp
   <== NOT EXECUTED
40008080:   ba 10 00 18 mov  %i0, %i5

  return _Chain_Immutable_head( the_chain )->next;

40008084:   f0 06 00 00 ld  [ %i0 ], %i0

even though it is marked as executed in the coverage file. The second
problems is that the size of ranges is sometimes off by one byte, e.g.
21 bytes instead of 20. This can only be seen when debugging covoar in gdb.

I will prepare a patch for sis to add the coverage, and then covoar can
be debugged using our standard tools. Maybe it could be a task for GSoC
...? An additional task could also be to add RISC-V support to covoar,
which is currently missing...


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

Re: [PATCH] rtems-tools/covoar: -f switch was not used to select coverage format

2019-01-24 Thread Joel Sherrill
On Thu, Jan 24, 2019 at 8:46 AM Jiri Gaisler  wrote:

>
> On 1/24/19 2:19 PM, Joel Sherrill wrote:
>
>
>
> On Thu, Jan 24, 2019, 6:38 AM Jiri Gaisler 
>> Small patch to fix covoar to work with TSIM coverage files. It should be
>> noted that covoar erroneously marks some code as uncovered while it is
>> marked as covered in the coverage file. This seems to be due to incorrect
>> parsing of the symbol table in the exec file. I will file a ticket for this
>> on trac ..
>>
>
> Is this the entry and exit code of a method or something else? The switch
> to dwarf info seems to have caused that and not marking assembly from
> inlined methods.
>
> I notice two problems: the first instruction in a range is sometimes
> marked as uncovered:
>
> 4000807c <_Freechain_Get>:
>   Freechain_Control   *freechain,
>   Freechain_Allocator  allocator,
>   size_t   number_nodes_to_extend,
>   size_t   node_size
> )
> {
> 4000807c:   9d e3 bf a0 save  %sp, -96, %sp
><== NOT EXECUTED
> 40008080:   ba 10 00 18 mov  %i0, %i5
>
>   return _Chain_Immutable_head( the_chain )->next;
>
> 40008084:   f0 06 00 00 ld  [ %i0 ], %i0
>
> even though it is marked as executed in the coverage file. The second
> problems is that the size of ranges is sometimes off by one byte, e.g. 21
> bytes instead of 20. This can only be seen when debugging covoar in gdb.
>

I recall that the CoverageReaderTSIM code did an offset of +1 to +4 from
the address. Perhaps it just needs to be 0-3. :)

The off by one on the ranges is something else.


> I will prepare a patch for sis to add the coverage, and then covoar can be
> debugged using our standard tools. Maybe it could be a task for GSoC ...?
> An additional task could also be to add RISC-V support to covoar, which is
> currently missing...
>

Yes on GSoC. Use the keywords "SoC, testing" and it will show up in the
list here:

https://devel.rtems.org/wiki/Developer/OpenProjects

Clearly one bug isn't a GSoC project but if we file tickets for all the
issues, then that's a GSoC project.

RISC-V support would be awesome! I am thrilled you have added support for
it. :)

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