Re: [PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

2019-03-27 Thread Sebastian Huber 

On 27/03/2019 20:26, Chris Johns wrote:

On 28/3/19 5:28 am, Joel Sherrill wrote:

On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:
 On 26/03/2019 15:17, Lou Woods wrote:
 > From: Lou Woods 
 >
 > ---
 >   bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++-
 >   1 file changed, 11 insertions(+), 5 deletions(-)
 >
 > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
 b/bsps/arm/xilinx-zynq/console/zynq-uart.c
 > index fa91f3f..9c21f6f 100644
 > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
 > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
 > @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
 >   #endif
 >   }
 >
 > +/*
 > + * Disable this because the initialization is done by code generated
 > + * by the Xilinx code generator.
 > + */

 The main purpose of the set attributes function is to apply the settings
 specified by the user via the Termios interface. Returning false just
 indicates that this function is not implemented. If you want to hide
 this fact from the user, then you can simply return true ...

This assumes all UART hardware supports all possible options. There are many
UARTs that do not. I am not sure if there are errno's that could determine the
nature of the failure.


We discussed this alternative with Chris and this was the end result.

git blame shows that Chris added the if 0 and then you added the return false
which broke the callers. From that point forward, no interactive test ran
successfully.

The driver provides no attribute functionality so removing the function means
the default behavior in termios is used to manage the error. It was decided
having the default behavior was best until the driver provided the 
functionality.

The Zynq is sort of strange in relation to default settings for UARTs. The
SystemZ component in the Xilinx design tool provides settings for the UART and
this ends up in the ps7_init.c file generated by the SDK and built into the FSBL
bootloader. This code paints all registers including the UART at boot time.
Adding UART attribute setting code to the RTEMS driver would result in the
SystemZ settings being overridden by RTEMS which is confusing. I am not sure how
this can be handled without there being some conflict. RTEMS would need to set
the baudrate to 115200 to match the SystemZ default.


So even if we implement the set attributes we have the problem to figure 
out in which state the UART is during initialization? My hope was 
eventually someone will implement it. Since nobody requested the set 
attributes function in a couple of years, I think it is all right to 
just remove it and return no error.


--
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: libbsd: Add openssl tool

2019-03-27 Thread Christian Mauderer 
Am 27.03.19 um 20:40 schrieb Chris Johns:
> On 27/3/19 9:11 pm, Christian Mauderer wrote:
>> Hello,
>>
>> I've added a port of the openssl tool together with a test for `openssl
>> speed` (benchmark) and `openssl req` (generating server certificates).
>>
>> Unfortunately the openssl tool is quite big so that I can't send the
>> patches to the mailing list. You can find them on a bin-openssl branch here:
>>
>>   https://git.rtems.org/christianm/rtems-libbsd.git/log/?h=bin-openssl
>>
>> The two patches are
>>
>>   Import:
>> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=0fecf49362778d77da97e19cf9cbb639c64e1735
>>
>>   Port:
>> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=d1dac7891cd3234c935ce7e4d742b6f87663a5e1
>>
>> If everything is OK,
> 
> Very nice and thank you. The change looks great.

Thanks. I committed them.

> 
> I see OpenSSL 3.0.0 and later has an Apache V2 license so I assume the code is
> covered by this license. I could not see a LICENSES file in the top of our
> source tree that lists the licenses. Should we have one with the licenses
> contained in the libbsd package?

FreeBSD has a number of LICENSE files scattered about the source tree.
How about a plain text importer where we can just pick up LICENSE files
and import them together with the code?

> 
>> I'll commit the patches and backport them to the
>> 5-freebsd-12 branch.
> 
> What is this branch? I could not find anything in the top level 
> CONTRIBUTING.md
> doc. Is it documented?

Sebastian will write something about that.

> 
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] user: Fix typo by changing sudu to sudo

2019-03-27 Thread Jacob Shin 
---
 user/hosts/posix.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/hosts/posix.rst b/user/hosts/posix.rst
index 044b8bd..24e811f 100644
--- a/user/hosts/posix.rst
+++ b/user/hosts/posix.rst
@@ -126,7 +126,7 @@ Xubuntu. A minimal installation was used and the following 
packages installed:
 
 .. code-block:: none
 
-  $ sudu apt-get build-dep gcc-defaults g++ gdb git unzip pax bison \
+  $ sudo apt-get build-dep gcc-defaults g++ gdb git unzip pax bison \
  flex libpython-dev git libncurses5-dev zlib1g-dev
 
 Note that in previous versions of Ubuntu, the package libpython-dev was
-- 
2.21.0.windows.1

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

[PATCH] README.txt: Fix typo

2019-03-27 Thread Jacob Shin 
---
 README.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.txt b/README.txt
index 3679d1d..74393a4 100644
--- a/README.txt
+++ b/README.txt
@@ -45,7 +45,7 @@ NOTE: RedHat Enterprise Linux (RHEL) and Fedora should be the 
same as CentOS.
 Images
 --
 
-All images should be placed int he 'images' directory and referenced from the
+All images should be placed in the 'images' directory and referenced from the
 ReST with a relative path. This lets us shared and control images.
 
 We prefer being able to build images from source. This is not always possible
-- 
2.21.0.windows.1

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

Re: libbsd: Add openssl tool

2019-03-27 Thread Chris Johns 
On 27/3/19 9:11 pm, Christian Mauderer wrote:
> Hello,
> 
> I've added a port of the openssl tool together with a test for `openssl
> speed` (benchmark) and `openssl req` (generating server certificates).
> 
> Unfortunately the openssl tool is quite big so that I can't send the
> patches to the mailing list. You can find them on a bin-openssl branch here:
> 
>   https://git.rtems.org/christianm/rtems-libbsd.git/log/?h=bin-openssl
> 
> The two patches are
> 
>   Import:
> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=0fecf49362778d77da97e19cf9cbb639c64e1735
> 
>   Port:
> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=d1dac7891cd3234c935ce7e4d742b6f87663a5e1
> 
> If everything is OK,

Very nice and thank you. The change looks great.

I see OpenSSL 3.0.0 and later has an Apache V2 license so I assume the code is
covered by this license. I could not see a LICENSES file in the top of our
source tree that lists the licenses. Should we have one with the licenses
contained in the libbsd package?

> I'll commit the patches and backport them to the
> 5-freebsd-12 branch.

What is this branch? I could not find anything in the top level CONTRIBUTING.md
doc. Is it documented?

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

Re: Design Tools for RTEMS Qualification Toolchain

2019-03-27 Thread Joel Sherrill 
Scott. mentioned you below. Time for you to speak up. :)

On Wed, Mar 27, 2019 at 1:08 PM Jose Valdez  wrote:

> Hello Joel,
>
>
>
> From the statement of work of the RTEMS Qualification, we have that:
>
>
>
> “The Software Design Document (SDD) has to cover ECSS-E-ST-40C clauses
> 5.4.3.1.a, 5.4.3.2.a, 5.4.3.3.a, 5.4.3.4.a, 5.4.3.5.a, 5.4.3.6.c,
> 5.5.2.1.a, 5.5.2.1.b, 5.5.2.1.c, 5.5.2.2.a, 5.5.2.3.a, 5.5.2.4.a,
> 5.5.2.5.a, 5.5.2.6.a, 5.5.2.7.a, 5.5.3.1.a, 5.5.3.2.a, 5.5.3.2.b,
> 5.8.3.3.a, and 5.8.3.4.a and ECSS-Q-ST-80C clause 7.2.2.3.a.”
>

Thanks. The qualification and compliance efforts I have been involved with
or near allow you to do "bespoke" documentation and provide a mapping from
the expected to the actual.More below.


>
>
> The Software Design Document is the document which will contain
> Architectural Design (“high level”) and Detailed Design (“low level”) of
> RTEMS.
>

Using this as an example, we could have an Architecture Design document and
something else for Detailed Design. The mapping document from ECCS to RTEMS
artifacts would go through each of those section numbers, likely repeat the
text, and then explain where the required information is for RTEMS. If
necessary, it will justify the mapping. For example,say we were using a
true modeling tool which generated code, requirements, etc. It is quite
likely that its output is not in the format or names expected by ECCS, NASA
Quaity, DO-178, or another standard.

Providing the mapping document insulates both RTEMS and ECCS from each
other.

This is not to say that the names or artifact list in ECCS is bad -- just
that it is ECCS. And another standard will name the same artifact
differently. We will end up producing mapping documents so we might as well
start with one.

Scott Zemerick did a mapping for a couple of the quality standards when he
gave us the outline of the Software Engineering Guide. If we do an ECCS ->
RTEMS mapping, then the NASA folks should be able to do a NASA Quality and
hopefully DO-178 -> RTEMS mapping document in parallel.


> This means that the RTEMS Qualification Toolchain shall cover as much as
> possible the points above. I expect that some of the points can be done
> with the help of a tool (e.g. production of detailed component and sequence
> diagrams) but I haven’t seen a tool that does every content automatically –
> although of course, this would be great. My best guess is that the
> qualification toolchain will pick up the design that is made, probably bits
> of sphynx modules, aggregate them, do some automatic work (e.g.
> traceabilities, interfaces) and then generate a final Sphynx that could be
> converted to pdf. For the points above which cannot be automated, they have
> to be done manually.
>

I'm old and cynical on the quality of generated output so I am guessing
that we will find some we like and some that sucks. Hopefully the stuff we
have to do by hand is not volatile. Things dependent on source code need to
be generated.

Devil is in the details. We have to push each artifact topic and make it as
easy and maintainable as possible.

>
>
> I hope that this explanation answers your questions. Note also for your
> question below: “This is a goal for improving the RTEMS Project processes.
> Are these being captured?”, yes, we will do it
>

+1 Did my outline for the tools evaluation chapter in the SW Engineering
Guide make sense? I hope so because I think you are working on it now.

If the requirements tool evaluation is nearing an end, posting that as a
patch in Rest for the Guide would be a good start. This will then be
another section in the same chapter.

--joel

>
>
> Best regards
>
>
>
> José
>
>
>
>
>
> *From:* Joel Sherrill [mailto:j...@rtems.org]
> *Sent:* terça-feira, 26 de março de 2019 14:32
> *To:* Jose Valdez
> *Cc:* rtems-de...@rtems.org
> *Subject:* Re: Design Tools for RTEMS Qualification Toolchain
>
>
>
>
>
>
>
> On Mon, Mar 25, 2019 at 12:20 PM Jose Valdez 
> wrote:
>
> Hello Joel,
>
>
>
> Thank you for your reply.
>
>
>
> I meant by design tools, UML tools (I am targeting component and sequence
> diagrams). It seems that you meant that you consider design tools the ones
> that are able to produce code from the design. Indeed was not with that
> goal in mind, because:
>
> è RTEMS source code is already defined (although this would not be a
> critical point, since reverse engineering would be possible, like will do
> the doxygen)
>
> è As far as I know, most of these tools target code production for
> object-oriented languages. This is not the case for RTEMS.
>
>
>
> The term design tools covers so much territory that my first Google turned
> up SysML and MathCAD.
>
> It is just too broad a term.
>
>
>
>
>
> What do you mean by a use-case? An example? I tried to quick capture the
> main features of the tools and their applicability to our project and, as
> you may read in the previous e-mail, the PlantUML and blockdiag are the far
> the most suitable.
>
>
>
> The definition of use

Re: [PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

2019-03-27 Thread Chris Johns 
On 28/3/19 5:28 am, Joel Sherrill wrote:
> On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber
>  >
> wrote:
> On 26/03/2019 15:17, Lou Woods wrote:
> > From: Lou Woods 
> >
> > ---
> >   bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++-
> >   1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
> b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > index fa91f3f..9c21f6f 100644
> > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
> >   #endif
> >   }
> >   
> > +/*
> > + * Disable this because the initialization is done by code generated
> > + * by the Xilinx code generator.
> > + */
> 
> The main purpose of the set attributes function is to apply the settings
> specified by the user via the Termios interface. Returning false just
> indicates that this function is not implemented. If you want to hide
> this fact from the user, then you can simply return true ...

This assumes all UART hardware supports all possible options. There are many
UARTs that do not. I am not sure if there are errno's that could determine the
nature of the failure.

> We discussed this alternative with Chris and this was the end result.
> 
> git blame shows that Chris added the if 0 and then you added the return false
> which broke the callers. From that point forward, no interactive test ran
> successfully. 

The driver provides no attribute functionality so removing the function means
the default behavior in termios is used to manage the error. It was decided
having the default behavior was best until the driver provided the 
functionality.

The Zynq is sort of strange in relation to default settings for UARTs. The
SystemZ component in the Xilinx design tool provides settings for the UART and
this ends up in the ps7_init.c file generated by the SDK and built into the FSBL
bootloader. This code paints all registers including the UART at boot time.
Adding UART attribute setting code to the RTEMS driver would result in the
SystemZ settings being overridden by RTEMS which is confusing. I am not sure how
this can be handled without there being some conflict. RTEMS would need to set
the baudrate to 115200 to match the SystemZ default.

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

Re: [PATCH] Disable zynq_uart_set_attributes that prevents console input

2019-03-27 Thread Joel Sherrill 
On Wed, Mar 27, 2019 at 1:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 26/03/2019 15:17, Lou Woods wrote:
> > From: Lou Woods
> >
> > This patch fully disables the zynq_uart_set_attributes handler that had
> > previously been commented out, but was returning false.  This prevented
> > fileio.exe from blocking on the rtems_shell_wait_for_input call.
>
> Would it make sense to move this comment to the commit message?
>

Yeah. It would.

This is certainly a case of starting with something broken and tracking it
through multiple changes using git blame to figure out why it wasn't
working.

>
> --
> 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] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

2019-03-27 Thread Joel Sherrill 
On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 26/03/2019 15:17, Lou Woods wrote:
> > From: Lou Woods 
> >
> > ---
> >   bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++-
> >   1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
> b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > index fa91f3f..9c21f6f 100644
> > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
> > @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
> >   #endif
> >   }
> >
> > +/*
> > + * Disable this because the initialization is done by code generated
> > + * by the Xilinx code generator.
> > + */
>
> The main purpose of the set attributes function is to apply the settings
> specified by the user via the Termios interface. Returning false just
> indicates that this function is not implemented. If you want to hide
> this fact from the user, then you can simply return true ...
>

We discussed this alternative with Chris and this was the end result.

git blame shows that Chris added the if 0 and then you added the return
false
which broke the callers. From that point forward, no interactive test ran
successfully.


> > +#if 0
> >   static bool zynq_uart_set_attributes(
> > rtems_termios_device_context *context,
> > const struct termios *term
> >   )
> >   {
> > -#if 0
> > volatile zynq_uart *regs = zynq_uart_get_regs(minor);
> > uint32_t brgr = 0;
> > uint32_t bauddiv = 0;
> > @@ -283,14 +287,16 @@ static bool zynq_uart_set_attributes(
> > regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
> >
> > return true;
> > -#else
> > -  return false;
>
> ... here.
>
> > -#endif
> >   }
> > +#endif
> >
> >   const rtems_termios_device_handler zynq_uart_handler = {
> > .first_open = zynq_uart_first_open,
> > -  .set_attributes = zynq_uart_set_attributes,
> > +#if 0
> > +  .set_attributes = zynq_uart_set_attributes;
> > +#else
> > +  .set_attributes = NULL,
> > +#endif
> > .write = zynq_uart_write_support,
> >   #ifdef ZYNQ_CONSOLE_USE_INTERRUPTS
> > .last_close = zynq_uart_last_close,
>
> --
> 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

RTEMS on ARMv8

2019-03-27 Thread Jeff Kubascik 
Hello,

I am interested in porting RTEMS to run as a Xen guest on our distro for the
Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM Cortex-A53 processor, which
is based on the ARMv8 architecture.

I have noticed that RTEMS already runs on a few Zynq 7000 boards. However, those
are using the Cortex-A9 processor, which is based on the ARMv7 architecture.
Looking at the source code, I didn't see any ARMv8 cpu code.

I was curious if there has been any work done to port RTEMS to an ARMv8 based
platform?

Thanks!

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

RE: Design Tools for RTEMS Qualification Toolchain

2019-03-27 Thread Jose Valdez 
Hello Joel,

From the statement of work of the RTEMS Qualification, we have that:

“The Software Design Document (SDD) has to cover ECSS-E-ST-40C clauses 
5.4.3.1.a, 5.4.3.2.a, 5.4.3.3.a, 5.4.3.4.a, 5.4.3.5.a, 5.4.3.6.c, 5.5.2.1.a, 
5.5.2.1.b, 5.5.2.1.c, 5.5.2.2.a, 5.5.2.3.a, 5.5.2.4.a, 5.5.2.5.a, 5.5.2.6.a, 
5.5.2.7.a, 5.5.3.1.a, 5.5.3.2.a, 5.5.3.2.b, 5.8.3.3.a, and 5.8.3.4.a and 
ECSS-Q-ST-80C clause 7.2.2.3.a.”

The Software Design Document is the document which will contain Architectural 
Design (“high level”) and Detailed Design (“low level”) of RTEMS. This means 
that the RTEMS Qualification Toolchain shall cover as much as possible the 
points above. I expect that some of the points can be done with the help of a 
tool (e.g. production of detailed component and sequence diagrams) but I 
haven’t seen a tool that does every content automatically – although of course, 
this would be great. My best guess is that the qualification toolchain will 
pick up the design that is made, probably bits of sphynx modules, aggregate 
them, do some automatic work (e.g. traceabilities, interfaces) and then 
generate a final Sphynx that could be converted to pdf. For the points above 
which cannot be automated, they have to be done manually.

I hope that this explanation answers your questions. Note also for your 
question below: “This is a goal for improving the RTEMS Project processes. Are 
these being captured?”, yes, we will do it

Best regards

José


From: Joel Sherrill [mailto:j...@rtems.org]
Sent: terça-feira, 26 de março de 2019 14:32
To: Jose Valdez
Cc: rtems-de...@rtems.org
Subject: Re: Design Tools for RTEMS Qualification Toolchain



On Mon, Mar 25, 2019 at 12:20 PM Jose Valdez 
mailto:jose.val...@edisoft.pt>> wrote:
Hello Joel,

Thank you for your reply.

I meant by design tools, UML tools (I am targeting component and sequence 
diagrams). It seems that you meant that you consider design tools the ones that 
are able to produce code from the design. Indeed was not with that goal in 
mind, because:

==> RTEMS source code is already defined (although this would not be a critical 
point, since reverse engineering would be possible, like will do the doxygen)

==> As far as I know, most of these tools target code production for 
object-oriented languages. This is not the case for RTEMS.

The term design tools covers so much territory that my first Google turned up 
SysML and MathCAD.
It is just too broad a term.


What do you mean by a use-case? An example? I tried to quick capture the main 
features of the tools and their applicability to our project and, as you may 
read in the previous e-mail, the PlantUML and blockdiag are the far the most 
suitable.

The definition of use case is " a specific situation in which a product or 
service could potentially be used."
I think that covers my intent. Define how these tools will be used and what's 
expected.

I agree that we are not generating code and are just capturing existing design.
But I still don't know what technical data/artifacts are required by the ESA 
quality standard
so can only base the expected use cases on what I would expect.

+ Document high level architecture in a new document
+ Document sequences, flows, logic primarily to enhance Doxygen output

Any diagrams could also be useful in Classic API Users Guide to document
schedulers,  etc to users.



I agree with the approach to generate detail design data from source code and 
then for the top level architecture, to use the Design selected tool. Of course 
part of the work will be to incorporate functionality that if an architectural 
change in the code is made, the user shall be warned to update the 
Architectural Design. This shall be done by linking (traceability) 
architectural components source code (that’s why defining architectural 
components in text files will be useful).

This is a a goal for improving the RTEMS Project processes. Are these being
captured?

And I would expect a fair number of false positives. I will have 30 years with 
RTEMS
this summer and the basic architecture figures rarely need to change for 
technical
reasons.

I'm not trying to be argumentative. Just looking a well-defined process for 
these
tool evaluations:

+ What will the tool(s) be used for?
+ What artifacts produced?
+ What "requirements" of the various quality standards is it meeting?
+ Does it need to integrate with build processes?

I am assuming a high level design document would be natural to go in the
RTEMS Documentation Suite. Today, I am sure the rtems-docs build system
supports both PlantUML and ditaa. If it doesn't support graphviz/dot and mscgen
(used by our Doxygen), then that's has to be addressed.

--joel


Best regards

José

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: segunda-feira, 25 de março de 2019 16:31
To: Jose Valdez
Cc: rtems-de...@rtems.org
Subject: Re: Design Tools for RTEMS Qualification Toolchain

You haven't defined what

Re: Project Track Page: Drafted proposal for Basic Support for Trace Compass

2019-03-27 Thread Ravindra Kumar Meena 
Hi Sebastian,

I have already submitted the proposal. Phase 1 of my proposal is to
generate trace data(LTTng). So I tried this example to figure out the way
for generating trace data(LTTng)
https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application

Maybe we could try out the same. I would like to hear your opinion on this.

Thanks
--Ravindra Kumar Meena

On Tue, Mar 26, 2019 at 10:27 PM Ravindra Kumar Meena 
wrote:

> Great, thanks for the update.
>
> On Tue, Mar 26, 2019, 10:26 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Ravindra Kumar Meena,
>>
>> thanks for your proposal and the good work to prepare it. I will have a
>> look at it this week.
>>
>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

libbsd: Add openssl tool

2019-03-27 Thread Christian Mauderer 
Hello,

I've added a port of the openssl tool together with a test for `openssl
speed` (benchmark) and `openssl req` (generating server certificates).

Unfortunately the openssl tool is quite big so that I can't send the
patches to the mailing list. You can find them on a bin-openssl branch here:

  https://git.rtems.org/christianm/rtems-libbsd.git/log/?h=bin-openssl

The two patches are

  Import:
https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=0fecf49362778d77da97e19cf9cbb639c64e1735

  Port:
https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl&id=d1dac7891cd3234c935ce7e4d742b6f87663a5e1

If everything is OK, I'll commit the patches and backport them to the
5-freebsd-12 branch.

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Design Tools for RTEMS Qualification Toolchain

2019-03-27 Thread Sebastian Huber 

Hello José,

since the RTEMS software architecture, detailed design and 
implementation exists already we don't need a design tool. We need 
documentation tools for the software architecture and detailed design. I 
would simply use what we have and this is Doxygen + Graphviz + MSC + 
PlantUML.


For the pre-qualification activity the ECSS requirements are for example 
defined in ECSS-E-ST-40C:


5.4.3.1.a    Transformation of software requirements into a software 
architecture


5.4.3.2.a    Software design method

5.4.3.4.a    Description of software behaviour

5.4.3.5.a    Development and documentation of the software interfaces

5.5.2.1    Detailed design of each software component

5.5.2.2.a    Development and documentation of the software interfaces 
detailed design


5.5.2.3.a    Production of the detailed design model

5.5.2.4.a    Software detail design method

5.5.2.5    Detailed design of real–time software

5.5.3.1.a    Development and documentation of the software units

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