Re: RTEMS Project projects?

2020-02-03 Thread Sebastian Huber 
Hello,

ok, I think we should at least write some words about these projects and give 
some context in the Software Engineering manual, maybe under

https://docs.rtems.org/branches/master/eng/mission.html#

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

[rtems-docs PATCH v2] user/testing: Add coverage analysis instructions

2020-02-03 Thread Vijay Kumar Banerjee 
---
 user/testing/coverage.rst | 68 +++
 user/testing/index.rst|  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 user/testing/coverage.rst

diff --git a/user/testing/coverage.rst b/user/testing/coverage.rst
new file mode 100644
index 000..4f2266e
--- /dev/null
+++ b/user/testing/coverage.rst
@@ -0,0 +1,68 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 Vijay Kumar Banerjee 
+
+Coverage Analysis
+=
+
+RTEMS is used in many critical systems. It is important that the RTEMS Project
+ensure that the RTEMS product is tested as thoroughly as possible. With this
+goal in mind, the RTEMS test suite was expanded with the goal that 100% of the
+RTEMS executive is tested.
+
+RTEMS-TESTER takes the following arguments to produce coverage reports:
+
+`--coverage :`
+When the coverage option is enabled the tester produces coverage reports 
for
+all the symbols in cpukit. To generate a coverage report for a specific
+symbol-set ( e.g.: score) the symbol-set is passed as an argument to the
+option, e.g.: --coverage=score.
+
+`--no-clean :`
+Tells the script not to delete the .cov trace files generated while running
+the coverage. These trace files are used for debugging purposes and will 
not
+be needed for a normal user.
+
+For example: To generate a coverage report of hello.exe for leon3 on SIS, the
+following command is used:
+
+.. code-block:: none
+
+rtems-test \
+--rtems-tools=$HOME/development/rtems/5 \
+--log=coverage_analysis.log \
+--no-clean \
+--coverage \
+--rtems-bsp=leon3-sis-cov \
+
$HOME/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe
+
+The command will create the coverage report in the following tree structure:
+
+.. code-block:: none
+
+├── coverage_analysis.log
+├── leon3-sis-coverage
+│   └── score
+│   ├── annotated.html
+│   ├── annotated.txt
+│   ├── branch.html
+│   ├── branch.txt
+│   ├── covoar.css
+│   ├── ExplanationsNotFound.txt
+│   ├── index.html
+│   ├── no_range_uncovered.html
+│   ├── no_range_uncovered.txt
+│   ├── NotReferenced.html
+│   ├── sizes.html
+│   ├── sizes.txt
+│   ├── summary.txt
+│   ├── symbolSummary.html
+│   ├── symbolSummary.txt
+│   ├── table.js
+│   ├── uncovered.html
+│   └── uncovered.txt
+└── leon3-sis-report.html
+
+The html on top of the directory, i.e., leon3-sis-report.html is the top level
+navigation for the coverage analysis report and will let the user browse 
through
+all the generated reports from different subsystems.
diff --git a/user/testing/index.rst b/user/testing/index.rst
index a938af4..3d36fab 100644
--- a/user/testing/index.rst
+++ b/user/testing/index.rst
@@ -43,6 +43,7 @@ extension.
 
tests
configuration
+   coverage
consoles
simulation
gdb-jtag
-- 
2.21.1

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

[PATCH] dhcpcd: Pass config structure.

2020-02-03 Thread Christian Mauderer 
---
 dhcpcd/dhcpcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dhcpcd/dhcpcd.c b/dhcpcd/dhcpcd.c
index fd6356de..b7839d49 100644
--- a/dhcpcd/dhcpcd.c
+++ b/dhcpcd/dhcpcd.c
@@ -1181,7 +1181,8 @@ rtems_dhcpcd_start(const rtems_dhcpcd_config *config)
if (sc == RTEMS_SUCCESSFUL) {
dhcpcd_initialized = true;
 
-   sc = rtems_task_start(id, dhcpcd_task, 0);
+   sc = rtems_task_start(id, dhcpcd_task,
+   (rtems_task_argument) config);
assert(sc == RTEMS_SUCCESSFUL);
}
} else {
-- 
2.16.4

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

Re: [PATCH] dhcpcd: Pass config structure.

2020-02-03 Thread Sebastian Huber 
Looks good, sorry for this bug.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Pre-Qualification Master Plan

2020-02-03 Thread Sebastian Huber 
Hello,

I will try to present the "master plan" for the RTEMS pre-qualification project
done in the scope of an ESA activity. Since I am not a master in software
qualification activities, this is probably only a novice plan. 

There is a master ticket for this activity here:

https://devel.rtems.org/ticket/3701

We analysed the relevant ECSS standards with respect to software development
(ECSS-E-ST-40C and ECSS-Q-ST-80C Rev.1) and other standards such as IEC 61508,
ISO 26262, DO-178, DO-330, DO-333, and Galileo Software Standard (GSWS). We
also had a look at previous RTEMS pre-qualification projects. We ended up with
roughly the same conclusions as presented in the RTEMS Software Engineering
manual (content probably from Joel Sherill or Scott Zemerick).

https://docs.rtems.org/branches/master/eng/prequalification.html

ECSS-E-ST-40C requires that you deliver about 70 documents. For some documents
the scope, content, formatting, structure, etc. is defined by the standard. For
each document we have a proposal how it can be delivered. Several documents
were discarded since they correspond to project life-cycles which are not
included in the ESA activity, e.g. operational phase, maintenance. RTEMS is
operational and maintained. Some documents are specific to the ESA activity and
have no value for the RTEMS Project, e.g. the Software Development Plan for the
overall ESA activity.

At least the ECSS standards demand from you that the software is developed
according to procedures defined by the standards. ECSS is very detailed here.
Obviously, it makes no sense to apply these clauses to an open source project
one-to-one. What we try to do is document the procedures used by the RTEMS
community, so that an auditor not familiar with RTEMS can get an overview about
the project organization. New contributors may also benefit from this
documentation.

Another big chunk in the standards is how the software product is derived from
and in line with requirements. This is also outlined in the RTEMS Software
Engineering manual:

https://docs.rtems.org/branches/master/eng/prequalification.html

"The second area is the creation and maintenance of master technical data that
has traditionally not been owned or maintained by the RTEMS Project. The most
obvious example of this is a requirements set with proper infrastructure for
tracing requirements through code to test and documentation. It is expected
that these will be maintained by the RTEMS Qualification Project. They will be
evaluated for adoption by the main RTEMS Project but the additional maintenance
burden imposed will be a strong factor in this consideration. It behooves the
RTEMS Qualification Project to limit dependence on manual checks and ensure
that automation and ongoing support for that automation is contributed to the
RTEMS Project."

The missing requirements set and the corresponding traceability is the biggest
work package we have in this activity. To manage requirements a tool support is
necessary. We evaluated some open source requirements management tools:

https://docs.rtems.org/branches/master/eng/req-eng.html#tooling

We ended up with Doorstop. I am very happy about this tool and I think it
perfectly fits to what I have in mind with the specification items:

https://docs.rtems.org/branches/master/eng/req-eng.html#

I wrote a new build system for RTEMS based on specification items:

https://lists.rtems.org/pipermail/devel/2019-November/056267.html

This turned out to be a good proof of concept.

The specification items (YAML files) are machine and human readable (at least
for the subset of humans which got used to read plain text files). Between the
specification items and the documents mandated by standards is a gap. To fill
this gap tools are necessary. These tools run on the host (not the RTEMS
target). They will use the following inputs:

* specification items (in the RTEMS main repository "spec" directory)

* the RTEMS sources

* the RTEMS documentation sources

* output from test suite runs

* output from other tools (e.g. static analysers)

* databases (e.g. a ticket system)

Some tools will generate documentation sources (*.rst files) and configuration
files for other tools (e.g. Doxygen, static code analysers) for documents such
as:

* user manuals

* software architecture and design documentation

* Software Requirements Specification (SRS; ECSS-specific name)

* Interface Control Document (ICD; ECSS-specific name)

* test reports

* static analysis reports

* software problem reports

Some documents may be standard-specific. The goal is to have all meta-data
available in the specification items to satisfy different standards. The
generator tools should handle the standard specializations.

Other tools will execute tests on a specific target and collect the output
(e.g. the RTEMS Tester). We need tools to collect everything and produce a
package.

To implement the tools we need a programming language. From the set of
languages currently used by

Re: About Beaglebone Black device tree

2020-02-03 Thread Christian Mauderer 
On 02/02/2020 18:34, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Sun, Feb 2, 2020 at 9:49 PM Christian Mauderer  > wrote:
> 
> 
> On 31/01/2020 17:43, Vijay Kumar Banerjee wrote:
> >
> >
> > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     On 31/01/2020 17:25, Christian Mauderer wrote:
> >     > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote:
> >     >> Hi,
> >     >>
> >     >> While trying to run an rtems-littlevgl app on BBB, I found that
> >     the device
> >     >> tree generated from the freebsd source matching the freebsd-org
> >     >> HEAD commit doesn't work with the app and framebuffer
> device fails
> >     >> to open. This is most likely due to the changes in the
> freebsd dts
> >     >> sources because of which the overlay isn't working as expected.
> >     >
> >     > If I remember correctly, SD card doesn't work either with a FDT
> >     that is
> >     > too new.
> >     >
> >     >>
> >     >> I haven't had a detailed look at what's missing and the
> u-boot isn't
> >     >> reporting any error in applying the overlay either. I checked
> >     that the
> >     >> device tree built from freebsd tree matching the
> following commit
> >     >> works:
> >     >> 19a6ceb89dbacf74697d493e48c388767126d418
> >     >
> >     > At the moment that's the right one. But that can change if
> someone
> >     > updates libbsd again.
> >
> >     And I have to correct myself: That is not the right one. The
> current
> >     libbsd HEAD should work with
> 6b0307a0a5184339393f555d5d424190d8a8277a.
> >
> > I meant to say that the framebuffer doesn't work with the current HEAD
> > (6b0307).
> > I checked with a previous commit, which is 19a6ce and found it
> working.
> > I should have been clear in the problem statement, sorry about that.
> 
> Thats not good. But the correct way would be to find out what's wrong
> and fix it. Did they add a fix in a future FreeBSD version?
> 
> Most likely the overlay isn't working as expected. I'll have to have a
> detailed
> look to figure out what's going on there. 
> 
> >
> >     >
> >     >>
> >     >> This brings up two questions:
> >     >> 1. Should we add the commit hash in the user manual so that the
> >     user can
> >     >> build
> >     >>     from source matching that commits instead of HEAD. This
> can be a
> >     >> problem 
> >     >>     as other codes ported from freebsd might break if the
> device tree
> >     >> doesn't
> >     >>     match the HEAD commit of freebsd-org
> >     >
> >     > Adding a fixed commit id isn't really a good idea either. It
> is nearly
> >     > guaranteed that no one updates it if libbsd is updated. It
> would be
> >     > better to add instructions how to find out which commit
> should be
> >     used.
> >
> >     The command would be:
> >
> >         git ls-files -s freebsd-org
> >
> >     It works regardless whether the sub-module is initialized or not.
> >
> >     >
> >     >>
> >     >> 2. How do we manage the device tree overlays required by
> RTEMS or
> >     libbsd?
> >     >>     I guess only BBB uses an overlay currently. Can we add
> a BSD
> >     license to
> >     >>     the overlay and add it somewhere in rtems or rtems-libbsd
> >     repository and
> >     >>     maintain it?
> >     >
> >     > I think you wrote the overlay so you can add any license you
> want. But
> >     > I'm really not sure where to put it. We currently don't have a
> >     location
> >     > for that. Do you have a good suggestion?
> >     >
> >
> > How about rtemsbsd/sys/dts/arm/overlays ?
> > Following the freebsd tree freebsd/sys/dts/arm/overlays/
> 
> Following the FreeBSD tree is a good point. But would they be visible
> there? Beneath that: We currently don't have support for building the
> overlays. Do you have an idea how that could look like?
> 
> keeping it visible will be a problem. For building the overlay, we can
> use dtc
> and add a script to build the overlay. I see that rsb has a build
> package for
> devel/dtc.bset as well. 

Hm. Optimal would be an integration into waf. Something like "waf
fdt-overlay". Even better would be if we could build the original fdt
too. But I'm sure that both would be quite a bit tricky to integrate
(the waf scripts in libbsd are not really easy to understand). So I'm
not insisting on that.

> 
> Best regards
> 
> Christian
> 
> >
> >     > Best regards
> >     >
> >     > Christian
> >     >
> >     >>
> >     >> Best

[PATCH] termios: Fix input canonical mode

2020-02-03 Thread Sebastian Huber 
Canonical input processing was broken by
667501a314ba75f80f1c13c6b43dd35d0a00efd1 as shown by test case
termios09.

Update #3800.
---
 cpukit/libcsupport/src/termios.c | 83 
 1 file changed, 33 insertions(+), 50 deletions(-)

diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index fedaa80ba0..b10a4ad774 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -1337,23 +1337,16 @@ rtems_status_code rtems_termios_register_isig_handler(
 
 /**
  * @brief Type returned by all input processing (iproc) methods
- */ 
+ */
 typedef enum {
   /**
-   * This indicates that the input character was processed
-   * and the results were placed into the buffer.
-   */
-  RTEMS_TERMIOS_IPROC_IN_BUFFER,
-  /**
-   * This indicates that the input character was processed
-   * and the result did not go into the buffer.
+   * This indicates that the input processing can continue.
*/
-  RTEMS_TERMIOS_IPROC_WAS_PROCESSED,
+  RTEMS_TERMIOS_IPROC_CONTINUE,
   /**
-   * This indicates that the input character was not processed and
-   * subsequent processing is required.
+   * This indicates that the input processing is done.
*/
-  RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED,
+  RTEMS_TERMIOS_IPROC_DONE,
   /**
* This indicates that the character was processed and determined
* to be one that requires a signal to be raised (e.g. VINTR or
@@ -1361,7 +1354,7 @@ typedef enum {
* occur. There is no further processing of this character required and
* the pending read() operation should be interrupted.
*/
-  RTEMS_TERMIOS_IPROC_INTERRUPT_READ
+  RTEMS_TERMIOS_IPROC_INTERRUPT
 } rtems_termios_iproc_status_code;
 
 /*
@@ -1379,12 +1372,10 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
   rtems_termios_isig_status_code rc;
   rc = (*termios_isig_handler)(c, tty);
   if (rc == RTEMS_TERMIOS_ISIG_INTERRUPT_READ) {
- return RTEMS_TERMIOS_IPROC_INTERRUPT_READ;
-  }
-  if (rc == RTEMS_TERMIOS_ISIG_WAS_PROCESSED) {
- return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+ return RTEMS_TERMIOS_IPROC_INTERRUPT;
   }
-  _Assert(rc == RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED);
+
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
   }
 
@@ -1394,25 +1385,25 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
   if ((c != '\0') && (tty->termios.c_lflag & ICANON)) {
 if (c == tty->termios.c_cc[VERASE]) {
   erase (tty, 0);
-  return RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 else if (c == tty->termios.c_cc[VKILL]) {
   erase (tty, 1);
-  return RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 else if (c == tty->termios.c_cc[VEOF]) {
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 } else if (c == '\n') {
   if (tty->termios.c_lflag & (ECHO | ECHONL))
 echo (c, tty);
   tty->cbuf[tty->ccount++] = c;
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 } else if ((c == tty->termios.c_cc[VEOL]) ||
(c == tty->termios.c_cc[VEOL2])) {
   if (tty->termios.c_lflag & ECHO)
 echo (c, tty);
   tty->cbuf[tty->ccount++] = c;
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 }
   }
 
@@ -1425,9 +1416,8 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
 if (tty->termios.c_lflag & ECHO)
   echo (c, tty);
 tty->cbuf[tty->ccount++] = c;
-return RTEMS_TERMIOS_IPROC_IN_BUFFER;
   }
-  return RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 
 /*
@@ -1456,7 +1446,7 @@ static rtems_termios_iproc_status_code
 siprocPoll (unsigned char c, rtems_termios_tty *tty)
 {
   if (c == '\r' && (tty->termios.c_iflag & IGNCR) != 0) {
-return RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED;
+return RTEMS_TERMIOS_IPROC_CONTINUE;
   }
 
   /*
@@ -1476,7 +1466,6 @@ fillBufferPoll (struct rtems_termios_tty *tty)
 {
   int n;
   rtems_termios_iproc_status_code rc;
-  rtems_termios_iproc_status_code retval = RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
 
   if (tty->termios.c_lflag & ICANON) {
 for (;;) {
@@ -1485,12 +1474,8 @@ fillBufferPoll (struct rtems_termios_tty *tty)
 rtems_task_wake_after (1);
   } else {
 rc = siprocPoll (n, tty);
-if (rc == RTEMS_TERMIOS_IPROC_IN_BUFFER) {
-  break;
-}
-if (rc == RTEMS_TERMIOS_IPROC_INTERRUPT_READ) {
-  retval = RTEMS_TERMIOS_IPROC_INTERRUPT_READ;
-  break;
+if (rc != RTEMS_TERMIOS_IPROC_CONTINUE) {
+  return rc;
 }
   }
 }
@@ -1519,9 +1504,8 @@ fillBufferPoll (struct rtems_termios_tty *tty)
 rtems_task_wake_after (1);
   } else {
 rc = siprocPoll (n, tty);
-if (rc == RTEMS_TERMIOS_IPROC_INTERRUPT_READ) {
-

[PATCH] score: Optimize STATUS_BUILD()

2020-02-03 Thread Sebastian Huber 
Do not cast to unsigned int to avoid an unsigned long long enum type.
Use a multiplication/division instead to preserve the signedness of the
POSIX status.
---
 cpukit/include/rtems/score/status.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/status.h 
b/cpukit/include/rtems/score/status.h
index fe1f0e87e6..b257ccc5db 100644
--- a/cpukit/include/rtems/score/status.h
+++ b/cpukit/include/rtems/score/status.h
@@ -49,9 +49,11 @@ typedef enum {
 
 /**
  * @brief Macro to build a status code from Classic and POSIX API parts.
+ *
+ * Uses a multiplication to preserve the signedness of the POSIX status.
  */
 #define STATUS_BUILD( classic_status, posix_status ) \
-  ( ( ( (unsigned int) ( posix_status ) ) << 8 ) | ( classic_status ) )
+  ( ( ( posix_status ) * 256 ) | ( classic_status ) )
 
 /**
  * @brief Macro to get the Classic API status code.
@@ -62,10 +64,10 @@ typedef enum {
 /**
  * @brief Macro to get the POSIX API status code.
  *
- * Performs an arithmetic shift to reconstruct a negative POSIX status.
+ * Uses a division to preserve the signedness of the POSIX status.
  */
 #define STATUS_GET_POSIX( status ) \
-  ( ( ( (int) ( status ) ) | 0xff ) >> 8 )
+  ( ( status ) / 256 )
 
 /**
  * @brief Status codes.
-- 
2.16.4

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

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

2020-02-03 Thread Chris Johns 
On 3/2/20 5:38 pm, Sebastian Huber wrote:
> - Am 3. Feb 2020 um 7:12 schrieb Chris Johns chr...@rtems.org:
> 
>> On 3/2/20 4:21 pm, Sebastian Huber wrote:
>>> - Am 3. Feb 2020 um 1:14 schrieb Chris Johns chr...@rtems.org:
>>>
 On 2/2/20 1:28 am, Sebastian Huber wrote:
> - Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems.org:
>
>> On 17/12/19 4:57 pm, Sebastian Huber wrote:
>>> My experience tells me that doing a BSP development without a debugger 
>>> is a
>>> waste of time.
>>
>> Sometimes getting a working debugger is more effort than getting a BSP 
>> to work.
>> The Pi is an example. I believe Alan used print statements.
>
> Ok, what do you think about a new configuration option:
>
> CONFIGURE_ENABLE_VERBOSE_INITIALIZATION

 CONFIGURE_ENABLE_VERBOSE_SYS_INIT ?
>>>
>>> In v2 of the patch set I named it CONFIGURE_VERBOSE_INITIALIZATION. I am 
>>> not in
>>> favour of abbreviations, since they are in general not used in the
>>> configuration options.
>>
>> Sure.
>>
>>> More precise would be CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION. It is 
>>> longer, but
>>> would be not the longest configuration option name (e.g.
>>> CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER is longer). So, what about this 
>>> one?
>>
>> Yes CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION is OK, the original could imply 
>> more
>> to a new user.
> 
> Ok, I will change the name to CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION. 
> Anything else which needs to be addressed before I push the patch set?

I do not think so. Thanks.

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

Re: V5.x porting guide or prototypical example?

2020-02-03 Thread Joel Sherrill 
On Sun, Feb 2, 2020 at 11:39 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Andrei,
>
> - Am 3. Feb 2020 um 4:14 schrieb  gro...@chichak.ca:
>
> > \Good day,
> >
> > A while back I put together a BSP for STM32F7 based on the STM32F407 BSP
> for an
> > early version of RTEMS 5.
> >
> > Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a
> bit and
> > I need to redo my BSP.
> >
> > Is there a porting guide for 5.0 yet, or is there a shining example of a
> BSP
> > that I should emulate?
>
> unfortunately, there is no porting guide available. We discuss currently
> the introduction of a new build system. If it is not very urgent, then I
> would wait a bit with the porting.
>
> You can also start right now and use the stm32f4 BSP as an example. The
> relevant directories are:
>
> bsps/arm/stm32f4 (sources)
>
> c/src/lib/libbsp/arm/stm32f4 (build system)
>

It isn't too bad Andrei. libcpu and libchip are now in bsps/shared. There
is a single
bsps/include and the Makefile.am just lists files.

If you have questions, just ask.

--joel


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

Re: [rtems-docs PATCH v2] user/testing: Add coverage analysis instructions

2020-02-03 Thread Gedare Bloom 
looks OK to me.

On Mon, Feb 3, 2020 at 3:06 AM Vijay Kumar Banerjee
 wrote:
>
> ---
>  user/testing/coverage.rst | 68 +++
>  user/testing/index.rst|  1 +
>  2 files changed, 69 insertions(+)
>  create mode 100644 user/testing/coverage.rst
>
> diff --git a/user/testing/coverage.rst b/user/testing/coverage.rst
> new file mode 100644
> index 000..4f2266e
> --- /dev/null
> +++ b/user/testing/coverage.rst
> @@ -0,0 +1,68 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2019 Vijay Kumar Banerjee 
> +
> +Coverage Analysis
> +=
> +
> +RTEMS is used in many critical systems. It is important that the RTEMS 
> Project
> +ensure that the RTEMS product is tested as thoroughly as possible. With this
> +goal in mind, the RTEMS test suite was expanded with the goal that 100% of 
> the
> +RTEMS executive is tested.
> +
> +RTEMS-TESTER takes the following arguments to produce coverage reports:
> +
> +`--coverage :`
> +When the coverage option is enabled the tester produces coverage reports 
> for
> +all the symbols in cpukit. To generate a coverage report for a specific
> +symbol-set ( e.g.: score) the symbol-set is passed as an argument to the
> +option, e.g.: --coverage=score.
> +
> +`--no-clean :`
> +Tells the script not to delete the .cov trace files generated while 
> running
> +the coverage. These trace files are used for debugging purposes and will 
> not
> +be needed for a normal user.
> +
> +For example: To generate a coverage report of hello.exe for leon3 on SIS, the
> +following command is used:
> +
> +.. code-block:: none
> +
> +rtems-test \
> +--rtems-tools=$HOME/development/rtems/5 \
> +--log=coverage_analysis.log \
> +--no-clean \
> +--coverage \
> +--rtems-bsp=leon3-sis-cov \
> +
> $HOME/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe
> +
> +The command will create the coverage report in the following tree structure:
> +
> +.. code-block:: none
> +
> +├── coverage_analysis.log
> +├── leon3-sis-coverage
> +│   └── score
> +│   ├── annotated.html
> +│   ├── annotated.txt
> +│   ├── branch.html
> +│   ├── branch.txt
> +│   ├── covoar.css
> +│   ├── ExplanationsNotFound.txt
> +│   ├── index.html
> +│   ├── no_range_uncovered.html
> +│   ├── no_range_uncovered.txt
> +│   ├── NotReferenced.html
> +│   ├── sizes.html
> +│   ├── sizes.txt
> +│   ├── summary.txt
> +│   ├── symbolSummary.html
> +│   ├── symbolSummary.txt
> +│   ├── table.js
> +│   ├── uncovered.html
> +│   └── uncovered.txt
> +└── leon3-sis-report.html
> +
> +The html on top of the directory, i.e., leon3-sis-report.html is the top 
> level
> +navigation for the coverage analysis report and will let the user browse 
> through
> +all the generated reports from different subsystems.
> diff --git a/user/testing/index.rst b/user/testing/index.rst
> index a938af4..3d36fab 100644
> --- a/user/testing/index.rst
> +++ b/user/testing/index.rst
> @@ -43,6 +43,7 @@ extension.
>
> tests
> configuration
> +   coverage
> consoles
> simulation
> gdb-jtag
> --
> 2.21.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs PATCH v2] user/testing: Add coverage analysis instructions

2020-02-03 Thread Chris Johns 
On 4/2/20 10:26 am, Gedare Bloom wrote:
> looks OK to me.

+1 from me.

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

Re: V5.x porting guide or prototypical example?

2020-02-03 Thread groups 
Thank you Seb and Joel.

I’ll do it. 

One of our customers Flock Audio (flockaudio.com) has a product on the market, 
PATCH, that uses an STM32F767 and RTEMS. The product is a replacement for a 
professional audio studio patch bay that is used to route microphones, 
instruments, compressors and the sort. The Flock unit is a digitally controlled 
unit but the audio signal path is completely analog. Instead of using 1/4” mono 
patch cables, we do the patching of inputs to outputs using a crossbar 
multiplexer  controlled by the processor.

The processor is overkill, and is under clocked to <100MHz for ease of FCC 
compliance, and uses USB to talk to the desktop app. Future versions will use 
ethernet, so I’ll have to figure out how to get a network stack going on the 
‘767.

Thanks again for the pointers, and sorry to post this in the dev list, I was 
aiming for the user list but Mail decided otherwise.


Andrei

> On 2020-February-03, at 15:25, Joel Sherrill  wrote:
> 
> 
> 
> On Sun, Feb 2, 2020 at 11:39 PM Sebastian Huber 
>  > wrote:
> Hello Andrei,
> 
> - Am 3. Feb 2020 um 4:14 schrieb  gro...@chichak.ca 
> :
> 
> > \Good day,
> > 
> > A while back I put together a BSP for STM32F7 based on the STM32F407 BSP 
> > for an
> > early version of RTEMS 5.
> > 
> > Now that RTEMS 5 became 5.0, the BSP structure has moved around quite a bit 
> > and
> > I need to redo my BSP.
> > 
> > Is there a porting guide for 5.0 yet, or is there a shining example of a BSP
> > that I should emulate?
> 
> unfortunately, there is no porting guide available. We discuss currently the 
> introduction of a new build system. If it is not very urgent, then I would 
> wait a bit with the porting.
> 
> You can also start right now and use the stm32f4 BSP as an example. The 
> relevant directories are:
> 
> bsps/arm/stm32f4 (sources)
> 
> c/src/lib/libbsp/arm/stm32f4 (build system)
> 
> It isn't too bad Andrei. libcpu and libchip are now in bsps/shared. There is 
> a single
> bsps/include and the Makefile.am just lists files.
> 
> If you have questions, just ask.
> 
> --joel
>  
> ___
> 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