Re: Glossary of Terms

2020-01-07 Thread Sebastian Huber

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


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

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

Re: [PATCH v3] eng: Add Software Requirements Engineering chapter

2020-01-07 Thread Sebastian Huber

Hello,

I checked in now the first version of this new chapter.

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

[PATCH 4/4] eng: Add glossary

2020-01-07 Thread Sebastian Huber
Generated by "./waf regenerate".

Update #3715.
---
 eng/glossary.rst | 39 +++
 eng/index.rst|  1 +
 eng/wscript  |  2 +-
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 eng/glossary.rst

diff --git a/eng/glossary.rst b/eng/glossary.rst
new file mode 100644
index 000..5f3b759
--- /dev/null
+++ b/eng/glossary.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Automatically generated by "./waf regenerate"
+
+Glossary
+
+
+.. glossary::
+   :sorted:
+
+   ABI
+  An accronym for Application Binary Interface.
+   API
+  An acronym for Application Programming Interface.
+   CCB
+  An acronym for Change Control Board.
+   Doorstop
+  `Doorstop `_ is a
+  requirements management tool.
+   EARS
+  An acronym for Easy Approach to Requirements Syntax.
+   GNAT
+  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
+  :term:`GCC`.
+   ISVV
+  An acronym for Independent Software Verification and Validation.
+   ReqIF
+  An abbreviation for
+  `Requirements Interchange Format 
`_.
+   software item
+  See :term:`software product`.
+   source code
+  This project uses the *source code* definition of the
+  `Linux Information Project `_:
+  "Source code (also referred to as source or code) is the version of
+  software as it is originally written (i.e., typed into a computer) by a
+  human in plain text (i.e., human readable alphanumeric characters)."
+   YAML
+  An acronym for `YAML Ain't Markup Language `_.
diff --git a/eng/index.rst b/eng/index.rst
index ed314a9..a317727 100644
--- a/eng/index.rst
+++ b/eng/index.rst
@@ -37,4 +37,5 @@ RTEMS Software Engineering (|version|)
 appendix-a
 function_and_variable
 concept
+glossary
 zreferences
diff --git a/eng/wscript b/eng/wscript
index 6bbe351..7ef6896 100644
--- a/eng/wscript
+++ b/eng/wscript
@@ -5,4 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
-from common.waf import cmd_regenerate
+from common.glossary import cmd_regenerate
-- 
2.16.4

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


[PATCH 2/4] common: Add script to generate glossary

2020-01-07 Thread Sebastian Huber
Update #3853.
---
 common/glossary.py | 121 +
 1 file changed, 121 insertions(+)
 create mode 100755 common/glossary.py

diff --git a/common/glossary.py b/common/glossary.py
new file mode 100755
index 000..1353853
--- /dev/null
+++ b/common/glossary.py
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: BSD-2-Clause
+#
+# Copyright (C) 2020 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.
+
+import re
+
+class Term(object):
+terms = {}
+
+def __init__(self, terms, definition):
+self.terms = terms
+self.definition = definition
+for t in terms:
+Term.terms[t] = self
+
+def __cmp__(self, other):
+for t in other.terms:
+if t in self.terms:
+return 0
+if self.terms[0].lower() < other.terms[0].lower():
+return -1
+return 1
+
+def __hash__(self):
+return hash(self.terms[0])
+
+def __str__(self):
+return "   " + "\n   ".join(self.terms) + "\n" + self.definition
+
+class State(object):
+def next(self, line):
+assert 0
+
+class GlossaryTermDefinition(State):
+def __init__(self, indent, term):
+self.indent = indent
+self.terms = [term]
+self.definition = ""
+
+def next(self, line):
+m = re.search("^\\s{" + "{}".format(self.indent) + "}(\\w.*)$", line)
+if m:
+self.terms.append(m.group(1))
+return self
+m = re.search(r"^\s+(.+)$", line)
+if m:
+self.definition += line
+return self
+m = re.search(r"^\s*$", line)
+if m:
+Term(self.terms, self.definition)
+return GlossaryTerm()
+raise Exception("unexpected term definition: {}".format(line))
+
+class GlossaryTerm(State):
+def next(self, line):
+m = re.search(r"^(\s+)(.*)$", line)
+if m:
+return GlossaryTermDefinition(len(m.group(1)), m.group(2))
+m = re.search(r"^\s*$", line)
+if m:
+return self
+raise Exception("unexpected term: {}".format(line))
+
+class GlossaryOptions(State):
+def next(self, line):
+m = re.search(r"^\s+:", line)
+if m:
+return self
+m = re.search(r"^\s*$", line)
+if m:
+return GlossaryTerm()
+raise Exception("unexpected glossary option: {}".format(line))
+
+class GlossaryInitial(State):
+def next(self, line):
+if line.strip() == ".. glossary::":
+return GlossaryOptions()
+return self
+
+def cmd_regenerate(ctx):
+with open(ctx.path.abspath() + "/../c-user/glossary.rst", "r") as f:
+s = GlossaryInitial()
+for line in f:
+s = s.next(line)
+terms = set()
+for src in ctx.path.ant_glob("**/*.rst"):
+if src.abspath().endswith("glossary.rst"):
+continue
+for t in re.findall(":term:`[^`]+`", src.read()):
+term = re.search("`([^`]+)`", re.sub("\s+", " ", t)).group(1)
+terms.add(Term.terms[term])
+c = ".. SPDX-License-Identifier: CC-BY-SA-4.0\n\n"
+c += ".. Automatically generated by \"./waf regenerate\"\n\n"
+c += "Glossary\n\n\n"
+c += ".. glossary::\n   :sorted:\n\n"
+for t in sorted(terms):
+c += str(t)
+g = ctx.path.make_node("glossary.rst")
+g.write(c)
-- 
2.16.4

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


[PATCH 0/4] Add support for document-specific glossaries

2020-01-07 Thread Sebastian Huber
Sebastian Huber (4):
  common: Add waf regenerate target
  common: Add script to generate glossary
  c-user: Add glossary entries for "eng"
  eng: Add glossary

 bsp-howto/wscript|   1 +
 c-user/glossary.rst  |  40 
 c-user/wscript   |   1 +
 common/glossary.py   | 121 +++
 common/waf.py|   8 
 cpu-supplement/wscript   |   1 +
 develenv/wscript |   1 +
 eclipse/wscript  |   1 +
 eng/glossary.rst |  39 +++
 eng/index.rst|   1 +
 eng/wscript  |   1 +
 filesystem/wscript   |   1 +
 networking/wscript   |   1 +
 porting/wscript  |   1 +
 posix-compliance/wscript |   1 +
 posix-users/wscript  |   1 +
 rtemsconfig/wscript  |   1 +
 shell/wscript|   1 +
 user/wscript |   1 +
 wscript  |   4 ++
 20 files changed, 227 insertions(+)
 create mode 100755 common/glossary.py
 create mode 100644 eng/glossary.rst

-- 
2.16.4

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


[PATCH 3/4] c-user: Add glossary entries for "eng"

2020-01-07 Thread Sebastian Huber
Update #3715.
---
 c-user/glossary.rst | 40 
 1 file changed, 40 insertions(+)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 5a2e6db..2720b21 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -6,6 +6,9 @@ Glossary
 .. glossary::
:sorted:
 
+   ABI
+  An accronym for Application Binary Interface.
+
active
   A term used to describe an object which has been created by an
   application.
@@ -80,6 +83,9 @@ Glossary
   the passing of arguments, the call and return mechanism, and the register
   set which must be preserved.
 
+   CCB
+  An acronym for Change Control Board.
+
Central Processing Unit
   This term is equivalent to the terms processor and microprocessor.
 
@@ -148,6 +154,10 @@ Glossary
   The act of loading a task's context onto the CPU and transferring control
   of the CPU to that task.
 
+   Doorstop
+  `Doorstop `_ is a
+  requirements management tool.
+
dormant
   The state entered by a task after it is created and before it has been
   started.
@@ -160,6 +170,9 @@ Glossary
   A term used to describe memory which can be accessed at two different
   addresses.
 
+   EARS
+  An acronym for Easy Approach to Requirements Syntax.
+
embedded
   An application that is delivered as a hidden part of a larger system.
   For example, the software in a fuel-injection control system is an
@@ -218,6 +231,10 @@ Glossary
   An object that has been created with the GLOBAL attribute and exported to
   all nodes in a multiprocessor system.
 
+   GNAT
+  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
+  :term:`GCC`.
+
handler
   The equivalent of a manager, except that it is internal to RTEMS and
   forms part of the core.  A handler is a collection of routines which
@@ -279,6 +296,9 @@ Glossary
ISR
   An acronym for Interrupt Service Routine.
 
+   ISVV
+  An acronym for Independent Software Verification and Validation.
+
kernel
   In this document, this term is used as a synonym for executive.
 
@@ -538,6 +558,10 @@ Glossary
   The manipulation of an object which does not reside on the same node as
   the calling task.
 
+   ReqIF
+  An abbreviation for
+  `Requirements Interchange Format 
`_.
+
return code
   Also known as error code or return value.
 
@@ -640,6 +664,19 @@ Glossary
   A real-time system in which a missed deadline does not compromise the
   integrity of the system.
 
+   software item
+  See :term:`software product`.
+
+   software product
+  The *software product* is the :term:`RTEMS` real-time operating system.
+
+   source code
+  This project uses the *source code* definition of the
+  `Linux Information Project `_:
+  "Source code (also referred to as source or code) is the version of
+  software as it is originally written (i.e., typed into a computer) by a
+  human in plain text (i.e., human readable alphanumeric characters)."
+
sporadic task
   A task which executes at irregular intervals and must comply with a hard
   deadline.  A minimum period of time between successive iterations of the
@@ -770,5 +807,8 @@ Glossary
   Message queues, regions, and semaphores have a wait queue associated with
   them.
 
+   YAML
+  An acronym for `YAML Ain't Markup Language `_.
+
yield
   When a task voluntarily releases control of the processor.
-- 
2.16.4

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


[PATCH 1/4] common: Add waf regenerate target

2020-01-07 Thread Sebastian Huber
Update #3853.
---
 bsp-howto/wscript| 1 +
 c-user/wscript   | 1 +
 common/waf.py| 8 
 cpu-supplement/wscript   | 1 +
 develenv/wscript | 1 +
 eclipse/wscript  | 1 +
 eng/wscript  | 1 +
 filesystem/wscript   | 1 +
 networking/wscript   | 1 +
 porting/wscript  | 1 +
 posix-compliance/wscript | 1 +
 posix-users/wscript  | 1 +
 rtemsconfig/wscript  | 1 +
 shell/wscript| 1 +
 user/wscript | 1 +
 wscript  | 4 
 16 files changed, 26 insertions(+)

diff --git a/bsp-howto/wscript b/bsp-howto/wscript
index 4063cd4..6bbe351 100644
--- a/bsp-howto/wscript
+++ b/bsp-howto/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/c-user/wscript b/c-user/wscript
index 4063cd4..6bbe351 100644
--- a/c-user/wscript
+++ b/c-user/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/common/waf.py b/common/waf.py
index 066048d..8535ff6 100644
--- a/common/waf.py
+++ b/common/waf.py
@@ -71,6 +71,9 @@ def cmd_linkcheck(ctx):
 target = "linkcheck/output.txt"
 )
 
+def cmd_regenerate(ctx):
+pass
+
 class spell(BuildContext):
 __doc__ = "Check spelling.  Supply a list of files or a glob (*.rst)"
 cmd = 'spell'
@@ -81,6 +84,11 @@ class linkcheck(BuildContext):
 cmd = 'linkcheck'
 fun = 'cmd_linkcheck'
 
+class regenerate(BuildContext):
+__doc__ = "Regenerate files."
+cmd = 'regenerate'
+fun = 'cmd_regenerate'
+
 def check_sphinx_version(ctx, minver):
 try:
 import sphinx
diff --git a/cpu-supplement/wscript b/cpu-supplement/wscript
index 4063cd4..6bbe351 100644
--- a/cpu-supplement/wscript
+++ b/cpu-supplement/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/develenv/wscript b/develenv/wscript
index 4063cd4..6bbe351 100644
--- a/develenv/wscript
+++ b/develenv/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/eclipse/wscript b/eclipse/wscript
index 4063cd4..6bbe351 100644
--- a/eclipse/wscript
+++ b/eclipse/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/eng/wscript b/eng/wscript
index 4063cd4..6bbe351 100644
--- a/eng/wscript
+++ b/eng/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/filesystem/wscript b/filesystem/wscript
index 4063cd4..6bbe351 100644
--- a/filesystem/wscript
+++ b/filesystem/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/networking/wscript b/networking/wscript
index 4063cd4..6bbe351 100644
--- a/networking/wscript
+++ b/networking/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/porting/wscript b/porting/wscript
index 4063cd4..6bbe351 100644
--- a/porting/wscript
+++ b/porting/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/posix-compliance/wscript b/posix-compliance/wscript
index 01fcf4b..e904683 100644
--- a/posix-compliance/wscript
+++ b/posix-compliance/wscript
@@ -5,6 +5,7 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
 
 import posix_rst
 
diff --git a/posix-users/wscript b/posix-users/wscript
index 4063cd4..6bbe351 100644
--- a/posix-users/wscript
+++ b/posix-users/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from common.waf import linkcheck
 from common.waf import cmd_linkcheck
+from common.waf import cmd_regenerate
diff --git a/rtemsconfig/wscript b/rtemsconfig/wscript
index 4063cd4..6bbe351 100644
--- a/rtemsconfig/wscript
+++ b/rtemsconfig/wscript
@@ -5,3 +5,4 @@ from common.waf import spell
 from common.waf import cmd_spell
 from

Re: Glossary of Terms

2020-01-07 Thread Gedare Bloom
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:.)

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

Re: [PATCH] bsp/raspberrypi: Enable FDT support.

2020-01-07 Thread Christian Mauderer
Pushed. Thanks.

On 03/01/2020 04:26, G S Niteesh wrote:
> This commit adds FDT support to the BSP.
> ---
>  bsps/arm/raspberrypi/include/bsp.h|  4 
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |  1 +
>  c/src/lib/libbsp/arm/raspberrypi/configure.ac | 13 +
>  3 files changed, 18 insertions(+)
> 
> diff --git a/bsps/arm/raspberrypi/include/bsp.h 
> b/bsps/arm/raspberrypi/include/bsp.h
> index 1075cb1771..b81d19cd76 100644
> --- a/bsps/arm/raspberrypi/include/bsp.h
> +++ b/bsps/arm/raspberrypi/include/bsp.h
> @@ -41,6 +41,10 @@ extern "C" {
>  
>  #define BSP_FEATURE_IRQ_EXTENSION
>  
> +#if BSP_START_COPY_FDT_FROM_U_BOOT
> +#define BSP_FDT_IS_SUPPORTED
> +#endif
> +
>  #define RPI_L2_CACHE_ENABLE 1
>  
>  #define BSP_GPIO_PIN_COUNT 32
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> index 11a22f89e3..77aa360977 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> @@ -45,6 +45,7 @@ librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/shared/start/sbrk.c
>  librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/stackalloc.c
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/arm/shared/start/bsp-start-memcpy.S
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> +librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/bsp-fdt.c
>  
>  # Startup
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/arm/raspberrypi/start/bspstart.c
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/configure.ac 
> b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> index 452aa4d029..b1aa0bf417 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> +++ b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
> @@ -15,6 +15,19 @@ RTEMS_CANONICAL_TARGET_CPU
>  AM_INIT_AUTOMAKE([no-define nostdinc foreign 1.12.2])
>  RTEMS_BSP_CONFIGURE
>  
> +RTEMS_BSPOPTS_SET([BSP_START_COPY_FDT_FROM_U_BOOT],[*],[1])
> +RTEMS_BSPOPTS_HELP([BSP_START_COPY_FDT_FROM_U_BOOT],[copy the U-Boot 
> provided FDT to an internal storage])
> +
> +RTEMS_BSPOPTS_SET([BSP_FDT_BLOB_SIZE_MAX],[*],[262144])
> +RTEMS_BSPOPTS_HELP([BSP_FDT_BLOB_SIZE_MAX],[maximum size of the FDT blob in 
> bytes])
> +
> +RTEMS_BSPOPTS_SET([BSP_FDT_BLOB_READ_ONLY],[*],[1])
> +RTEMS_BSPOPTS_HELP([BSP_FDT_BLOB_READ_ONLY],[place the FDT blob into the 
> read-only data area])
> +
> +RTEMS_BSPOPTS_SET([BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA],[*],[1])
> +RTEMS_BSPOPTS_HELP([BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA],[copy the FDT 
> blob into the read-only load area via bsp_fdt_copy()])
> +
> +
>  RTEMS_BSPOPTS_SET([BSP_START_RESET_VECTOR],[*],[])
>  RTEMS_BSPOPTS_HELP([BSP_START_RESET_VECTOR],[reset vector address for BSP 
> start])
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

2020-01-07 Thread Christian Mauderer
Pushed with a minor modification: Due to the header reorder it was
necessary to include one extra header in bsp/fbcons.h. But that has been
a hidden bug anyway.

On 04/01/2020 20:50, G S Niteesh wrote:
> Replaces the legacy termios API with new termios API (#3034)
> Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> Update #3034
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 143 +++
>  bsps/arm/raspberrypi/console/console_select.c | 114 
>  bsps/arm/raspberrypi/console/fbcons.c |  78 
>  bsps/arm/raspberrypi/console/usart.c  | 167 --
>  bsps/arm/raspberrypi/include/bsp.h|   2 +
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
>  10 files changed, 197 insertions(+), 404 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> 
> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..48c4c6a3ec 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,133 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  
>  #include 
> +#include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &bcm2835_usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &fbcons_fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> +
> +#define UART0 "/dev/ttyS0"
> +#define FBCONS"/dev/fbcons"
> +
> +arm_pl011_context pl011_context;
> +
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(&pl011_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(&fb_context.base, c);
> +}
> +
> +static void init_ctx_arm_pl011(
> +  const void *fdt,
> +  int node
> +)
> +{
> +  arm_pl011_context *ctx = &pl011_context;
> +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> +}
> +
> +static void register_fb( void )
> +{
> +  if (fbcons_probe(&fb_context.base) == true) {
> +rtems_termios_device_install(
> +  FBCONS,
> +  &fbcons_fns,
> +  NULL,
> +  &fb_context.base);
> +  }
> +}
> +
> +static void console_select( void )
> +{
> +  const char *opt;
> +
> +  opt = rpi_cmdline_get_arg("--console=");
> +
> +  if ( opt ) {
> +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> +  if ( rpi_video_is_initialized() > 0 ) {
> +BSP_output_char = output_char_fb;
> +link(FBCONS, CONSOLE_DEVICE_NAME);
> +return ;
> +  }
> +}
> +  }
> +  BSP_output_char = output_char_serial;
> +  link(UART0, CONSOLE_DEVICE_NAME);
> +}
> +
> +static void uart_probe(void)
> +{
> +  static bool initialized = false;
> +  const void *fdt;
> +  int node;
> +
> +  if ( initialized ) {
> +return ;
> +  }
> +
> +  fdt = bsp_fdt_get();
> +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
> +
> +  init_ctx_arm_pl011(fdt, node);
> +
> +  initialized = true;
> +}
>  
>  static void output_char(char c)
>  {
> -  const console_fns *con =
> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> +  uart_probe();
> +  output_char_serial(c);
> +}
> +
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
>  
> -  con->deviceWritePolled((int) Console_Port_Minor, c);
> +  uart_probe();
> +  rtems_termios_device_install(
> +UART0,
> +&arm_pl011_fns,
> +NULL,
> +&pl011_context.base
> +  );
> +
> +  register_fb();
> +
> +  console_select();
> +
> +  return RTEMS_SUCCESSFUL;
>  }
>  
>  BSP_output_char_function_type BSP_output_char = output_char;
>  
>  BSP_polling_getchar_function_type BSP_poll_char = NULL;
> +
> +RTEMS_SYSINIT_ITEM(
> +  uart_probe,
> +  RTEMS_SYSINIT_BSP_START,
> +  RT

Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

2020-01-07 Thread Niteesh
Great, thank you it wouldn't have been possible without your help and
support.
And thanks for patiently answering my questions :)

On Tue, Jan 7, 2020 at 10:58 PM Christian Mauderer 
wrote:

> Pushed with a minor modification: Due to the header reorder it was
> necessary to include one extra header in bsp/fbcons.h. But that has been
> a hidden bug anyway.
>
> On 04/01/2020 20:50, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 143 +++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 197 insertions(+), 404 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..48c4c6a3ec 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,133 @@
> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> >
> >  #include 
> > +#include 
> >
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +
> > +#define UART0 "/dev/ttyS0"
> > +#define FBCONS"/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> > +
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = &pl011_context;
> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(&fb_context.base) == true) {
> > +rtems_termios_device_install(
> > +  FBCONS,
> > +  &fbcons_fns,
> > +  NULL,
> > +  &fb_context.base);
> > +  }
> > +}
> > +
> > +static void console_select( void )
> > +{
> > +  const char *opt;
> > +
> > +  opt = rpi_cmdline_get_arg("--console=");
> > +
> > +  if ( opt ) {
> > +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> > +  if ( rpi_video_is_initialized() > 0 ) {
> > +BSP_output_char = output_char_fb;
> > +link(FBCONS, CONSOLE_DEVICE_NAME);
> > +return ;
> > +  }
> > +}
> > +  }
> > +  BSP_output_char = output_char_serial;
> > +  link(UART0, CONSOLE_DEVICE_NAME);
> > +}
> > +
> > +static void uart_probe(void)
> > +{
> > +  static bool initialized = false;
> > +  const void *fdt;
> > +  int node;
> > +
> > +  if ( initialized ) {
> > +return ;
> > +  }
> > +
> > +  fdt = bsp_fdt_get();
> > +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
> > +
> > +  init_ctx_arm_pl011(fdt, node);
> > +
> > +  initialized = true;
> > +}
> >
> >  static void output_char(char c)
> >  {
> > -  const console_fns *con =
> > -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> > +  uart_probe();
> > +  output_char_serial(c);
> > +}
> > +
> > +rtems_status_code console_initialize(
> > +  rtems_device_major_number major,
> > +  rtems_device_minor_number minor,
> > +  void *arg
> > +)
> > +{
> > +  rtems_termios_initializ

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

2020-01-07 Thread Niteesh
I didn't use the QEMU build from RSB, I built it from the source directly
for another project
I'll try QEMU from RSB, and will also add instructions for it in a couple
of days.

On Tue, Jan 7, 2020 at 1:00 AM Gedare Bloom  wrote:

> On Mon, Jan 6, 2020 at 11:25 AM Niteesh  wrote:
> >
> > Do you want to add a build section or just add in a statement that
> states "it was built
> > using xx version of RSB"?
> >
>
> Just a simple statement. Don't even  need to mention a specific
> version, if they use RSB to build QEMU it should just work, right?
>
> > On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer 
> wrote:
> >> >
> >> > Looks a lot better.
> >> >
> >> > On 05/01/2020 20:19, G S Niteesh wrote:
> >> > > Added instructions to run examples on raspberrypi.
> >> > > ---
> >> > >  user/bsps/arm/raspberrypi.rst | 74
> ++-
> >> > >  1 file changed, 73 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> >> > > index 4ef75bd..7eccca5 100644
> >> > > --- a/user/bsps/arm/raspberrypi.rst
> >> > > +++ b/user/bsps/arm/raspberrypi.rst
> >> > > @@ -5,4 +5,76 @@
> >> > >  raspberrypi
> >> > >  ===
> >> > >
> >> > > -TODO.
> >> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
> >> > > +The support for `Raspberry Pi 3` is work under progress.
> >> > > +The default bootloader on the raspberrypi which is used to boot
> raspbian
> >> >
> >> > raspberrypi -> Raspberry Pi
> >> > raspbian -> Raspbian
> >> >
> >> > > +or other OS can be also used to boot RTEMS. U-boot can also be
> used.
> >> > > +
> >> > > +Setup SD card
> >> > > +
> >> > > +
> >> > > +The Raspberry Pis have an unconventional booting mechanism. The GPU
> >> > > +boots first, initializes itself, runs the bootloader and starts
> the CPU.
> >> > > +The bootloader looks for a kernel image, by default the kernel
> images must
> >> > > +have a name of the form `kernel*.img` but this can be changed by
> adding
> >> >
> >> > Please highlight all files in the same way. Other BSPs use the
> following
> >> > syntax:
> >> >
> >> > The ``ticker.exe`` elf file must be translated ...
> >> >
> >> > So here it is:
> >> >
> >> > `kernel*.img` -> ``kernel*.img``
> >> >
> >> > > +`kernel=` to config.txt.
> >> >
> >> > config.txt -> ``config.txt``
> >> >
> >> > > +
> >> > > +You must provide the required files for the GPU to proceed. These
> files
> >> > > +can be downloaded from this
> >> > > +`link  >`_.
> >> >
> >> > I would suggest:
> >> >
> >> > ... can be downloaded from
> >> > `the Raspberry Pi Firmware Repository
> >> > `_.
> >> >
> >> > I think you shouldn't break links so if this is too long you can
> >> > exceptionally break the 80 character rule. It's done for other links
> too.
> >> >
> >> > > +You can remove the kernel*.img if you want, but don't touch the
> other files.
> >> >
> >> > kernel*.img -> ``kernel*.img``
> >> >
> >> > > +
> >> > > +Copy these files in to a SD card with FAT filesystem.
> >> > > +
> >> > > +Kernel image
> >> > > +
> >> > > +
> >> > > +The following steps show how to run hello.exe on a Raspberry Pi 2.
> >> >
> >> > hello.exe -> ``hello.exe``
> >> >
> >> > > +The same instructions can be applied to Raspberry Pi 1 also.
> >> > > +Other executables can be processed in a similar way.
> >> > > +
> >> > > +To create the kernel image:
> >> > > +
> >> > > +.. code-block:: none
> >> > > +
> >> > > + arm-rtems5-objcopy -Obinary hello.exe kernel.img
> >> > > +
> >> > > +Copy the kernel image to the SD card.
> >> > > +
> >> > > +Make sure you have these lines below in your config.txt.
> >> > > +
> >> > > +.. code-block:: none
> >> > > +
> >> > > + enable-uart=1
> >> > > + kernel_address=0x20
> >> > > + kernel=kernel.img
> >> > > +
> >> > > +Testing
> >> > > +---
> >> >
> >> > Maybe change that chapter to "Emulation" or "Testing using QEMU". When
> >> > reading I had expected a hardware setup in this chapter after the
> >> > SD-card has been prepared in the previous one.
> >> >
> >> > > +
> >> > > +Qemu along with GDB can be used for debugging, but it only supports
> >> >
> >> > Please always use the capitalization that the project uses. In this
> case:
> >> >
> >> > Qemu -> QEMU
> >> >
> >> > > +``Raspberry Pi 2`` and the emulation is also incomplete. So some
> of the
> >> >
> >> > Again: One formatting for one phrase. So that would be:
> >> >
> >> > ``Raspberry Pi 2`` -> Raspberry Pi 2
> >> >
> >> > > +features might not work as expected.
> >> > > +
> >> > > +Make sure you have latest version of qemu, because older ones
> don't support
> >> >
> >> > qemu -> QEMU
> >> >
> >> My only other comment is if this version is built by RSB already it is
> >> worth mentioning here.
> >>
> >> > > +Raspb

Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

2020-01-07 Thread Niteesh
You said that the FB was not working, was it because of this bug?
or else I want to take a look at it.

On Tue, Jan 7, 2020 at 11:03 PM Niteesh  wrote:

> Great, thank you it wouldn't have been possible without your help and
> support.
> And thanks for patiently answering my questions :)
>
> On Tue, Jan 7, 2020 at 10:58 PM Christian Mauderer 
> wrote:
>
>> Pushed with a minor modification: Due to the header reorder it was
>> necessary to include one extra header in bsp/fbcons.h. But that has been
>> a hidden bug anyway.
>>
>> On 04/01/2020 20:50, G S Niteesh wrote:
>> > Replaces the legacy termios API with new termios API (#3034)
>> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
>> > Update #3034
>> > ---
>> >  bsps/arm/raspberrypi/console/console-config.c | 143 +++
>> >  bsps/arm/raspberrypi/console/console_select.c | 114 
>> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
>> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
>> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
>> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
>> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
>> >  10 files changed, 197 insertions(+), 404 deletions(-)
>> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>> >
>> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> > index d2186c918b..48c4c6a3ec 100644
>> > --- a/bsps/arm/raspberrypi/console/console-config.c
>> > +++ b/bsps/arm/raspberrypi/console/console-config.c
>> > @@ -19,50 +19,133 @@
>> >   */
>> >
>> >  #include 
>> > +#include 
>> > +#include 
>> >
>> >  #include 
>> > +#include 
>> >
>> >  #include 
>> > -#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> >
>> > -console_tbl Console_Configuration_Ports [] = {
>> > -{
>> > -  .sDeviceName = "/dev/ttyS0",
>> > -  .deviceType = SERIAL_CUSTOM,
>> > -  .pDeviceFns = &bcm2835_usart_fns,
>> > -  .deviceProbe = NULL,
>> > -  .pDeviceFlow = NULL,
>> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
>> > -  .ulCtrlPort2 = 0,
>> > -  .ulClock = USART0_DEFAULT_BAUD,
>> > -  .ulIntVector = BCM2835_IRQ_ID_UART
>> > -},
>> > -{
>> > -  .sDeviceName ="/dev/fbcons",
>> > -  .deviceType = SERIAL_CUSTOM,
>> > -  .pDeviceFns = &fbcons_fns,
>> > -  .deviceProbe = fbcons_probe,
>> > -  .pDeviceFlow = NULL,
>> > -},
>> > -};
>> > -
>> > -#define PORT_COUNT \
>> > -  (sizeof(Console_Configuration_Ports) \
>> > -/ sizeof(Console_Configuration_Ports [0]))
>> > -
>> > -unsigned long Console_Configuration_Count = PORT_COUNT;
>> > +
>> > +#define UART0 "/dev/ttyS0"
>> > +#define FBCONS"/dev/fbcons"
>> > +
>> > +arm_pl011_context pl011_context;
>> > +
>> > +rpi_fb_context fb_context;
>> > +
>> > +static void output_char_serial(char c)
>> > +{
>> > +  arm_pl011_write_polled(&pl011_context.base, c);
>> > +}
>> > +
>> > +void output_char_fb(char c)
>> > +{
>> > +  fbcons_write_polled(&fb_context.base, c);
>> > +}
>> > +
>> > +static void init_ctx_arm_pl011(
>> > +  const void *fdt,
>> > +  int node
>> > +)
>> > +{
>> > +  arm_pl011_context *ctx = &pl011_context;
>> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
>> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>> > +}
>> > +
>> > +static void register_fb( void )
>> > +{
>> > +  if (fbcons_probe(&fb_context.base) == true) {
>> > +rtems_termios_device_install(
>> > +  FBCONS,
>> > +  &fbcons_fns,
>> > +  NULL,
>> > +  &fb_context.base);
>> > +  }
>> > +}
>> > +
>> > +static void console_select( void )
>> > +{
>> > +  const char *opt;
>> > +
>> > +  opt = rpi_cmdline_get_arg("--console=");
>> > +
>> > +  if ( opt ) {
>> > +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
>> > +  if ( rpi_video_is_initialized() > 0 ) {
>> > +BSP_output_char = output_char_fb;
>> > +link(FBCONS, CONSOLE_DEVICE_NAME);
>> > +return ;
>> > +  }
>> > +}
>> > +  }
>> > +  BSP_output_char = output_char_serial;
>> > +  link(UART0, CONSOLE_DEVICE_NAME);
>> > +}
>> > +
>> > +static void uart_probe(void)
>> > +{
>> > +  static bool initialized = false;
>> > +  const void *fdt;
>> > +  int node;
>> > +
>> > +  if ( initialized ) {
>> > +return ;
>> > +  }
>> > +
>> > +  fdt = bsp_fdt_get();
>> > +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
>> > +
>> > +  init_ctx_arm_pl011(fdt, node);
>> > +
>> > +  initialized = true;
>> > +}
>> >
>> >  static void output_char(char c)
>> >  {
>> > -  const console_fns *con =

Re: [PATCH] Updated docs to use the standalone SIS simulator, instead of GDB inbuilt SIS for the erc32 BSP.

2020-01-07 Thread Christian Mauderer
Pushed. Thanks.

On 27/12/2019 13:01, G S Niteesh wrote:
> ---
>  user/start/bsp-test.rst |   4 +-
>  user/tools/tester.rst   | 144 
>  2 files changed, 132 insertions(+), 16 deletions(-)
> 
> diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
> index 5278375..aefeeb9 100644
> --- a/user/start/bsp-test.rst
> +++ b/user/start/bsp-test.rst
> @@ -21,7 +21,7 @@ Just run this command:
>  .. code-block:: none
>  
>  cd $HOME/quick-start/build/b-erc32
> -rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5 .
> +rtems-test --rtems-bsp=erc32-sis --rtems-tools=$HOME/quick-start/rtems/5 
> .
>  
>  This command should output something like this (omitted lines are denoted by
>  ...).  In this output the base directory :file:`$HOME/quick-start` was 
> replaced
> @@ -30,7 +30,7 @@ by ``$BASE``.
>  .. code-block:: none
>  
>  RTEMS Testing - Tester, 5.0.not_released
> - Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32 
> --rtems-tools=$BASE/rtems/5 .
> + Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32-sis 
> --rtems-tools=$BASE/rtems/5 .
>   Python: 2.7.15 (default, Jan 10 2019, 01:14:47) [GCC 4.2.1 Compatible 
> FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
>  Host: FreeBSD-12.0-RELEASE-p2-amd64-64bit-ELF (FreeBSD Build_FreeBSD12 
> 12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC amd64 amd64)
>  [  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
> sparc/erc32: dhrystone.exe
> diff --git a/user/tools/tester.rst b/user/tools/tester.rst
> index 609384b..c3c3fe2 100644
> --- a/user/tools/tester.rst
> +++ b/user/tools/tester.rst
> @@ -109,39 +109,155 @@ the tests. Using the run with the ERC32 BSP the 
> command is:
>  
>  The run command is the GDB simulator without the GDB part.
>  
> -Running the example using GDB:
> +Running the example using SIS:
> +
> +.. code-block:: none
> +
> +$ sparc-rtems5-sis 
> sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
> +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri Gaisler 
> 2019
> +Bug-reports to j...@gaisler.se
> +ERC32 emulation enabled
> +
> +Loaded sparc-rtems5/c/erc32/testsuites/samples/hello.exe, entry 
> 0x0200
> +
> +sis> run
> +
> +
> +*** BEGIN OF TEST HELLO WORLD ***
> +*** TEST VERSION: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> +*** TEST STATE: EXPECTED-PASS
> +*** TEST BUILD: RTEMS_POSIX_API
> +*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> +Hello World
> +
> +*** END OF TEST HELLO WORLD ***
> +
> +
> +*** FATAL ***
> +fatal source: 0 (INTERNAL_ERROR_CORE)
> +fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)
> +RTEMS version: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> +RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> +executing thread ID: 0x08a010001
> +executing thread name: UI1
> +cpu 0 in error mode (tt = 0x101)
> +116401  02009ae0:  91d02000   ta  0x0
> +
> +sis> q
> +
> +The examples can also be run using GDB with SIS as the backend. SIS can be 
> connected to
> +gdb through a network socket using the gdb remote interface.
> +
> +Either start SIS with ``-gdb``, or issue the ``gdb`` command inside SIS, and 
> connect
> +gdb with ``target remote:1234``. The default port is ``1234``, the port can 
> be changed
> +using the ``-port`` option.
> +
> +Open a terminal and issue the command:
> +
> +.. code-block:: none
> +
> +$ sparc-rtems5-sis -gdb
> +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri Gaisler 
> 2019
> +Bug-reports to j...@gaisler.se
> +ERC32 emulation enabled
> +
> +gdb: listening on port 1234
> +
> +Now open another terminal and issue the command:
>  
>  .. code-block:: none
>  
>  $ sparc-rtems5-gdb 
> sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
> -GNU gdb (GDB) 7.12
> -Copyright (C) 2016 Free Software Foundation, Inc.
> +GNU gdb (GDB) 8.3
> +Copyright (C) 2019 Free Software Foundation, Inc.
>  License GPLv3+: GNU GPL version 3 or later 
> 
>  This is free software: you are free to change and redistribute it.
> -There is NO WARRANTY, to the extent permitted by law.  Type "show 
> copying"
> -and "show warranty" for details.
> +There is NO WARRANTY, to the extent permitted by law.
> +Type "show copying" and "show warranty" for details.
>  This GDB was configured as "--host=x86_64-linux-gnu 
> --target=sparc-rtems5".
>  Type "show configuration" for configuration details.
>  For bug reporting instructions, please see:
>  .
>  Find the GDB manual and other documentation resources online at:
> -.
> +

Re: Raspberry Pi test report

2020-01-07 Thread Christian Mauderer
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.

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 in my tests:
>> https://www.adafruit.com/product/3589
>> It can power the pi through the USB cable and has a power switch as well.
>>
>> After the Pi Zero models, I tried my remaining older single core models:
>> 1. Raspberry Pi Model B ( Original single core model with 512MB of RAM
>> and 26 pin GPIO header)
>> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM
>> and 40 pin GPIO header)
>> 3. Raspberry Pi Model A+ (Smaller form factor single core model with
>> 256MB of RAM and 40 pin GPIO header)
>>    (Note this model has been updated to now have 512MB of RAM)
>>
>> All three of the above models had the same exception that has been
>> discussed on the mailing list:
>> https://lists.rtems.org/pipermail/devel/2019-December/056556.html
> 
> I addressed that issue in the following patch set:
> 
> https://lists.rtems.org/pipermail/devel/2019-December/056623.html
> https://lists.rtems.org/pipermail/devel/2019-December/056622.html
> https://lists.rtems.org/pipermail/devel/2019-December/056624.html
> 
> I'll push it in the next days together with patches regarding the
> console from Niteesh. I just gave it some more time for review during
> the public holidays.
> 
> Basically it addresses the issues that you describe below.
> 
>>
>> All of these single core models are supposed to be compatible, and
>> should run the same RTEMS image given the same memory configuration.
>> Since the previous message was discussing the bspgetworkarea.c changes,
>> I made a couple of changes:
>> - Reverted to the generic bspgetworkarea.c file, and changed the memory
>> size from 256MB to 128MB ( same as the 4.11 release ).
>> With these changes, the same RTEMS images worked on all single core models:
>> - RPi Zero 1.2 and 1.3
>> - RPi Model B
>> - RPi Model B+
>> - RPi Model A+
>>
>> Findings:
>> 1. The code that identifies the models in bspstart.c does not account
>> for the older models:
>> https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c
>> The RPi Model B, B+, and A+ that I have all use the older revision which
>> is not in the table in bspstart.c. I think we can fix this by adding the
>> older revision codes in the table, but I think this code is mostly cosmetic.
>> ht

Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

2020-01-07 Thread Christian Mauderer
On 07/01/2020 18:45, Niteesh wrote:
> You said that the FB was not working, was it because of this bug?
> or else I want to take a look at it.

No, that is a different problem. So if you want feel free to take a look.

The first thing I noted is that the command line is not parsed
correctly. The current console select code searches for a "--console="
but there is only a "console=" in the commandline.txt. You took that
logic over 1:1 from the old console.

> 
> On Tue, Jan 7, 2020 at 11:03 PM Niteesh  > wrote:
> 
> Great, thank you it wouldn't have been possible without your help
> and support.
> And thanks for patiently answering my questions :)

Thanks for beeing patient enough to rework the patch again and again.

> 
> On Tue, Jan 7, 2020 at 10:58 PM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> 
> Pushed with a minor modification: Due to the header reorder it was
> necessary to include one extra header in bsp/fbcons.h. But that
> has been
> a hidden bug anyway.
> 
> On 04/01/2020 20:50, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 143
> +++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c         |  78 
> >  bsps/arm/raspberrypi/console/usart.c          | 167
> --
> >  bsps/arm/raspberrypi/include/bsp.h            |   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h     |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c         |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 197 insertions(+), 404 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..48c4c6a3ec 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,133 @@
> >   */
> > 
> >  #include 
> > +#include 
> > +#include 
> > 
> >  #include 
> > +#include 
> > 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > 
> > -console_tbl Console_Configuration_Ports [] = {
> > -    {
> > -      .sDeviceName = "/dev/ttyS0",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = &bcm2835_usart_fns,
> > -      .deviceProbe = NULL,
> > -      .pDeviceFlow = NULL,
> > -      .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -      .ulCtrlPort2 = 0,
> > -      .ulClock = USART0_DEFAULT_BAUD,
> > -      .ulIntVector = BCM2835_IRQ_ID_UART
> > -    },
> > -    {
> > -      .sDeviceName ="/dev/fbcons",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = &fbcons_fns,
> > -      .deviceProbe = fbcons_probe,
> > -      .pDeviceFlow = NULL,
> > -    },
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -    / sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +
> > +#define UART0     "/dev/ttyS0"
> > +#define FBCONS    "/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> > +
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = &pl011_context;
> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +stati

Re: [EXTERNAL] Re: Raspberry Pi test report

2020-01-07 Thread Cudmore, Alan P. (GSFC-5820)
Thank you for the updates, I will try out the latest on my collection of 
Raspberry Pis and report back.
Alan

On 1/7/20, 1:47 PM, "devel on behalf of 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.

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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_tree_master_boot&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=PTx9y7REtCqICcxlngPx3cPtokUsZviH9R58ebNv6vo&e=
 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056551.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=flUH8jUi8ixjtv4XbduImKPMiy6XvlyAxh7I0mBsv6Y&e=
 
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2020-2DJanuary_056796.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=WQsPX2PnRA6i0f7Vh3IjAg3xqfh0yuqMQc7qQ3PH5Og&e=
 
> 
>>
>> 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 in my tests:
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.adafruit.com_product_3589&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=ID9UkEyd1TRcGUrZYw4RgFCGNP5qxxlwbVqwIvp_K9I&e=
 
>> It can power the pi through the USB cable and has a power switch as well.
>>
>> After the Pi Zero models, I tried my remaining older single core models:
>> 1. Raspberry Pi Model B ( Original single core model with 512MB of RAM
>> and 26 pin GPIO header)
>> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM
>> and 40 pin GPIO header)
>> 3. Raspberry Pi Model A+ (Smaller form factor single core model with
>> 256MB of RAM and

RE: [PATCH] tester: Prefer '_' as test state separator char

2020-01-07 Thread Lou Woods
To add some test data to this topic, I applied this patch to rtems-tools and 
ran the testsuite on the BeagleBone Black.  See the results below.
The testsuite completed without error.

Passed:578
Failed: 13
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 1
Invalid: 1
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 602
Failures:
 i2c01.exe
 termios09.exe
 psxfenv01.exe
 spcache01.exe
 spconfig02.exe
 spintrcritical01.exe
 spintrcritical02.exe
 spintrcritical03.exe
 spintrcritical04.exe
 spintrcritical05.exe
 spsysinit01.exe
 tmcontext01.exe
 tmtimer01.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 dhrystone.exe
 linpack.exe
 whetstone.exe
Timeouts:
 dl06.exe
Invalid:
 mouse01.exe
Average test time: 0:00:14.840996
Testing time : 2:28:54.279823

> -Original Message-
> From: devel  On Behalf Of Sebastian Huber
> Sent: Wednesday, December 18, 2019 2:29 AM
> To: rtems-de...@rtems.org
> Subject: Re: [PATCH] tester: Prefer '_' as test state separator char
> 
> Hello Chris,
> 
> if this change is all right for you I would push it and update the RSB to 
> pick up
> the recent fixes in the tools.
> 
> --
> 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] tester: Prefer '_' as test state separator char

2020-01-07 Thread Chris Johns
On 18/12/19 7:28 pm, Sebastian Huber wrote:
> if this change is all right for you I would push it and update the RSB to pick
> up the recent fixes in the tools.

It is fine.

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


Re: Raspberry Pi test report

2020-01-07 Thread Joel Sherrill
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

>
> 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 in my tests:
> >> https://www.adafruit.com/product/3589
> >> It can power the pi through the USB cable and has a power switch as
> well.
> >>
> >> After the Pi Zero models, I tried my remaining older single core models:
> >> 1. Raspberry Pi Model B ( Original single core model with 512MB of RAM
> >> and 26 pin GPIO header)
> >> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM
> >> and 40 pin GPIO header)
> >> 3. Raspberry Pi Model A+ (Smaller form factor single core model with
> >> 256MB of RAM and 40 pin GPIO header)
> >>(Note this model has been updated to now have 512MB of RAM)
> >>
> >> All three of the above models had the same exception that has been
> >> discussed on the mailing list:
> >> https://lists.rtems.org/pipermail/devel/2019-December/056556.html
> >
> > I addressed that issue in the following patch set:
> >
> > https://lists.rtems.org/pipermail/devel/2019-December/056623.html
> > https://lists.rtems.org/pipermail/devel/2019-December/056622.html
> > https://lists.rtems.org/pipermail/devel/2019-December/056624.html
> >
> > I'll push it in the next days together with patches regarding the
> > console from Niteesh. I just gave it some more time for review during
> > the public holidays.
> >
> > Basically it addresses the issues that you describe below.
> >
> >>
> >> All of these single core models are supposed to be compatible, and
> >> should run the same RTEMS image given the same memory configuration.
> >> Since the previous message was discussing the bspgetworkarea.c changes,
> >> I made a couple of changes:
> >> - Reverted to the generic bspgetworkarea.c file, and changed the memory
> >> size from 256MB to 128MB ( same as the 4.11 release ).
> >> With these changes, the same RTEMS images worked on all single core
> models:
> >> - RPi Zero 1.2 and 1.3
> >> - RPi Model B
> >> - RPi Model B+
> >> - RPi Model A+
> >>
> >> Find

Re: Raspberry Pi test report

2020-01-07 Thread Christian Mauderer
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 in my tests:
> >> https://www.adafruit.com/product/3589
> >> It can power the pi through the USB cable and has a power switch
> as well.
> >>
> >> After the Pi Zero models, I tried my remaining older single core
> models:
> >> 1. Raspberry Pi Model B ( Original single core model with 512MB
> of RAM
> >> and 26 pin GPIO header)
> >> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM
> >> and 40 pin GPIO header)
> >> 3. Raspberry Pi Model A+ (Smaller form factor single core model with
> >> 256MB of RAM and 40 pin GPIO header)
> >>    (Note this model has been updated to now have 512

Re: [PATCH] tester: Prefer '_' as test state separator char

2020-01-07 Thread Sebastian Huber

On 08/01/2020 00:02, Chris Johns wrote:

On 18/12/19 7:28 pm, Sebastian Huber wrote:

if this change is all right for you I would push it and update the RSB to pick
up the recent fixes in the tools.


It is fine.


Thanks for having a look at it. I pushed the change and updated the RSB.

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

2020-01-07 Thread Sebastian Huber



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 mailto:ged...@rtems.org>> 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.


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.


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