date:20200108


Hello,

the introduction of specification items and generator tools has some 
benefits. However, it makes things more complex. You also need to know 
how things are connected. Instead of having a single hand written 
content which you can immediately edit to do a modification, have to 
know about specification items, the existence of generator tools and 
which files are generated (e.g. documentation source files and header 
files) to change something.


I think we should address this with a howto. For the new build system I 
added a howto section to the documentation (8.6 Howtos):


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

We should add a general howto chapter to the RTEMS Software Engineering 
manual, which contains sections, e.g. one for the build system, for the 
application configuration, etc.


New howto topics could be:

Add a glossary term

Add a glossary acronym

Add an application configuration group

Add an application configuration option

Regroup application configuration options


--
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: Requirement Document generator tool


On 08/01/2020 19:31, Gedare Bloom wrote:


I agree completely on the proposed approach with Python tools.


Yes. Reading it I'm actually reminded about Google's approach toward
Python which includes many of the elements mentioned. Although their
guide is probably more comprehensive and verbose that what we need, it
might be a useful reference for developing a set of guidelines
suitable for Python code in RTEMS (mainly, rtems-tools).  Here is a
link:
http://google.github.io/styleguide/pyguide.html

I think most of the existing style has been determined and driving by
Chris Johns. So I would also give him some credit to develop/approve
how we plan to use Python at a project level. (**Hands Chris an "RTEMS
Python Maintainer" hat**);)


I think the Google guide would be a good start. We can always add 
project-specific exceptions/clarifications if necessary. My aim is to 
use it for new code, e.g. code produced for the pre-qualification 
activity. For the code format I strongly want to use a tool for this. I 
don't want to spend review time on code formatting issues.


Using standard guidelines makes the RTEMS Project more attractive for 
new contributors and GSoC students. I think it increases your job 
opportunities if you can refer to a successful GSoC project and it shows 
that you used standard engineering practices in the project. This is 
usually not something a university education includes.


--
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: Use specification items to generate documentation

On 08/01/2020 19:49, Gedare Bloom wrote:

On Wed, Jan 8, 2020 at 7:55 AM Sebastian Huber
wrote:

Hello,

for the RTEMS pre-qualification activity we need a specification of
RTEMS. I would like to use this opportunity to move structured
information which is present in hand written and hand formatted content
in the RTEMS documentation into a structured data format (YAML).
Documentation source files can be generated from the YAML files. Having
information available in an easily machine readable format with
meta-information gives us a lot of flexibility. For example to adjust
the presentation we just have to change the generator program and not
the hand written content. The presentation of things may depend on the
standard of interest, e.g. ECSS, IEC 61508, ISO 26262, DO-178C, etc.

The proposal makes sense to me.

To get started, I would like to use the glossary of terms and the
application configuration as a use case. The conversion from hand
written and hand formatted content to generated content needs three things:

1. A definition of the data format (YAML with Doorstop attributes)

2. The specification items in the defined data format.

3. A generator program which uses the specification items as input and
outputs the documentation source files.

The new build system introduced build specification items in the RTEMS
sources under "spec/build". I would like to place all of the RTEMS
specification under the "spec" directory. For the glossary I propose to
use "spec/glossary". For the application configuration categories I
propose "spec/cfg" and for the application configuration options
"spec/cfg/opt". The layout of the application configuration items
enables an easy reassignment of options to categories.

Will there also be specifications for RTEMS configuration? (I.e.,
options specified during RTEMS build such as --enable-networking.) If
so, maybe spec/cfg needs to be separated or subdirectoried for 'app'
vs 'rtems'?

The new build system doesn't use a --enable-networking command line
option. For each BSP configuration a list of key-value pairs in
INI-style files is used. The RTEMS_NETWORKING related option is defined
like this:

https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTNET.yml?h=build

One remark: the interpretation of the "links" attribute is item
type-dependent. In the build specification items the links are
interpreted as "depends on". In the requirements related specification
items the links are interpreted as "is a refinement of". In validation
test items the links are interpreted as "validates".

The definition of the data format should be added to the RTEMS Software
Engineering manual to the Software Requirements Engineering chapter.

The generator program should be written in Python and placed into the
rtems-tools repository. The generator program needs paths to the RTEMS
sources and the RTEMS documentation sources. The paths should be
specified via the command line.

Similar paths are specified as options for other tools (e.g.,
rtems-test). Aim for consistency (and code reuse) in these interfaces.

Yes, we should try to name the command line options consistently across
our tools.

For a proof-of-concept please have a look at the attached two patches.

The .doorstop.yml are "hidden" files in typical *nix filesystems. Are
these automatically generated files and not to be modified or
necessarily read by humans? If so, fine, but otherwise they should not
be "hidden"

The .doorstop.yml is defined by the Doorstop tool. A maintainer may have
to edit it if new item attributes are added which contribute to the item
fingerprint:

https://doorstop.readthedocs.io/en/latest/cli/creation/#document-configuration

What do you think of it?

Cursory glance of the patches makes sense. Is there a good way to
validate the format or error-check the configuration yml files, or it
is a manual job to create the file and check correctness?

At some point we need also a tool to check the specification for
consistency. Maybe we could use

https://json-schema.org/

The YAML/JSON world seems to be a bit scattered to me with lots of home
grown solutions.

--
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: Error while building the rtems-libbsd

2020-01-08 Thread Christian Mauderer

Hello Utkarsh,

On 08/01/2020 18:52, Utkarsh Rai wrote:
> So, finally after resetting almost every configuration on my system ,
> and rebasing the changes  on the latest libsd commit I was able to build
> the libbsd successfully on my host  for beagle BSP. 

Great.

>  I have been trying to get a test app to work for PRU drivers , as of
> now the app cannot read the IRQs triggered as described here
>  (The issue seems to be with mmaps)
> . Should I write the app from scratch or continue upon the current
> work?(And in that case it would be helpful if I could get some pointers
> to solve the mmap issue).

What advantage would you gain in re-writing the application? As far as I
understood the problem is with the mmap implementation. That won't
change by re-writing a demo application.

mmap in RTEMS is always a bit tricky. Basically everything that goes
beyond returning a pointer to a fixed memory location will get tricky. I
don't know the topic exactly. But I would expect that for the PRU
drivers mmap just has to just return a pointer to a fixed location.

Regarding the FreeBSD ticket you linked:

- It seems to be an old and closed one (from 2017). So I would assume
that FreeBSD already has that one implemented. Did you check that? Did
you check whether libbsd uses a recent enough commit to pull the patch in?

- I'm not sure why you think that ticket has something to do with mmap.
The only change in ti_pruss_mmap is that it returns an error value that
is more useful than before.

Best regards

Christian

> 
> 
> On Sun, Jan 5, 2020 at 2:27 PM Christian Mauderer  > wrote:
> 
> On 05/01/2020 03:17, Utkarsh Rai wrote:
> > 1. For the libbbsd I have been
> > using https://github.com/nilhoel1/rtems-libbsd/tree/ti_pruss, this was
> > used by @Nils Hölscher  > for his GSoc project(
> > I have talked to him about my errors, and this libbsd builds fine
> on his
> > host system).
> 
> That version of libbsd is based on commit bc2ba9a9c of libbsd which has
> been added on 2019-07-09.
> 
> > 2. The rtems and RSB versions are https://github.com/RTEMS/rtems.git 
> > and https://github.com/RTEMS/rtems-source-builder.git
> 
> Which commit did you check out? I would suggest to either check out one
> with about the same date as the libbsd commit. Or you should rebase the
> changes onto the latest libbsd commit. That depends on whether you want
> to just use the work or continue it.
> 
> > 3. I have been using the beaglebone black BSP.
> >
> >
> > On Fri, Jan 3, 2020 at 2:12 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     On 01/01/2020 16:14, Utkarsh Rai wrote:
> >     > I have been successful in building the rtems-libbsd using
> 'python3
> >     > ./waf'. Although, I had to do some weird changes to some of the
> >     files in
> >     > the libbsd package. (These changes were done as there were
> several
> >     build
> >     > errors even after the 'python ./waf' command )
> >     >
> >     > 1. In the  ../freebsd/sys/netinet/in_mcast.c
> >     > and ../../freebsd/sys/netpfil/pf/if_pfsync.c files I had to
> change
> >     > the IP_MIN_MEMBERSHIPS with IP_MAX_MEMBERSHIPS .
> >     >
> >     > 2. In the ../../freebsd/sys/netinet6/in6_mcast.c  and
> >     > .../freebsd/sys/netinet/ip_carp.c files I had to
> >     > change  IPV6_MIN_MEMBERSHIPS, to IPV6_MAX_MEMBERSHIPS,
> >     >
> >     > 3. In the ../testsuite/syscalls01/test_main.c I changed
> >     the IPPROTO_SEP
> >     > to IPPROTO_EGP .
> >     >
> >     > Now, I suspect that these changes will come back to bite me as I
> >     proceed
> >     > further as I have simply overwritten them based on build error
> >     > messages.  It would be helpful if the community can provide its
> >     views on
> >     > my changes and whether this is a bug or something that I am
> doing
> >     wrong.
> >
> >     I would too expect that these changes are not a good idea. In
> normal
> >     case libbsd builds without any trouble.
> >
> >     Can you give some more information about the exact versions
> you use:
> >
> >     - Which commit of libbsd are you trying to build?
> >     - Which rtems commit do you use?
> >     - Which tool version do you use? If RSB: Which commit?
> >     - What BSP do you use?
> >
> >     Best regards
> >
> >     Christian
> >
> >     >
> >     > On Tue, Dec 31, 2019 at 6:28 PM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>

Re: Coding Convention: Sorting Order of Includes?


On 08/01/2020 20:09, Gedare Bloom wrote:

On Wed, Jan 8, 2020 at 9:33 AM Joel Sherrill  wrote:




On Wed, Jan 8, 2020 at 8:03 AM Sebastian Huber 
 wrote:


On 03/01/2020 17:52, Gedare Bloom wrote:

Hello all,

Vijay noted in another thread that:
"For RTEMS, I don't see any preference mentioned in the docs for the
order or includes:
https://docs.rtems.org/branches/master/eng/coding-conventions.html

In libbsd, however, the FreeBSD style guide is followed which has a
preference for the order of header includes:
https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9";

Should we consider any rules? I would suspect that at least ordering
by API layering could be helpful. Lexical sorting is nice but probably
there will be some exceptions based on dependencies.


I would use the Google rule:

https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes

It is compatible to the FreeBSD style (except the include related header
first).



FWIW I don't like how they worded that. I think they mean the public header 
files.
Related would include private header files which are grouped later. But the 
rationale
makes sense as long as there isn't a conditional for "inside the package" which 
covers
up issues.

There is also the issue of defining conditionals like POSIX level, GNU misc,
IN_KERNEL, etc.. I try to do that before any includes.

--joel


The 'related header' raises for me one question, which is how to treat
*impl.h headers.

In general the style rules I have seen go from "general to specific"
ordering. As mentioned, the Google guide makes one exception to
include "related" header, which appears to be singular "the related
header" implies to me (in agreement with Joel) the header that defines
the functions of this source file.  I suspect there would be no such
"related header" in a header file, except maybe we would consider our
*impl.h header to be a "related header" of a public header file?  That
would be one issue to clarify before moving forward with a proposal on
header file order.


Yes, I would consider XZY.h a related header to XYZimpl.h and include 
XYZ.h here first.  In general the "related header" is only meaningful 
for includes done in implementation source files (*.c and *.cc).




Once we decide whether to use the 'related header' or not, I think we
can define the rules following the FreeBSD/Google style and
Sebastian's suggestion. We have the somewhat odd position of having
both "kernel" (supercore) includes as well as userspace includes
(C/C++ libs), so we can't just point to either of those style guides
and  say "use it". A bit of writing has to be done :)


The "kernel" includes are "8. Your project's .h files." from my point of 
view.


Yes, some writing is necessary.

--
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: .rtemsstack location on ARM


Hello,

the region name REGION_VECTOR is a bit misleading. For ARMv-7M the 
vector table is in the .bsp_start_text section, see 
"bsps/arm/shared/start/start.S". In the REGION_VECTOR there is only the 
interrupt stack.


--
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: Glossary of Terms

On Wed, Jan 8, 2020 at 12:36 PM Gedare Bloom  wrote:

> On Tue, Jan 7, 2020 at 11:34 PM Sebastian Huber
>  wrote:
> >
> >
> >
> > On 07/01/2020 17:21, Gedare Bloom wrote:
> > > On Tue, Jan 7, 2020 at 2:09 AM Sebastian Huber
> > >   wrote:
> > >> On 03/01/2020 18:16, Joel Sherrill wrote:
> > >>>
> > >>> On Fri, Jan 3, 2020, 10:22 AM Gedare Bloom  > >>> > wrote:
> > >> [...]
> > >>>  I prefer we use a centralized glossary/document to generate
> individual
> > >>>  glossaries (via scripting or improving Sphinx). This will be a
> lot
> > >>>  easier to maintain.
> > >>>
> > >>>
> > >>> The DoD Architecture Framework (DoDAF) calls this an AV-2 which is a
> > >>> singular artifacr across the project for consistencyt
> > >>>
> > >>> http://acqnotes.com/acqnote/tasks/av-2-integrated-dictionary
> > >>>
> > >>> That said, you need glossaries in documents and automating pulling
> > >>> definitions and acronyms out automatically producing a glossary and
> > >>> acronym list from the master AV-2 is desirable. No one wants to
> > >>> reference a standalone glossary.
> > >>>
> > >>> There can be issues if definitions change over time because the
> single
> > >>> AV-2 can't deal with old and new. It gets confusing. I have seen a
> > >>> project where the AV-2 included history like the Oxford English
> > >>> Dictionary. It was dreadful.
> > >>>
> > >>> That's a lot of background to say this isn't a RTEMS unique problem.
> A
> > >>> central database of acronyms and definitions would be a good thing.
> If
> > >>> grep is sufficient to find word use to trigger inclusion in a
> document
> > >>> specific glossary, great.
> > >> Good, so my proposal is this:
> > >>
> > >> 1. I move c-user/glossary.rst to common/glossary.rst and include this
> > >> file as is in c-user.
> > >>
> > >> 2. The glossary.rst for the other documents is generated from
> > >> common/glossary.rst based on the :term: usage. This can start simple,
> > >> e.g. only look at the *.rst files in the document directory (e.g. no
> > >> recursive includes).
> > >>
> > > Later when a new term is added for something not in c-user, then the
> > > c-user should be updated to also derive its glossary with :term:?
> > > (Before that, we might need to double check if the current glossary
> > > terms are all defined/used in c-user with :term:.)
> >
> > The :term: is sparely used in c-user currently. It would require a bit
> > of manual work to pull in all terms via this text role.
> >
> Understood, although adding those :term: from the existing glossary
> seems like a good job for grep and sed to me.
>
> > After one night, I don't like my proposal any more. I think it would be
> > better to move the glossary terms to the RTEMS specification (e.g. in
> > the RTEMS sources "spec/glossary/*.yml") and generate the glossary.rst
> > for the documents with a script.  This gives us more flexibility and
> > removes the need for the special parser code, see:
> >
> > https://lists.rtems.org/pipermail/devel/2020-January/056811.html
> >
> > The AV-2 mentioned by Joel wants the glossary terms in categories. We
> > could add categories to the glossary specification items. This would be
> > difficult with a master glossary in reST.
> >
> Yes, putting the glossary terms in a parseable structure like YAML
> sounds sensible.
>

+1

I know I have said this to anyone who will listen in person but I think the
questions we are answering and infrastructure being built up to address
pre-qualification and high integrity development processes will be of
great value outside the RTEMS Project. As banal as glossary management
sounds, managing as recommended by DoDAF and doing it with open
source tools is a BIG deal. Similar with requirements and traceability.

Let's keep solving big problems in simple ways with open source tools. :)

--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: Coding Convention: Sorting Order of Includes?

On Wed, Jan 8, 2020 at 9:33 AM Joel Sherrill  wrote:
>
>
>
> On Wed, Jan 8, 2020 at 8:03 AM Sebastian Huber 
>  wrote:
>>
>> On 03/01/2020 17:52, Gedare Bloom wrote:
>> > Hello all,
>> >
>> > Vijay noted in another thread that:
>> > "For RTEMS, I don't see any preference mentioned in the docs for the
>> > order or includes:
>> > https://docs.rtems.org/branches/master/eng/coding-conventions.html
>> >
>> > In libbsd, however, the FreeBSD style guide is followed which has a
>> > preference for the order of header includes:
>> > https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9";
>> >
>> > Should we consider any rules? I would suspect that at least ordering
>> > by API layering could be helpful. Lexical sorting is nice but probably
>> > there will be some exceptions based on dependencies.
>>
>> I would use the Google rule:
>>
>> https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
>>
>> It is compatible to the FreeBSD style (except the include related header
>> first).
>
>
> FWIW I don't like how they worded that. I think they mean the public header 
> files.
> Related would include private header files which are grouped later. But the 
> rationale
> makes sense as long as there isn't a conditional for "inside the package" 
> which covers
> up issues.
>
> There is also the issue of defining conditionals like POSIX level, GNU misc,
> IN_KERNEL, etc.. I try to do that before any includes.
>
> --joel
>
The 'related header' raises for me one question, which is how to treat
*impl.h headers.

In general the style rules I have seen go from "general to specific"
ordering. As mentioned, the Google guide makes one exception to
include "related" header, which appears to be singular "the related
header" implies to me (in agreement with Joel) the header that defines
the functions of this source file.  I suspect there would be no such
"related header" in a header file, except maybe we would consider our
*impl.h header to be a "related header" of a public header file?  That
would be one issue to clarify before moving forward with a proposal on
header file order.

Once we decide whether to use the 'related header' or not, I think we
can define the rules following the FreeBSD/Google style and
Sebastian's suggestion. We have the somewhat odd position of having
both "kernel" (supercore) includes as well as userspace includes
(C/C++ libs), so we can't just point to either of those style guides
and  say "use it". A bit of writing has to be done :)

-Gedare

>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use specification items to generate documentation

On Wed, Jan 8, 2020 at 7:55 AM Sebastian Huber
 wrote:
>
> Hello,
>
> for the RTEMS pre-qualification activity we need a specification of
> RTEMS. I would like to use this opportunity to move structured
> information which is present in hand written and hand formatted content
> in the RTEMS documentation into a structured data format (YAML).
> Documentation source files can be generated from the YAML files. Having
> information available in an easily machine readable format with
> meta-information gives us a lot of flexibility. For example to adjust
> the presentation we just have to change the generator program and not
> the hand written content. The presentation of things may depend on the
> standard of interest, e.g. ECSS, IEC 61508, ISO 26262, DO-178C, etc.
>
The proposal makes sense to me.

> To get started, I would like to use the glossary of terms and the
> application configuration as a use case. The conversion from hand
> written and hand formatted content to generated content needs three things:
>
> 1. A definition of the data format (YAML with Doorstop attributes)
>
> 2. The specification items in the defined data format.
>
> 3. A generator program which uses the specification items as input and
> outputs the documentation source files.
>
> The new build system introduced build specification items in the RTEMS
> sources under "spec/build". I would like to place all of the RTEMS
> specification under the "spec" directory. For the glossary I propose to
> use "spec/glossary". For the application configuration categories I
> propose "spec/cfg" and for the application configuration options
> "spec/cfg/opt". The layout of the application configuration items
> enables an easy reassignment of options to categories.
>
Will there also be specifications for RTEMS configuration? (I.e.,
options specified during RTEMS build such as --enable-networking.) If
so, maybe spec/cfg needs to be separated or subdirectoried for 'app'
vs 'rtems'?

> The definition of the data format should be added to the RTEMS Software
> Engineering manual to the Software Requirements Engineering chapter.
>
> The generator program should be written in Python and placed into the
> rtems-tools repository. The generator program needs paths to the RTEMS
> sources and the RTEMS documentation sources. The paths should be
> specified via the command line.
>
Similar paths are specified as options for other tools (e.g.,
rtems-test). Aim for consistency (and code reuse) in these interfaces.

> For a proof-of-concept please have a look at the attached two patches.
>
The .doorstop.yml are "hidden" files in typical *nix filesystems. Are
these automatically generated files and not to be modified or
necessarily read by humans? If so, fine, but otherwise they should not
be "hidden"

> What do you think of it?
>
Cursory glance of the patches makes sense. Is there a good way to
validate the format or error-check the configuration yml files, or it
is a manual job to create the file and check correctness?

> --
> 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: Glossary of Terms

On Tue, Jan 7, 2020 at 11:34 PM Sebastian Huber
 wrote:
>
>
>
> On 07/01/2020 17:21, Gedare Bloom wrote:
> > On Tue, Jan 7, 2020 at 2:09 AM Sebastian Huber
> >   wrote:
> >> On 03/01/2020 18:16, Joel Sherrill wrote:
> >>>
> >>> On Fri, Jan 3, 2020, 10:22 AM Gedare Bloom  >>> > wrote:
> >> [...]
> >>>  I prefer we use a centralized glossary/document to generate 
> >>> individual
> >>>  glossaries (via scripting or improving Sphinx). This will be a lot
> >>>  easier to maintain.
> >>>
> >>>
> >>> The DoD Architecture Framework (DoDAF) calls this an AV-2 which is a
> >>> singular artifacr across the project for consistencyt
> >>>
> >>> http://acqnotes.com/acqnote/tasks/av-2-integrated-dictionary
> >>>
> >>> That said, you need glossaries in documents and automating pulling
> >>> definitions and acronyms out automatically producing a glossary and
> >>> acronym list from the master AV-2 is desirable. No one wants to
> >>> reference a standalone glossary.
> >>>
> >>> There can be issues if definitions change over time because the single
> >>> AV-2 can't deal with old and new. It gets confusing. I have seen a
> >>> project where the AV-2 included history like the Oxford English
> >>> Dictionary. It was dreadful.
> >>>
> >>> That's a lot of background to say this isn't a RTEMS unique problem. A
> >>> central database of acronyms and definitions would be a good thing. If
> >>> grep is sufficient to find word use to trigger inclusion in a document
> >>> specific glossary, great.
> >> Good, so my proposal is this:
> >>
> >> 1. I move c-user/glossary.rst to common/glossary.rst and include this
> >> file as is in c-user.
> >>
> >> 2. The glossary.rst for the other documents is generated from
> >> common/glossary.rst based on the :term: usage. This can start simple,
> >> e.g. only look at the *.rst files in the document directory (e.g. no
> >> recursive includes).
> >>
> > Later when a new term is added for something not in c-user, then the
> > c-user should be updated to also derive its glossary with :term:?
> > (Before that, we might need to double check if the current glossary
> > terms are all defined/used in c-user with :term:.)
>
> The :term: is sparely used in c-user currently. It would require a bit
> of manual work to pull in all terms via this text role.
>
Understood, although adding those :term: from the existing glossary
seems like a good job for grep and sed to me.

> After one night, I don't like my proposal any more. I think it would be
> better to move the glossary terms to the RTEMS specification (e.g. in
> the RTEMS sources "spec/glossary/*.yml") and generate the glossary.rst
> for the documents with a script.  This gives us more flexibility and
> removes the need for the special parser code, see:
>
> https://lists.rtems.org/pipermail/devel/2020-January/056811.html
>
> The AV-2 mentioned by Joel wants the glossary terms in categories. We
> could add categories to the glossary specification items. This would be
> difficult with a master glossary in reST.
>
Yes, putting the glossary terms in a parseable structure like YAML
sounds sensible.

> --
> 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: Requirement Document generator tool

On Wed, Jan 8, 2020 at 9:47 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jan 3, 2020 at 7:26 AM Sebastian Huber 
>  wrote:
>>
>> Hello Jose,
>>
>> On 03/01/2020 11:52, Jose Valdez wrote:
>>  Should be in rtems-tools? If so, in which place?
>> >>> I think this is the best place given the information I have. I would
>> >>> need to have more detail before I could provide any specific direction 
>> >>> here.
>> >>
>> >> All host tools are in rtems-tools so at this point, there isn't another 
>> >> place.
>> >>
>> >> But I agree with Chris. We need more information.
>> >>
>> > We need to know:
>> > * Language(s) used for the tool
>> > * Host requirements to run the tool
>> > * Licensing of the tool
>> >
>> > Putting the pre-qual tools into rtems-tools seems reasonable, but a 
>> > discussion should happen within the RTEMS Project community/maintainers to 
>> > do that.
>> >
>> > JV02012019, Joel and Gedare:
>> >
>> > We need to know:
>> > * Language(s) used for the tool - python (>= 3.7)
>> > * Host requirements to run the tool - Debian 10
>> > * Licensing of the tool - BSD-2-Clause
>> >
>> > Please read the section 4 of the document SDD-301.pdf, I am sending in 
>> > attach (removed to go to rtems devel mailing list!!). This provides an 
>> > overview of the tool (I think we missed to give you this overview).
>> > For more information you may also take a look in the SRS-300.pdf and 
>> > TI-003 (just the conclusions on each section).
>> > Note that the information presented in these documents is subjected to be 
>> > changed, but as I said, the idea is for you to have a better understanding 
>> > about the big picture of the project. The details will be discussed (and 
>> > iterated) alongside the project execution.
>>
>> the aim is to write all tools in the ESA pre-qualification activity in
>> Python. Derivatives of existing stuff will use the respective license.
>> New stuff will use the BSD-2-Clause license for code and CC-BY-SA-4.0
>> for documentation.
>>
>>  From an RTEMS Project point of view, project-specific documentation is
>> irrelevant in general. It can be used as a complementary material to
>> explain things intended for integration, however, all content relevant
>> to things integrated in the RTEMS Project must move to the right places
>> in the RTEMS Project.
>>
>> We have to settle on a specific Python version. Since Doorstop 2.0.post2
>> is already selected as the tool for requirements management and it
>> requires at least Python 3.6 I think it makes sense to use this version
>> as well for new tools. In contrast to the build system I think a Python
>> 2 compatibility is unnecessary.
>>
>> Tools which belong also to the work flow of an RTEMS user, e.g. the
>> RTEMS Tester, should still work with Python 2.
>>
>> The decisions, justification, and requirements with respect to the tool
>> language selection should be recorded in the RTEMS Software Engineering
>> manual.
>>
>> Once a tool language is selected. We need a coding style and standard.
>> We should choose an existing one, e.g.
>>
>> https://www.python.org/dev/peps/pep-0008/
>>
>> There should be tools to check the coding style automatically. I don't
>> want the situation we have with the RTEMS sources. For Python there are
>> plenty of tools, guides, and documentation available. We just have to
>> pick some for the RTEMS Project and document this in the RTEMS Software
>> Engineering manual.
>>
>> The compatible Python versions (e.g. 3.6+), coding style (e.g. black -l
>> 80), documentation style (e.g. pydocstyle), test approach (standard
>> Python unittest and unittest.mock), static analysis (e.g. mypy and
>> pylint), code coverage, use of third-party packages, etc. need to be
>> discussed with the RTEMS Project and the conclusions should be added to
>> the RTEMS Software Engineering manual.
>>
>> Running the checkers, test suites, code coverage, etc. should be done
>> though the build system (in rtems-tools this is waf). The Doorstop
>> project is a good example how this can be set up.
>>
>> If you look at the current RTEMS Software Engineering manual you will
>> find next to nothing with respect to Python code. You can set now the
>> standards (after discussion on devel@rtems.org). You should do this
>> before you send the first line of Python code for review.
>
>
> I agree completely on the proposed approach with Python tools.
>
Yes. Reading it I'm actually reminded about Google's approach toward
Python which includes many of the elements mentioned. Although their
guide is probably more comprehensive and verbose that what we need, it
might be a useful reference for developing a set of guidelines
suitable for Python code in RTEMS (mainly, rtems-tools).  Here is a
link:
http://google.github.io/styleguide/pyguide.html

I think most of the existing style has been determined and driving by
Chris Johns. So I would also give him some credit to develop/approve
how we plan to use Python at a project level. (**Hands Chris an "RTEMS
Python Main

Re: Error while building the rtems-libbsd

2020-01-08 Thread Utkarsh Rai

So, finally after resetting almost every configuration on my system , and
rebasing the changes  on the latest libsd commit I was able to build the
libbsd successfully on my host  for beagle BSP.
 I have been trying to get a test app to work for PRU drivers , as of now
the app cannot read the IRQs triggered as described here
 (The issue seems to be with mmaps) .
Should I write the app from scratch or continue upon the current work?(And
in that case it would be helpful if I could get some pointers to solve the
mmap issue).


On Sun, Jan 5, 2020 at 2:27 PM Christian Mauderer 
wrote:

> On 05/01/2020 03:17, Utkarsh Rai wrote:
> > 1. For the libbbsd I have been
> > using https://github.com/nilhoel1/rtems-libbsd/tree/ti_pruss, this was
> > used by @Nils Hölscher  for his GSoc project(
> > I have talked to him about my errors, and this libbsd builds fine on his
> > host system).
>
> That version of libbsd is based on commit bc2ba9a9c of libbsd which has
> been added on 2019-07-09.
>
> > 2. The rtems and RSB versions are https://github.com/RTEMS/rtems.git
> > and https://github.com/RTEMS/rtems-source-builder.git
>
> Which commit did you check out? I would suggest to either check out one
> with about the same date as the libbsd commit. Or you should rebase the
> changes onto the latest libbsd commit. That depends on whether you want
> to just use the work or continue it.
>
> > 3. I have been using the beaglebone black BSP.
> >
> >
> > On Fri, Jan 3, 2020 at 2:12 PM Christian Mauderer  > > wrote:
> >
> > On 01/01/2020 16:14, Utkarsh Rai wrote:
> > > I have been successful in building the rtems-libbsd using 'python3
> > > ./waf'. Although, I had to do some weird changes to some of the
> > files in
> > > the libbsd package. (These changes were done as there were several
> > build
> > > errors even after the 'python ./waf' command )
> > >
> > > 1. In the  ../freebsd/sys/netinet/in_mcast.c
> > > and ../../freebsd/sys/netpfil/pf/if_pfsync.c files I had to change
> > > the IP_MIN_MEMBERSHIPS with IP_MAX_MEMBERSHIPS .
> > >
> > > 2. In the ../../freebsd/sys/netinet6/in6_mcast.c  and
> > > .../freebsd/sys/netinet/ip_carp.c files I had to
> > > change  IPV6_MIN_MEMBERSHIPS, to IPV6_MAX_MEMBERSHIPS,
> > >
> > > 3. In the ../testsuite/syscalls01/test_main.c I changed
> > the IPPROTO_SEP
> > > to IPPROTO_EGP .
> > >
> > > Now, I suspect that these changes will come back to bite me as I
> > proceed
> > > further as I have simply overwritten them based on build error
> > > messages.  It would be helpful if the community can provide its
> > views on
> > > my changes and whether this is a bug or something that I am doing
> > wrong.
> >
> > I would too expect that these changes are not a good idea. In normal
> > case libbsd builds without any trouble.
> >
> > Can you give some more information about the exact versions you use:
> >
> > - Which commit of libbsd are you trying to build?
> > - Which rtems commit do you use?
> > - Which tool version do you use? If RSB: Which commit?
> > - What BSP do you use?
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > On Tue, Dec 31, 2019 at 6:28 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > On 31/12/2019 12:41, Utkarsh Rai wrote:
> > > > My host system has an x-86_64  architecture with ubuntu-18.04
> > > running on
> > > > top of it, I have a python2 installed.
> > > > Interestingly enough, when I clean up the libbsd directory
> > and try to
> > > > build as a super-user, I have two observations:-
> > >
> > > Please note that building as super user is generally not a
> > good idea for
> > > any sane build environment. Although I have to say that in
> > this case it
> > > provided an interesting error output ...
> > >
> > > > 1. The build fails with the following error message:-
> > > > [1/4] Creating
> > > >
> > >
> >
>   
> ///h/o/m/e///u/r/1/0///s/a/n/d/b/o/x///r/t/e/m/s/-/l/i/b/b/s/d///b/u/i/l/d///a/r/m/-/r/t/e/m/s/5/-/b/e/a/g/l/e/b/o/n/e/b/l/a/c/k/-/d/e/f/a/u/l/t/build-include/rtems/bsd/modules.h
> > >
> > > ... here. That looks like some join went horrible wrong. I
> > assume that
> > > there is some location in the build system where an array of
> paths
> > > should be joined but only one is given. Looks like a bug.
> > >
> > > > [2/4] Compiling rtemsbsd/rtems/generate_kvm_symbols
> > > > [3/4] Compiling
> > > testsuite/include/rtems/bsd/test/network-config.h.in
> > 
> > > 
> > > >

Re: Requirement Document generator tool

On Fri, Jan 3, 2020 at 7:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Jose,
>
> On 03/01/2020 11:52, Jose Valdez wrote:
>  Should be in rtems-tools? If so, in which place?
> >>> I think this is the best place given the information I have. I would
> >>> need to have more detail before I could provide any specific direction
> here.
> >>
> >> All host tools are in rtems-tools so at this point, there isn't another
> place.
> >>
> >> But I agree with Chris. We need more information.
> >>
> > We need to know:
> > * Language(s) used for the tool
> > * Host requirements to run the tool
> > * Licensing of the tool
> >
> > Putting the pre-qual tools into rtems-tools seems reasonable, but a
> discussion should happen within the RTEMS Project community/maintainers to
> do that.
> >
> > JV02012019, Joel and Gedare:
> >
> > We need to know:
> > * Language(s) used for the tool - python (>= 3.7)
> > * Host requirements to run the tool - Debian 10
> > * Licensing of the tool - BSD-2-Clause
> >
> > Please read the section 4 of the document SDD-301.pdf, I am sending in
> attach (removed to go to rtems devel mailing list!!). This provides an
> overview of the tool (I think we missed to give you this overview).
> > For more information you may also take a look in the SRS-300.pdf and
> TI-003 (just the conclusions on each section).
> > Note that the information presented in these documents is subjected to
> be changed, but as I said, the idea is for you to have a better
> understanding about the big picture of the project. The details will be
> discussed (and iterated) alongside the project execution.
>
> the aim is to write all tools in the ESA pre-qualification activity in
> Python. Derivatives of existing stuff will use the respective license.
> New stuff will use the BSD-2-Clause license for code and CC-BY-SA-4.0
> for documentation.
>
>  From an RTEMS Project point of view, project-specific documentation is
> irrelevant in general. It can be used as a complementary material to
> explain things intended for integration, however, all content relevant
> to things integrated in the RTEMS Project must move to the right places
> in the RTEMS Project.
>
> We have to settle on a specific Python version. Since Doorstop 2.0.post2
> is already selected as the tool for requirements management and it
> requires at least Python 3.6 I think it makes sense to use this version
> as well for new tools. In contrast to the build system I think a Python
> 2 compatibility is unnecessary.
>
> Tools which belong also to the work flow of an RTEMS user, e.g. the
> RTEMS Tester, should still work with Python 2.
>
> The decisions, justification, and requirements with respect to the tool
> language selection should be recorded in the RTEMS Software Engineering
> manual.
>
> Once a tool language is selected. We need a coding style and standard.
> We should choose an existing one, e.g.
>
> https://www.python.org/dev/peps/pep-0008/
>
> There should be tools to check the coding style automatically. I don't
> want the situation we have with the RTEMS sources. For Python there are
> plenty of tools, guides, and documentation available. We just have to
> pick some for the RTEMS Project and document this in the RTEMS Software
> Engineering manual.
>
> The compatible Python versions (e.g. 3.6+), coding style (e.g. black -l
> 80), documentation style (e.g. pydocstyle), test approach (standard
> Python unittest and unittest.mock), static analysis (e.g. mypy and
> pylint), code coverage, use of third-party packages, etc. need to be
> discussed with the RTEMS Project and the conclusions should be added to
> the RTEMS Software Engineering manual.
>
> Running the checkers, test suites, code coverage, etc. should be done
> though the build system (in rtems-tools this is waf). The Doorstop
> project is a good example how this can be set up.
>
> If you look at the current RTEMS Software Engineering manual you will
> find next to nothing with respect to Python code. You can set now the
> standards (after discussion on devel@rtems.org). You should do this
> before you send the first line of Python code for review.
>

I agree completely on the proposed approach with Python tools.


>
> Once the frame for Python development is settled. We need a high level
> description of the purpose of the tools, the inputs and the outputs.
> This high level description should be integrated in the RTEMS Project
> documentation. If you want to get things integrated in the RTEMS Project
> then you have make sure that it is good and general enough so that
> others can continue to work on it. In the worst case everything should
> be maintainable by the RTEMS Project without you in the future.
>

Describing the purpose, inputs and outputs, and high level description
should
go a long way to having a theory of operation for the tools. It is
important to
know what software engineering purpose the tool satisfies and its role in
the pre-qualification workflow.

T

Re: Pi Zero Automated Testing/TFTP/Uboot

2020-01-08 Thread Alan Cudmore

Unfortunately, The Raspberry Pi Zero (1.3) does not have a network
interface, it just has the MicroSD card and the interfaces exposed on the
40 Pin GPIO header. (SPI, I2C, GPIO, UART, etc)
The Raspberry Pi Zero W adds the Wi-Fi/bluetooth module that the RPi 3 has,
but I'm guessing that won't work with u-boot?

The Raspberry Pi Model B+ looks like it will be made until at least January
2022. It should be the same as the Pi Zero with the addition of the USB hub
that adds additional USB ports and the ethernet.
I think we are at the point where the "raspberrypi" BSP will run on all
single core models, so it may make sense for the reference system for the
"raspberrypi" BSP to continue to be the Model B+ so it can be used with
u-boot and TFTP.

https://www.raspberrypi.org/blog/product_categories/raspberry-pi-boards/

On Wed, Jan 8, 2020 at 10:37 AM Joel Sherrill  wrote:

> Hi
>
> Can the Pi Zero boot with TFTP like the wired versions? We are wondering
> as this is how the automated testing for the Pi's is done.
>
> We are hoping to setup at least one Pi from each basic generation (1, 2,
> 3, 4, and Zero) for automated testing.
>
> Thanks.
>
> --joel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coding Convention: Sorting Order of Includes?

On Wed, Jan 8, 2020 at 8:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/01/2020 17:52, Gedare Bloom wrote:
> > Hello all,
> >
> > Vijay noted in another thread that:
> > "For RTEMS, I don't see any preference mentioned in the docs for the
> > order or includes:
> > https://docs.rtems.org/branches/master/eng/coding-conventions.html
> >
> > In libbsd, however, the FreeBSD style guide is followed which has a
> > preference for the order of header includes:
> > https://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9";
> >
> > Should we consider any rules? I would suspect that at least ordering
> > by API layering could be helpful. Lexical sorting is nice but probably
> > there will be some exceptions based on dependencies.
>
> I would use the Google rule:
>
>
> https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
>
> It is compatible to the FreeBSD style (except the include related header
> first).
>

FWIW I don't like how they worded that. I think they mean the public header
files.
Related would include private header files which are grouped later. But the
rationale
makes sense as long as there isn't a conditional for "inside the package"
which covers
up issues.

There is also the issue of defining conditionals like POSIX level, GNU
misc,
IN_KERNEL, etc.. I try to do that before any includes.

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

.rtemsstack location on ARM

2020-01-08 Thread Will

I've been working on a Cortex-M4 BSP and its Qemu model has some
peculiarities requiring me to relocate the vector table to the end of the
available storage, at least temporarily. In the process of doing this, I
noticed that .rtemsstack is placed in REGION_VECTOR in the shared
linkcmds.base instead of REGION_WORK like it is for or1k and epiphany. This
complicates relocation of the vector table a bit and while I can hack
around it for now, I was wondering if this was intentional on ARM.

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

Pi Zero Automated Testing/TFTP/Uboot

Hi

Can the Pi Zero boot with TFTP like the wired versions? We are wondering as
this is how the automated testing for the Pi's is done.

We are hoping to setup at least one Pi from each basic generation (1, 2, 3,
4, and Zero) for automated testing.

Thanks.

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

Re: Raspberry Pi test report

2020-01-08 Thread Alan Cudmore

The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32 bit
for both the Pi 3 and 4, so I would think 32 bit ports would run on both.
The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4 SDRAM,
Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not looked into it
enough to see what UARTs it uses.

On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 08/01/2020 00:24, Joel Sherrill wrote:
> >
> >
> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer  > > wrote:
> >
> > Hello Alan,
> >
> > I pushed the patches mentioned further below. So the raspberry BSP
> > should now work again for all raspberry 1 and 2 on the official
> master
> > branch. Note that the
> >
> > kernel_address=0x20
> >
> > is still necessary.
> >
> >
> > This is awesome work. What about the Pi 3 and and Pi 4?  I think Niteesh
> > has the Pi 3 working so that leaves the 4. Any idea?
> >
> > --joel
> >
>
> As far as I followed his work Niteesh had some minimal version working
> with the mini UART and thought about trying the existing NS16550 (after
> I suggested that one). But I haven't seen a patch yet. So currently even
> if some basic stuff runs there will be no console.
>
> Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any
> experience with aarch64. Therefore I'm not sure whether we can safely
> use them with 32Bit fallback. It seems to work to some extend but
> according to
>
> https://en.wikipedia.org/wiki/ARM_architecture#AArch64
>
> "ARMv8-A allows 32-bit applications to be executed in
>  a 64-bit OS, and a 32-bit OS to be under the control
>  of a 64-bit hypervisor."
>
> So I'm not sure in which situations we will run into problems. Maybe on
> interrupts?
>
> Best regards
>
> Christian
>
> >
> > Best regards
> >
> > Christian
> >
> > On 06/01/2020 11:10, Christian Mauderer wrote:
> > > Hello Alan,
> > >
> > > thanks for your very detailed tests.
> > >
> > > On 05/01/2020 23:42, Alan Cudmore wrote:
> > >> I finally found the time to try the latest RTEMS head on my
> > collection
> > >> of Raspberry Pi models.
> > >> The last time I tried to run RTEMS on a Pi, I had trouble with the
> > >> current version of the Raspberry Pi Firmware, so I had to go back
> > to a
> > >> specific tag on the Rasberry Pi firmware repository to get RTEMS
> to
> > >> work. This time, the head of the firmware repository seems to
> > work (at
> > >> least on the single core models)
> > >>
> > >> To keep things simple, I'm just going address the single core
> models
> > >> here, I can follow up after I finish testing the Raspberry Pi 2.
> > >>
> > >> Test Setup:
> > >> I used the git.rtems.org 
> >  rtems master from Jan 03
> > >> 2020.
> > >> I used the Raspberry Pi firmware from the same date.
> > >> The firmware can be found here:
> > >> https://github.com/raspberrypi/firmware/tree/master/boot
> > >> To boot an RTEMS image, you can copy all files from the above
> "boot"
> > >> directory on a DOS formatted SD/MicroSD card along with the RTEMS
> > image
> > >> (more about that in a minute).
> > >> On the SD card, I deleted the "dtb" files, as well as the overlay
> > >> directory. I dont think these are necessary to boot an RTEMS
> image.
> > >>
> > >> I built a new arm-rtems5 toolchain using the RSB tool (head from
> the
> > >> same date) and built the "raspberrypi" BSP. After a quick test
> > failed, I
> > >> reviewed the latest mailing list posts, and ended up applying the
> > linker
> > >> script patch:
> > >> https://lists.rtems.org/pipermail/devel/2019-December/056551.html
> > >
> > > I don't think that we will apply that patch. It moves code in an
> area
> > > that is protected against access to catch null pointer accesses
> later.
> > > This increases the image size.
> > >
> > > The alternative is to add the line
> > >
> > > kernel_address=0x20
> > >
> > > to the config.txt of the raspberry SD image. Niteesh is in the
> process
> > > of documenting this:
> > >
> > >
> https://lists.rtems.org/pipermail/devel/2020-January/056796.html
> > >
> > >>
> > >> After applying this patch and rebuilding, a few RTEMS samples
> > seemed to
> > >> work fine on the Raspberry Pi Zero Models 1.2 and 1.3 (no
> > wireless). I
> > >> ran hello.exe, ticker.exe, and unlimited.exe
> > >>
> > >> The above images must be prepared using the following command:
> > >> $ arm-rtems5-objcopy -Obinary ticker.exe kernel.img
> > >> Then I copied kernel.img over the linux kernel on the SD card.
> > >>
> > >> For all of these tests, I found this serial to USB board to be
> very
> > >> useful

Use specification items to generate documentation


Hello,

for the RTEMS pre-qualification activity we need a specification of 
RTEMS. I would like to use this opportunity to move structured 
information which is present in hand written and hand formatted content 
in the RTEMS documentation into a structured data format (YAML). 
Documentation source files can be generated from the YAML files. Having 
information available in an easily machine readable format with 
meta-information gives us a lot of flexibility. For example to adjust 
the presentation we just have to change the generator program and not 
the hand written content. The presentation of things may depend on the 
standard of interest, e.g. ECSS, IEC 61508, ISO 26262, DO-178C, etc.


To get started, I would like to use the glossary of terms and the 
application configuration as a use case. The conversion from hand 
written and hand formatted content to generated content needs three things:


1. A definition of the data format (YAML with Doorstop attributes)

2. The specification items in the defined data format.

3. A generator program which uses the specification items as input and 
outputs the documentation source files.


The new build system introduced build specification items in the RTEMS 
sources under "spec/build". I would like to place all of the RTEMS 
specification under the "spec" directory. For the glossary I propose to 
use "spec/glossary". For the application configuration categories I 
propose "spec/cfg" and for the application configuration options 
"spec/cfg/opt". The layout of the application configuration items 
enables an easy reassignment of options to categories.


The definition of the data format should be added to the RTEMS Software 
Engineering manual to the Software Requirements Engineering chapter.


The generator program should be written in Python and placed into the 
rtems-tools repository. The generator program needs paths to the RTEMS 
sources and the RTEMS documentation sources. The paths should be 
specified via the command line.


For a proof-of-concept please have a look at the attached two patches.

What do you think of it?

--
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.
>From cfaad1b7feb8fae9dc89ffe7d245a231e9e55c7d Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Tue, 10 Dec 2019 14:40:08 +0100
Subject: [PATCH 1/2] spec/cfg: Add application configuration

Update #3836.
---
 rtems-to-x.py  | 194 +
 spec/RTEMS-CONFIG.yml  |  14 ++
 spec/cfg/.doorstop.yml |  12 ++
 spec/cfg/RTEMS-CFG-GENERAL.yml |  14 ++
 spec/cfg/opt/.doorstop.yml |  13 ++
 spec/cfg/opt/RTEMS-CFG-OPT-EXTRATASKSTACKS.yml |  31 
 6 files changed, 278 insertions(+)
 create mode 100755 rtems-to-x.py
 create mode 100644 spec/RTEMS-CONFIG.yml
 create mode 100644 spec/cfg/.doorstop.yml
 create mode 100644 spec/cfg/RTEMS-CFG-GENERAL.yml
 create mode 100644 spec/cfg/opt/.doorstop.yml
 create mode 100644 spec/cfg/opt/RTEMS-CFG-OPT-EXTRATASKSTACKS.yml

diff --git a/rtems-to-x.py b/rtems-to-x.py
new file mode 100755
index 00..6ea44a7862
--- /dev/null
+++ b/rtems-to-x.py
@@ -0,0 +1,194 @@
+#!/usr/bin/env python
+
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (C) 2019 embedded brains GmbH
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+from __future__ import print_function
+
+import os
+import stat
+import yaml
+
+
+class Item(object):
+item

Re: sptests/sp19/Makefile in git?


On 03/01/2020 19:52, Gedare Bloom wrote:

OK must be something that got leftover on my filesystem during
bootstrapping and switching branches between 4.10 and master. Sorry
about the noise.


No, I added this file recently do document how the sptest.adb is generated:

https://git.rtems.org/rtems/commit/?id=ae716da79fe549c403cd2fcf4c221a9a57bf7b20

I didn't take the bootstrap command into account. I hope we will be able 
to remove it after the merge of the new build system.


--
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: Coding Convention: Sorting Order of Includes?