Re: [PATCH] libdebugger: Fix ARMv7-M with -O0

[Sebastian Huber]

Hallo Chris,

On 21/03/2020 07:45, Sebastian Huber wrote:


On 20/03/2020 22:23, Chris Johns wrote:



On 20 Mar 2020, at 4:49 pm, Sebastian Huber 
 wrote:


On 20/03/2020 05:15, Chris Johns wrote:


On 19/3/20 7:52 pm, Sebastian Huber wrote:

The ARMv7-M architecture has no CP-15.  The inline assembly for the
CP-15 access leads to assembler errors if compiled with -O0.

I would like to understand this one in detail to see why there is cp15 in the 
build.

In ARMv7-M the system registers are memory mapped.

If I compile a Cortex-M based BSP with -O0, then I get:


BSP?

For example the atsamv BSP.
could you please have a look at this. Being able to build with -O0 is 
quite helpful during BSP development.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] sb/setbuilder: do not include remotes in mailed reports

[Chris Johns]

Hi Gedare,

Thanks for taking a look at this ticket. Comments below..

On 2020-04-02 15:33, Gedare Bloom wrote:

Closes #3887.
---
  source-builder/sb/reports.py| 47 -
  source-builder/sb/setbuilder.py |  2 +-
  2 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
index ab20671..2f72088 100644
--- a/source-builder/sb/reports.py
+++ b/source-builder/sb/reports.py
@@ -241,13 +241,16 @@ class markdown_formatter(formatter):
  self.line(self._strong('Remotes:'))
  self.line('')
  rc = 1
-for r in remotes:
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-self.line('%d. %s: %s' % (rc, r, text))
-rc += 1
+if not remotes:
+self.line('[ removed for email, reply to sender for details ]')
+else:
+for r in remotes:
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+self.line('%d. %s: %s' % (rc, r, text))
+rc += 1
  self.line('')
  self.line(self._strong('Status:'))
  self.line('')
@@ -427,14 +430,17 @@ class text_formatter(formatter):
  if valid:
  self.line('%s Remotes:' % (self.cini))
  rc = 0
-for r in remotes:
-rc += 1
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-text = '%s: %s' % (r, text)
-self.line('%s  %2d: %s' % (self.cini, rc, text))
+if not remotes:
+self.line('[ removed for email, reply to sender for details ]')


Maybe something more generic ...

  [ remotes removed, contact to sender for details ]

?


+else:
+for r in remotes:
+rc += 1
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+text = '%s: %s' % (r, text)
+self.line('%s  %2d: %s' % (self.cini, rc, text))
  self.line('%s Status:' % (self.cini))
  if dirty:
  self.line('%s  Repository is dirty' % (self.cini))
@@ -647,17 +653,20 @@ class report:
  def release_status(self):
  self.formatter.release_status(version.string())
  
-def git_status(self):

+def git_status(self, sanitize = False):
  r = git.repo('.', self.opts, self.macros)
-self.formatter.git_status(r.valid(), r.dirty(), r.head(), r.remotes())
+if sanitize:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
+else:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
r.remotes())
  
-def introduction(self, name, intro_text = None):

+def introduction(self, name, intro_text = None, sanitize = False):
  now = datetime.datetime.now().ctime()
  self.formatter.introduction(name, now, intro_text)
  if version.released():
  self.release_status()
  else:
-self.git_status()
+self.git_status(sanitize)
  
  def epilogue(self, name):

  self.formatter.epilogue(name)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 7b80817..9367d55 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -201,7 +201,7 @@ class buildset:
  if mail:
  r = reports.report('text', self.configs,
 copy.copy(opts), copy.copy(macros))
-r.introduction(_build.config.file_name())
+r.introduction(_build.config.file_name(), sanitize = True)


Should the `sanitize` value be True if self.mail is not None?

Chris


  r.generate(_build.config.file_name())
  r.epilogue(_build.config.file_name())
  self.write_mail_report(r.get_output())


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

Re: [PATCH] sb/setbuilder: do not include remotes in mailed reports

[Gedare Bloom]

I couldn't test this patch successfully, the "Mailing report" step
hung for me without a good SMTP server to test it with.

On Wed, Apr 1, 2020 at 10:33 PM Gedare Bloom  wrote:
>
> Closes #3887.
> ---
>  source-builder/sb/reports.py| 47 -
>  source-builder/sb/setbuilder.py |  2 +-
>  2 files changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
> index ab20671..2f72088 100644
> --- a/source-builder/sb/reports.py
> +++ b/source-builder/sb/reports.py
> @@ -241,13 +241,16 @@ class markdown_formatter(formatter):
>  self.line(self._strong('Remotes:'))
>  self.line('')
>  rc = 1
> -for r in remotes:
> -if 'url' in remotes[r]:
> -text = remotes[r]['url']
> -else:
> -text = 'no URL found'
> -self.line('%d. %s: %s' % (rc, r, text))
> -rc += 1
> +if not remotes:
> +self.line('[ removed for email, reply to sender for details 
> ]')
> +else:
> +for r in remotes:
> +if 'url' in remotes[r]:
> +text = remotes[r]['url']
> +else:
> +text = 'no URL found'
> +self.line('%d. %s: %s' % (rc, r, text))
> +rc += 1
>  self.line('')
>  self.line(self._strong('Status:'))
>  self.line('')
> @@ -427,14 +430,17 @@ class text_formatter(formatter):
>  if valid:
>  self.line('%s Remotes:' % (self.cini))
>  rc = 0
> -for r in remotes:
> -rc += 1
> -if 'url' in remotes[r]:
> -text = remotes[r]['url']
> -else:
> -text = 'no URL found'
> -text = '%s: %s' % (r, text)
> -self.line('%s  %2d: %s' % (self.cini, rc, text))
> +if not remotes:
> +self.line('[ removed for email, reply to sender for details 
> ]')
> +else:
> +for r in remotes:
> +rc += 1
> +if 'url' in remotes[r]:
> +text = remotes[r]['url']
> +else:
> +text = 'no URL found'
> +text = '%s: %s' % (r, text)
> +self.line('%s  %2d: %s' % (self.cini, rc, text))
>  self.line('%s Status:' % (self.cini))
>  if dirty:
>  self.line('%s  Repository is dirty' % (self.cini))
> @@ -647,17 +653,20 @@ class report:
>  def release_status(self):
>  self.formatter.release_status(version.string())
>
> -def git_status(self):
> +def git_status(self, sanitize = False):
>  r = git.repo('.', self.opts, self.macros)
> -self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
> r.remotes())
> +if sanitize:
> +self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
> +else:
> +self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
> r.remotes())
>
> -def introduction(self, name, intro_text = None):
> +def introduction(self, name, intro_text = None, sanitize = False):
>  now = datetime.datetime.now().ctime()
>  self.formatter.introduction(name, now, intro_text)
>  if version.released():
>  self.release_status()
>  else:
> -self.git_status()
> +self.git_status(sanitize)
>
>  def epilogue(self, name):
>  self.formatter.epilogue(name)
> diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
> index 7b80817..9367d55 100644
> --- a/source-builder/sb/setbuilder.py
> +++ b/source-builder/sb/setbuilder.py
> @@ -201,7 +201,7 @@ class buildset:
>  if mail:
>  r = reports.report('text', self.configs,
> copy.copy(opts), copy.copy(macros))
> -r.introduction(_build.config.file_name())
> +r.introduction(_build.config.file_name(), sanitize = True)
>  r.generate(_build.config.file_name())
>  r.epilogue(_build.config.file_name())
>  self.write_mail_report(r.get_output())
> --
> 2.17.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] sb/setbuilder: do not include remotes in mailed reports

[Gedare Bloom]

Closes #3887.
---
 source-builder/sb/reports.py| 47 -
 source-builder/sb/setbuilder.py |  2 +-
 2 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
index ab20671..2f72088 100644
--- a/source-builder/sb/reports.py
+++ b/source-builder/sb/reports.py
@@ -241,13 +241,16 @@ class markdown_formatter(formatter):
 self.line(self._strong('Remotes:'))
 self.line('')
 rc = 1
-for r in remotes:
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-self.line('%d. %s: %s' % (rc, r, text))
-rc += 1
+if not remotes:
+self.line('[ removed for email, reply to sender for details ]')
+else:
+for r in remotes:
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+self.line('%d. %s: %s' % (rc, r, text))
+rc += 1
 self.line('')
 self.line(self._strong('Status:'))
 self.line('')
@@ -427,14 +430,17 @@ class text_formatter(formatter):
 if valid:
 self.line('%s Remotes:' % (self.cini))
 rc = 0
-for r in remotes:
-rc += 1
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-text = '%s: %s' % (r, text)
-self.line('%s  %2d: %s' % (self.cini, rc, text))
+if not remotes:
+self.line('[ removed for email, reply to sender for details ]')
+else:
+for r in remotes:
+rc += 1
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+text = '%s: %s' % (r, text)
+self.line('%s  %2d: %s' % (self.cini, rc, text))
 self.line('%s Status:' % (self.cini))
 if dirty:
 self.line('%s  Repository is dirty' % (self.cini))
@@ -647,17 +653,20 @@ class report:
 def release_status(self):
 self.formatter.release_status(version.string())
 
-def git_status(self):
+def git_status(self, sanitize = False):
 r = git.repo('.', self.opts, self.macros)
-self.formatter.git_status(r.valid(), r.dirty(), r.head(), r.remotes())
+if sanitize:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
+else:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
r.remotes())
 
-def introduction(self, name, intro_text = None):
+def introduction(self, name, intro_text = None, sanitize = False):
 now = datetime.datetime.now().ctime()
 self.formatter.introduction(name, now, intro_text)
 if version.released():
 self.release_status()
 else:
-self.git_status()
+self.git_status(sanitize)
 
 def epilogue(self, name):
 self.formatter.epilogue(name)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 7b80817..9367d55 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -201,7 +201,7 @@ class buildset:
 if mail:
 r = reports.report('text', self.configs,
copy.copy(opts), copy.copy(macros))
-r.introduction(_build.config.file_name())
+r.introduction(_build.config.file_name(), sanitize = True)
 r.generate(_build.config.file_name())
 r.epilogue(_build.config.file_name())
 self.write_mail_report(r.get_output())
-- 
2.17.1

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

[PATCH] sb/reports.py: Remove spurious error check

[Gedare Bloom]

The error path is taken when list-bsets or list-cfgs returns
true (meaning it listed them). So the error is invalid.
---
 source-builder/sb/reports.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
index 86a4c3a..ab20671 100644
--- a/source-builder/sb/reports.py
+++ b/source-builder/sb/reports.py
@@ -934,8 +934,6 @@ def run(args):
 raise error.general('config file not found: %s' % 
(_config))
 r.create(config, outname)
 del r
-else:
-raise error.general('invalid config type: %s' % (config))
 except error.general as gerr:
 print(gerr)
 sys.exit(1)
-- 
2.17.1

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

[PATCH] start/user: describe version numbers and releases

[Gedare Bloom]

Closes #2562.
---
 user/start/preparation.rst | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/user/start/preparation.rst b/user/start/preparation.rst
index 546a03d..eb0d56b 100644
--- a/user/start/preparation.rst
+++ b/user/start/preparation.rst
@@ -1,8 +1,10 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2018 Shashvat Jain
 .. Copyright (C) 2019 embedded brains GmbH
 .. Copyright (C) 2019 Sebastian Huber
 .. Copyright (C) 2020 Chris Johns
+.. Copyright (C) 2020 Gedare Bloom
 
 .. _QuickStartPreparation:
 
@@ -62,3 +64,50 @@ If you are looking for a hardware target to run RTEMS on we 
recommend the
 BSP. The BeagleBone Black support includes the RTEMS BSD Library (``libbsd``)
 and networking. The BeagleBone Black BSP is an ARM architecture BSP so the tool
 suite name is ``arm-rtems5``.
+
+Selecting a Version of RTEMS
+
+
+In the examples of this manual we will often refer to a specific version of
+RTEMS, which will usually be the version that accompanied the publication of
+this documentation manual. That may not be the appropriate version for you to
+use, for example, it may be too old (or too new) depending on what you are
+trying to do.  If you're not sure what version to use, we generally recommend
+using the most recent release or the development head (master), and you may
+want to consult with the same version of the documentation. We hope that newer
+is better.
+
+An RTEMS *release* involves the creation of a single downloadable file,
+normally a compressed tarball, that packages the source of all the repositories
+in a state consistent with the time the release is created.
+A release branch is a git branch pushed to the repositories named with the
+numeric identifier of the branch.
+A release branch release is a git tag on a release branch with
+the tags pushed to the repositories.
+
+Numbering for RTEMS versions beginning with RTEMS 5 uses a format as follows.
+The master branch has the version **N.0.0** with N being the next major release
+number. The first release of this series has the version number **N.1.0.** and
+there is exactly one commit with this version number in the corresponding
+repository. The first bugfix release (minor release) of this series will have
+the version number **N.2.0**. The release branch will have the version
+number **N.M.1** with **M** being the last minor release of this series.
+
+For example:
++ 5.0.0 is the version number of the development master for the 5 series.
++ 5.1.0 is the first release of the 5 series.
++ 5.1.1 is the version number of the 5 series release branch right after
+  the 5.1.0 release until 5.2.0 is released.
++ 5.2.0 is the first bugfix release of the 5 series
++ 5.2.1 is the version number of the 5 series release branch right after
+  the 5.2.0 release until 5.3.0 is released.
++ 6.0.0 is the version number of the development master for the 6 series.
+
+RTEMS development tools use **N** as the version number and are expected to
+work with all releases and the release branch of the N series.
+So to build tools for compiling RTEMS version number 5.1.0 for SPARC use
+``sparc-rtems5``. Despite the number not increasing, the tools may change
+within a release branch, for example the tools packaged with 5.1.1 still use
+the ``sparc-rtems5`` moniker, but are likely not the same as the tools used
+in version 5.1.0. This tool mismatch can be a source of confusion. Be sure to
+use the toolchain that matches your release.
-- 
2.17.1

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

RTEMS 5 release status

[Chris Johns]

Hello,

Please read if you have commit access.

I am cleaning up a few issues like the release README.txt to match 
moving all the released source in to `sources`, then updating the 
documentation to reference this and then I will create a 5.0.0-m2004 
snapshot.


After this I will be looking to make a branch so please wait for an ack 
from Joel, Gedare or myself for any pushes to any repo. We are in a 
slushy state to fix tickets.


The sooner we clear the tickets from 5.1 the sooner I can create the 
branch in the repos and the repos can be open again.


You help is needed and welcomed.

Thanks
Chris

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

[PATCH v4] doc: Moving M68K BSP Content to User Manual (#3905)

[Mritunjay]

---
 user/bsps/bsps-m68k.rst | 190 +++-
 1 file changed, 188 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..1e41f72 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -53,7 +53,19 @@ TODO.
 mcf5329
 ===
 
-TODO.
+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
+development kit features the MCF5329 based Fire Engine, as well as a plug-in
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
 
 mrm332
 ==
@@ -73,7 +85,181 @@ TODO.
 mvme162
 ===
 
-TODO.
+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for 
+embedded monitoring and control apllications it allows an OEM to minimize
+engineering expenses while integrating value-added hardware and software
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface
+options such as floating-point, Ethernet, SCSI, and VME. The result is a
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first
+user submitted BSP and continues to be a fairly popular simply because at one
+point it was the highest selling VMEBus board of all time.
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz
+162-Bug>env
+Bug or System environment [B/S] = B?
+Field Service Menu Enable [Y/N] = N?
+   Remote Start Method Switch [G/M/B/N] = B?
+   Probe System for Supported I/O Controllers [Y/N] = Y?
+   Negate VMEbus SYSFAIL* Always [Y/N] = N?
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
+   Local SCSI Bus Negotiations Type [A/S/N]   = A?
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
+   Auto Boot Enable [Y/N]   = N?
+   Auto Boot at power-up only [Y/N] = Y?
+   Auto Boot Controller LUN = 00?
+   Auto Boot Device LUN = 00?
+   Auto Boot Abort Delay= 15?
+   Auto Boot Default String [NULL for a empty string] = ?
+   ROM Boot Enable [Y/N]= N?
+   ROM Boot at power-up only [Y/N]  = Y?
+   ROM Boot Enable search of VMEbus [Y/N] = N?
+   ROM Boot Abort Delay = 0?
+   ROM Boot Direct Starting Address = FF80?
+   ROM Boot Direct Ending Address   = FFDC?
+   Network Auto Boot Enable [Y/N]   = N?
+   Network Auto Boot at power-up only [Y/N] = Y?
+   Network Auto Boot Controller LUN = 00?
+   Network Auto Boot Device LUN = 00?
+   Network Auto Boot Abort Delay= 5?
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
+   Memory Search Starting Address   = ?
+   Memory Search Ending Address = 0100?
+   Memory Search Increment Size = 0001?
+   Memory Search Delay Enable [Y/N] = N?
+   Memory Search Delay Address  = D20F?
+   Memory Size Enable [Y/N] = Y?
+   Memory Size Starting Address = ?
+   Memory Size Ending Address   = 0100?
+   Base Address of Dynamic Memory   = ?
+   Size of Parity Memory= ?
+   Size of ECC Memory Board #0  = 0100?
+   Size of ECC Memory Board #1  = ?
+   Base Address of Static Memory= FFE0?
+   Size of Static Memory= 0002?
+   Slave Enable #1 [Y/N] = Y?
+   Slave Starting Address #1 = ?
+   Slave Ending Address #1   = 00FF?
+   Slave Address Translation Address #1 = ?
+   Slave Address Translation Select #1  = ?
+   Slave Control #1 = 03FF?
+   Slave Enable #2 [Y/N] = N?
+   Slave Starting Address #2 = ?
+   Slave Ending Address #2   = ?
+   Slave Address Translation Address #2 = ?
+   Slave Address Translation Select #2  = ?
+   Slave Control #2 = ?
+   Master Enable #1 [Y/N] = Y?
+   Master Starting Address #1 = 0100?
+   Master Ending Address #1   = EFFF?
+   Master Control #1 = 0D?
+   Master Enable #2 [Y/N] = N?
+   Master Starting Address #2 = ?
+   Master Ending Address #2   = ?
+   Master 

Re: [PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Gedare Bloom]

On Wed, Apr 1, 2020 at 4:32 PM Mritunjay Sharma
 wrote:
>
>
>
> Sent from my iPhone
>
> > On 02-Apr-2020, at 3:51 AM, Gedare Bloom  wrote:
> >
> > On Wed, Apr 1, 2020 at 4:19 PM Gedare Bloom  wrote:
> >>
> >>> On Wed, Apr 1, 2020 at 3:56 PM Mritunjay  
> >>> wrote:
> >>>
> >>> ---
> >>> user/bsps/bsps-m68k.rst | 196 +++-
> >>> 1 file changed, 194 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> >>> index 60882fb..84f5f9d 100644
> >>> --- a/user/bsps/bsps-m68k.rst
> >>> +++ b/user/bsps/bsps-m68k.rst
> >>> @@ -1,6 +1,13 @@
> >>> .. SPDX-License-Identifier: CC-BY-SA-4.0
> >>>
> >>> .. Copyright (C) 2018 embedded brains GmbH
> >>> +.. Copyright (C) 2008 Mriek
> >>> +.. Copyright (C) 2011 Richard Campbell
> >>> +.. Copyright (C) 2010 Daniel Code
> >>> +.. Copyright (C) 2010 Mattrajca
> >>> +.. Copyright (C) 2009,2010 Joel Sherill
> >>> +.. Copyright (C) 2020 Mritunjay Sharma
> >>> +
> >>
> >> I'll have to look back, but most of these are going to be GCI students
> >> and the wiki names are not real names so the copyrights are not valid.
> >> Since they all pre-date the circa 2016 handoff from OAR to individual
> >> copyrights, I think we can just drop these copyright statements from
> >> the wiki contributions.
> >>
> >> Mritunjay, you should add your copyright only if you have made some
> >> actual contribution here to the writing, otherwise there should be no
> >> additional copyrights here (except maybe OAR one for circa 2008-2011
> >> modifications)
> >>
> >
> > I take the last statement back. Anything contributed to the wiki has
> > no clear copyright or license terms. However, GCI students'
> > contributions can be integrated more-or-less as we see fit. I think
> > someone dug up a few GCI student names before for the user manual
> > changes to provide the attribution list. It may be challenging.
> >
> > Either way, copyright statements won't be needed here, I think.
>
> Hi Gedare,
> I have added few lines that are written by me
> (like in Board Setup while describing about NIOT).
> Does that qualify for my name to be added in the
> Copyright or Should I simply remove all of them
> because all are prior to 2016?  I guess Chris advised me to find the names of 
> the authors.
> >
I was mistaken about the 2016 issue, that had to do with contributions
made explicitly to our docs prior to 2016. That said, I'm fairly sure
all the contributions are from GCI students except I don't know about
user:Mriek but when I look at that initial contribution it was from a
template and was subsequently overwritten.

It is kind of a pain. Furthermore, some of this text might be coming
from still other sources that aren't cited or with links that are now
dead. :(

So, just omit those copyrights. I think all the BSP information will
have been copied from vendor descriptions.

> >>>
> >>> m68k (Motorola 68000 / ColdFire)
> >>> 
> >>> @@ -53,7 +60,19 @@ TODO.
> >>> mcf5329
> >>> ===
> >>>
> >>> -TODO.
> >>> +Overview
> >>> +
> >>> +
> >>> +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a 
> >>> Motorola
> >>> +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
> >>> +development kit features the MCF5329 based Fire Engine, as well as a 
> >>> plug-in
> >>> +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 
> >>> 2 MB of
> >>> +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 
> >>> 800x600
> >>> +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
> >>> +
> >>> +You can find the link to MCF5329 Reference Manual below:
> >>> +
> >>> +* `MCF5329 Reference Manual 
> >>> `_
> >>>
> >>> mrm332
> >>> ==
> >>> @@ -73,7 +92,180 @@ TODO.
> >>> mvme162
> >>> ===
> >>>
> >>> -TODO.
> >>> +Overview
> >>> +
> >>> +
> >>> +The MVME162 family provides OEMs and solution developers an ideal 
> >>> platform for
> >>> +embedded monitoring and control apllications it allows an OEM to minimize
> >>> +engineering expenses while integrating value-added hardware and software
> >>> +applications onto an off-the-shelf product. In order to provide the wide 
> >>> range
> >>> +of solutions, the MVME162 allows a variety of MPU, memory, and interface
> >>> +options such as floating-point, Ethernet, SCSI, and VME. The result is a
> >>> +variation of the MVME162 which most closely fits the application 
> >>> requirement.
> >>> +
> >>> +There are a large number of model variations on this board. This was the 
> >>> first
> >>> +user submitted BSP and continues to be a fairly popular simply because 
> >>> at one
> >>> +point it was the highest selling VMEBus board of all time.
> >>> +
> >>> +Board Setup
> >>> +---
> >>> +
> >>> +We will setup the RTEMS Lab Board initally to proceed further for the 
> >>> setup
> >>> +of TFTP transfer.
> >>> 

Re: [PATCH v3] doc: Moving BSP Content to User Manual (#3905)

[Mritunjay Sharma]

> On 02-Apr-2020, at 3:48 AM, Chris Johns  wrote:
> 
> Hi,
> 
> The content is good however git noticed trailing whitespace and the 
> documentation standard says no trailing whitespace...
I'll fix them and will send you the updated patch 
once the discussion related to Copyright is
resolved.

Thanks 
Mritunjay 
> 
> Applying: doc: Moving BSP Content to User Manual (#3905)
> .git/rebase-apply/patch:31: trailing whitespace. 
> This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
> .git/rebase-apply/patch:32: trailing whitespace.
> evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
> .git/rebase-apply/patch:33: trailing whitespace.
> development kit features the MCF5329 based Fire Engine, as well as a plug-in
> .git/rebase-apply/patch:52: trailing whitespace.
> The MVME162 family provides OEMs and solution developers an ideal platform for
> .git/rebase-apply/patch:53: trailing whitespace.
> embedded monitoring and control apllications it allows an OEM to minimize
> warning: squelched 125 whitespace errors
> warning: 130 lines add whitespace errors. 
> 
> Also could the commit subject be more specific, e.g. ...
> 
> doc: Moving M68K BSP Content to User Manual (#3905)
> 
> Sorry to be so picky and thanks for doing this, it is great to see it being 
> done.
> 
> Thanks
> Chris
> 
>> On 2020-04-02 09:10, Mritunjay wrote:
>> ---
>>  user/bsps/bsps-m68k.rst | 197 +++-
>>  1 file changed, 195 insertions(+), 2 deletions(-)
>> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
>> index 60882fb..b829f5b 100644
>> --- a/user/bsps/bsps-m68k.rst
>> +++ b/user/bsps/bsps-m68k.rst
>> @@ -1,6 +1,13 @@
>>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>>.. Copyright (C) 2018 embedded brains GmbH
>> +.. Copyright (C) 2008 Mriek
>> +.. Copyright (C) 2011 Richard Campbell
>> +.. Copyright (C) 2010 Daniel Code
>> +.. Copyright (C) 2010 Mattrajca
>> +.. Copyright (C) 2009,2010 Joel Sherill
>> +.. Copyright (C) 2020 Mritunjay Sharma
>> +
>>m68k (Motorola 68000 / ColdFire)
>>  
>> @@ -53,7 +60,19 @@ TODO.
>>  mcf5329
>>  ===
>>  -TODO.
>> +Overview
>> +
>> +
>> +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
>> +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
>> +development kit features the MCF5329 based Fire Engine, as well as a plug-in
>> +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 
>> MB of
>> +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 
>> 800x600
>> +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
>> +
>> +You can find the link to MCF5329 Reference Manual below:
>> +
>> +* `MCF5329 Reference Manual 
>> `_
>>mrm332
>>  ==
>> @@ -73,7 +92,181 @@ TODO.
>>  mvme162
>>  ===
>>  -TODO.
>> +Overview
>> +
>> +
>> +The MVME162 family provides OEMs and solution developers an ideal platform 
>> for
>> +embedded monitoring and control apllications it allows an OEM to minimize
>> +engineering expenses while integrating value-added hardware and software
>> +applications onto an off-the-shelf product. In order to provide the wide 
>> range
>> +of solutions, the MVME162 allows a variety of MPU, memory, and interface
>> +options such as floating-point, Ethernet, SCSI, and VME. The result is a
>> +variation of the MVME162 which most closely fits the application 
>> requirement.
>> +
>> +There are a large number of model variations on this board. This was the 
>> first
>> +user submitted BSP and continues to be a fairly popular simply because at 
>> one
>> +point it was the highest selling VMEBus board of all time.
>> +
>> +Board Setup
>> +---
>> +
>> +We will setup the RTEMS Lab Board initally to proceed further for the setup
>> +of TFTP transfer.
>> +
>> +The env settings are:
>> +
>> +.. code-block:: none
>> +
>> +MPU Clock Speed =25Mhz
>> +162-Bug>env
>> +Bug or System environment [B/S] = B?
>> +Field Service Menu Enable [Y/N] = N?
>> +Remote Start Method Switch [G/M/B/N] = B?
>> +Probe System for Supported I/O Controllers [Y/N] = Y?
>> +Negate VMEbus SYSFAIL* Always [Y/N] = N?
>> +Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
>> +Local SCSI Bus Negotiations Type [A/S/N]   = A?
>> +Industry Pack Reset on Debugger Startup [Y/N]  = Y?
>> +Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
>> +Auto Boot Enable [Y/N]   = N?
>> +Auto Boot at power-up only [Y/N] = Y?
>> +Auto Boot Controller LUN = 00?
>> +Auto Boot Device LUN = 00?
>> +Auto Boot Abort Delay= 15?
>> +Auto Boot Default String [NULL for a empty string] = ?
>> +ROM Boot Enable [Y/N]= N?
>> +ROM Boot at power-up only [Y/N]  = Y?
>> +ROM Boot Enable search of VMEbus [Y/N] = N?
>> +ROM Boot Abort Delay = 

Re: [PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Mritunjay Sharma]

Sent from my iPhone

> On 02-Apr-2020, at 3:51 AM, Gedare Bloom  wrote:
> 
> On Wed, Apr 1, 2020 at 4:19 PM Gedare Bloom  wrote:
>> 
>>> On Wed, Apr 1, 2020 at 3:56 PM Mritunjay  
>>> wrote:
>>> 
>>> ---
>>> user/bsps/bsps-m68k.rst | 196 +++-
>>> 1 file changed, 194 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
>>> index 60882fb..84f5f9d 100644
>>> --- a/user/bsps/bsps-m68k.rst
>>> +++ b/user/bsps/bsps-m68k.rst
>>> @@ -1,6 +1,13 @@
>>> .. SPDX-License-Identifier: CC-BY-SA-4.0
>>> 
>>> .. Copyright (C) 2018 embedded brains GmbH
>>> +.. Copyright (C) 2008 Mriek
>>> +.. Copyright (C) 2011 Richard Campbell
>>> +.. Copyright (C) 2010 Daniel Code
>>> +.. Copyright (C) 2010 Mattrajca
>>> +.. Copyright (C) 2009,2010 Joel Sherill
>>> +.. Copyright (C) 2020 Mritunjay Sharma
>>> +
>> 
>> I'll have to look back, but most of these are going to be GCI students
>> and the wiki names are not real names so the copyrights are not valid.
>> Since they all pre-date the circa 2016 handoff from OAR to individual
>> copyrights, I think we can just drop these copyright statements from
>> the wiki contributions.
>> 
>> Mritunjay, you should add your copyright only if you have made some
>> actual contribution here to the writing, otherwise there should be no
>> additional copyrights here (except maybe OAR one for circa 2008-2011
>> modifications)
>> 
> 
> I take the last statement back. Anything contributed to the wiki has
> no clear copyright or license terms. However, GCI students'
> contributions can be integrated more-or-less as we see fit. I think
> someone dug up a few GCI student names before for the user manual
> changes to provide the attribution list. It may be challenging.
> 
> Either way, copyright statements won't be needed here, I think.

Hi Gedare,
I have added few lines that are written by me 
(like in Board Setup while describing about NIOT).
Does that qualify for my name to be added in the
Copyright or Should I simply remove all of them
because all are prior to 2016?  I guess Chris advised me to find the names of 
the authors.
> 
>>> 
>>> m68k (Motorola 68000 / ColdFire)
>>> 
>>> @@ -53,7 +60,19 @@ TODO.
>>> mcf5329
>>> ===
>>> 
>>> -TODO.
>>> +Overview
>>> +
>>> +
>>> +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
>>> +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
>>> +development kit features the MCF5329 based Fire Engine, as well as a 
>>> plug-in
>>> +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 
>>> MB of
>>> +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 
>>> 800x600
>>> +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
>>> +
>>> +You can find the link to MCF5329 Reference Manual below:
>>> +
>>> +* `MCF5329 Reference Manual 
>>> `_
>>> 
>>> mrm332
>>> ==
>>> @@ -73,7 +92,180 @@ TODO.
>>> mvme162
>>> ===
>>> 
>>> -TODO.
>>> +Overview
>>> +
>>> +
>>> +The MVME162 family provides OEMs and solution developers an ideal platform 
>>> for
>>> +embedded monitoring and control apllications it allows an OEM to minimize
>>> +engineering expenses while integrating value-added hardware and software
>>> +applications onto an off-the-shelf product. In order to provide the wide 
>>> range
>>> +of solutions, the MVME162 allows a variety of MPU, memory, and interface
>>> +options such as floating-point, Ethernet, SCSI, and VME. The result is a
>>> +variation of the MVME162 which most closely fits the application 
>>> requirement.
>>> +
>>> +There are a large number of model variations on this board. This was the 
>>> first
>>> +user submitted BSP and continues to be a fairly popular simply because at 
>>> one
>>> +point it was the highest selling VMEBus board of all time.
>>> +
>>> +Board Setup
>>> +---
>>> +
>>> +We will setup the RTEMS Lab Board initally to proceed further for the setup
>>> +of TFTP transfer.
>>> +
>>> +The env settings are:
>>> +
>>> +.. code-block:: none
>>> +
>>> +MPU Clock Speed =25Mhz
>>> +162-Bug>env
>>> +Bug or System environment [B/S] = B?
>>> +Field Service Menu Enable [Y/N] = N?
>>> +   Remote Start Method Switch [G/M/B/N] = B?
>>> +   Probe System for Supported I/O Controllers [Y/N] = Y?
>>> +   Negate VMEbus SYSFAIL* Always [Y/N] = N?
>>> +   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
>>> +   Local SCSI Bus Negotiations Type [A/S/N]   = A?
>>> +   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
>>> +   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
>>> +   Auto Boot Enable [Y/N]   = N?
>>> +   Auto Boot at power-up only [Y/N] = Y?
>>> +   Auto Boot Controller LUN = 00?
>>> +   Auto Boot Device LUN = 00?
>>> +   Auto Boot Abort Delay= 15?
>>> +   

Re: [PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Gedare Bloom]

On Wed, Apr 1, 2020 at 4:19 PM Gedare Bloom  wrote:
>
> On Wed, Apr 1, 2020 at 3:56 PM Mritunjay  wrote:
> >
> > ---
> >  user/bsps/bsps-m68k.rst | 196 +++-
> >  1 file changed, 194 insertions(+), 2 deletions(-)
> >
> > diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> > index 60882fb..84f5f9d 100644
> > --- a/user/bsps/bsps-m68k.rst
> > +++ b/user/bsps/bsps-m68k.rst
> > @@ -1,6 +1,13 @@
> >  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> >  .. Copyright (C) 2018 embedded brains GmbH
> > +.. Copyright (C) 2008 Mriek
> > +.. Copyright (C) 2011 Richard Campbell
> > +.. Copyright (C) 2010 Daniel Code
> > +.. Copyright (C) 2010 Mattrajca
> > +.. Copyright (C) 2009,2010 Joel Sherill
> > +.. Copyright (C) 2020 Mritunjay Sharma
> > +
>
> I'll have to look back, but most of these are going to be GCI students
> and the wiki names are not real names so the copyrights are not valid.
> Since they all pre-date the circa 2016 handoff from OAR to individual
> copyrights, I think we can just drop these copyright statements from
> the wiki contributions.
>
> Mritunjay, you should add your copyright only if you have made some
> actual contribution here to the writing, otherwise there should be no
> additional copyrights here (except maybe OAR one for circa 2008-2011
> modifications)
>

I take the last statement back. Anything contributed to the wiki has
no clear copyright or license terms. However, GCI students'
contributions can be integrated more-or-less as we see fit. I think
someone dug up a few GCI student names before for the user manual
changes to provide the attribution list. It may be challenging.

Either way, copyright statements won't be needed here, I think.

> >
> >  m68k (Motorola 68000 / ColdFire)
> >  
> > @@ -53,7 +60,19 @@ TODO.
> >  mcf5329
> >  ===
> >
> > -TODO.
> > +Overview
> > +
> > +
> > +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
> > +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
> > +development kit features the MCF5329 based Fire Engine, as well as a 
> > plug-in
> > +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 
> > MB of
> > +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 
> > 800x600
> > +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
> > +
> > +You can find the link to MCF5329 Reference Manual below:
> > +
> > +* `MCF5329 Reference Manual 
> > `_
> >
> >  mrm332
> >  ==
> > @@ -73,7 +92,180 @@ TODO.
> >  mvme162
> >  ===
> >
> > -TODO.
> > +Overview
> > +
> > +
> > +The MVME162 family provides OEMs and solution developers an ideal platform 
> > for
> > +embedded monitoring and control apllications it allows an OEM to minimize
> > +engineering expenses while integrating value-added hardware and software
> > +applications onto an off-the-shelf product. In order to provide the wide 
> > range
> > +of solutions, the MVME162 allows a variety of MPU, memory, and interface
> > +options such as floating-point, Ethernet, SCSI, and VME. The result is a
> > +variation of the MVME162 which most closely fits the application 
> > requirement.
> > +
> > +There are a large number of model variations on this board. This was the 
> > first
> > +user submitted BSP and continues to be a fairly popular simply because at 
> > one
> > +point it was the highest selling VMEBus board of all time.
> > +
> > +Board Setup
> > +---
> > +
> > +We will setup the RTEMS Lab Board initally to proceed further for the setup
> > +of TFTP transfer.
> > +
> > +The env settings are:
> > +
> > +.. code-block:: none
> > +
> > +MPU Clock Speed =25Mhz
> > +162-Bug>env
> > +Bug or System environment [B/S] = B?
> > +Field Service Menu Enable [Y/N] = N?
> > +   Remote Start Method Switch [G/M/B/N] = B?
> > +   Probe System for Supported I/O Controllers [Y/N] = Y?
> > +   Negate VMEbus SYSFAIL* Always [Y/N] = N?
> > +   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
> > +   Local SCSI Bus Negotiations Type [A/S/N]   = A?
> > +   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
> > +   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
> > +   Auto Boot Enable [Y/N]   = N?
> > +   Auto Boot at power-up only [Y/N] = Y?
> > +   Auto Boot Controller LUN = 00?
> > +   Auto Boot Device LUN = 00?
> > +   Auto Boot Abort Delay= 15?
> > +   Auto Boot Default String [NULL for a empty string] = ?
> > +   ROM Boot Enable [Y/N]= N?
> > +   ROM Boot at power-up only [Y/N]  = Y?
> > +   ROM Boot Enable search of VMEbus [Y/N] = N?
> > +   ROM Boot Abort Delay = 0?
> > +   ROM Boot Direct Starting Address = FF80?
> > +   ROM Boot Direct Ending Address   = FFDC?
> > +   Network Auto Boot Enable [Y/N] 

Re: [PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Gedare Bloom]

On Wed, Apr 1, 2020 at 3:56 PM Mritunjay  wrote:
>
> ---
>  user/bsps/bsps-m68k.rst | 196 +++-
>  1 file changed, 194 insertions(+), 2 deletions(-)
>
> diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> index 60882fb..84f5f9d 100644
> --- a/user/bsps/bsps-m68k.rst
> +++ b/user/bsps/bsps-m68k.rst
> @@ -1,6 +1,13 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
>  .. Copyright (C) 2018 embedded brains GmbH
> +.. Copyright (C) 2008 Mriek
> +.. Copyright (C) 2011 Richard Campbell
> +.. Copyright (C) 2010 Daniel Code
> +.. Copyright (C) 2010 Mattrajca
> +.. Copyright (C) 2009,2010 Joel Sherill
> +.. Copyright (C) 2020 Mritunjay Sharma
> +

I'll have to look back, but most of these are going to be GCI students
and the wiki names are not real names so the copyrights are not valid.
Since they all pre-date the circa 2016 handoff from OAR to individual
copyrights, I think we can just drop these copyright statements from
the wiki contributions.

Mritunjay, you should add your copyright only if you have made some
actual contribution here to the writing, otherwise there should be no
additional copyrights here (except maybe OAR one for circa 2008-2011
modifications)

>
>  m68k (Motorola 68000 / ColdFire)
>  
> @@ -53,7 +60,19 @@ TODO.
>  mcf5329
>  ===
>
> -TODO.
> +Overview
> +
> +
> +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
> +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
> +development kit features the MCF5329 based Fire Engine, as well as a plug-in
> +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB 
> of
> +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 
> 800x600
> +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
> +
> +You can find the link to MCF5329 Reference Manual below:
> +
> +* `MCF5329 Reference Manual 
> `_
>
>  mrm332
>  ==
> @@ -73,7 +92,180 @@ TODO.
>  mvme162
>  ===
>
> -TODO.
> +Overview
> +
> +
> +The MVME162 family provides OEMs and solution developers an ideal platform 
> for
> +embedded monitoring and control apllications it allows an OEM to minimize
> +engineering expenses while integrating value-added hardware and software
> +applications onto an off-the-shelf product. In order to provide the wide 
> range
> +of solutions, the MVME162 allows a variety of MPU, memory, and interface
> +options such as floating-point, Ethernet, SCSI, and VME. The result is a
> +variation of the MVME162 which most closely fits the application requirement.
> +
> +There are a large number of model variations on this board. This was the 
> first
> +user submitted BSP and continues to be a fairly popular simply because at one
> +point it was the highest selling VMEBus board of all time.
> +
> +Board Setup
> +---
> +
> +We will setup the RTEMS Lab Board initally to proceed further for the setup
> +of TFTP transfer.
> +
> +The env settings are:
> +
> +.. code-block:: none
> +
> +MPU Clock Speed =25Mhz
> +162-Bug>env
> +Bug or System environment [B/S] = B?
> +Field Service Menu Enable [Y/N] = N?
> +   Remote Start Method Switch [G/M/B/N] = B?
> +   Probe System for Supported I/O Controllers [Y/N] = Y?
> +   Negate VMEbus SYSFAIL* Always [Y/N] = N?
> +   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
> +   Local SCSI Bus Negotiations Type [A/S/N]   = A?
> +   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
> +   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
> +   Auto Boot Enable [Y/N]   = N?
> +   Auto Boot at power-up only [Y/N] = Y?
> +   Auto Boot Controller LUN = 00?
> +   Auto Boot Device LUN = 00?
> +   Auto Boot Abort Delay= 15?
> +   Auto Boot Default String [NULL for a empty string] = ?
> +   ROM Boot Enable [Y/N]= N?
> +   ROM Boot at power-up only [Y/N]  = Y?
> +   ROM Boot Enable search of VMEbus [Y/N] = N?
> +   ROM Boot Abort Delay = 0?
> +   ROM Boot Direct Starting Address = FF80?
> +   ROM Boot Direct Ending Address   = FFDC?
> +   Network Auto Boot Enable [Y/N]   = N?
> +   Network Auto Boot at power-up only [Y/N] = Y?
> +   Network Auto Boot Controller LUN = 00?
> +   Network Auto Boot Device LUN = 00?
> +   Network Auto Boot Abort Delay= 5?
> +   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
> +   Memory Search Starting Address   = ?
> +   Memory Search Ending Address = 0100?
> +   Memory Search Increment Size = 0001?
> +   Memory Search Delay Enable [Y/N] = N?
> +   Memory Search Delay Address  = D20F?
> +   Memory Size Enable [Y/N] = Y?
> +   Memory Size Starting Address = ?
> +   Memory Size Ending 

Re: [PATCH v3] doc: Moving BSP Content to User Manual (#3905)

[Chris Johns]

Hi,

The content is good however git noticed trailing whitespace and the 
documentation standard says no trailing whitespace...


Applying: doc: Moving BSP Content to User Manual (#3905)
.git/rebase-apply/patch:31: trailing whitespace. 


This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
.git/rebase-apply/patch:32: trailing whitespace.
evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
.git/rebase-apply/patch:33: trailing whitespace.
development kit features the MCF5329 based Fire Engine, as well as a 
plug-in

.git/rebase-apply/patch:52: trailing whitespace.
The MVME162 family provides OEMs and solution developers an ideal 
platform for

.git/rebase-apply/patch:53: trailing whitespace.
embedded monitoring and control apllications it allows an OEM to minimize
warning: squelched 125 whitespace errors
warning: 130 lines add whitespace errors. 



Also could the commit subject be more specific, e.g. ...

 doc: Moving M68K BSP Content to User Manual (#3905)

Sorry to be so picky and thanks for doing this, it is great to see it 
being done.


Thanks
Chris

On 2020-04-02 09:10, Mritunjay wrote:

---
  user/bsps/bsps-m68k.rst | 197 +++-
  1 file changed, 195 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..b829f5b 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -1,6 +1,13 @@
  .. SPDX-License-Identifier: CC-BY-SA-4.0
  
  .. Copyright (C) 2018 embedded brains GmbH

+.. Copyright (C) 2008 Mriek
+.. Copyright (C) 2011 Richard Campbell
+.. Copyright (C) 2010 Daniel Code
+.. Copyright (C) 2010 Mattrajca
+.. Copyright (C) 2009,2010 Joel Sherill
+.. Copyright (C) 2020 Mritunjay Sharma
+
  
  m68k (Motorola 68000 / ColdFire)

  
@@ -53,7 +60,19 @@ TODO.
  mcf5329
  ===
  
-TODO.

+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
+development kit features the MCF5329 based Fire Engine, as well as a plug-in
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
  
  mrm332

  ==
@@ -73,7 +92,181 @@ TODO.
  mvme162
  ===
  
-TODO.

+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for
+embedded monitoring and control apllications it allows an OEM to minimize
+engineering expenses while integrating value-added hardware and software
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface
+options such as floating-point, Ethernet, SCSI, and VME. The result is a
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first
+user submitted BSP and continues to be a fairly popular simply because at one
+point it was the highest selling VMEBus board of all time.
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz
+162-Bug>env
+Bug or System environment [B/S] = B?
+Field Service Menu Enable [Y/N] = N?
+   Remote Start Method Switch [G/M/B/N] = B?
+   Probe System for Supported I/O Controllers [Y/N] = Y?
+   Negate VMEbus SYSFAIL* Always [Y/N] = N?
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
+   Local SCSI Bus Negotiations Type [A/S/N]   = A?
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
+   Auto Boot Enable [Y/N]   = N?
+   Auto Boot at power-up only [Y/N] = Y?
+   Auto Boot Controller LUN = 00?
+   Auto Boot Device LUN = 00?
+   Auto Boot Abort Delay= 15?
+   Auto Boot Default String [NULL for a empty string] = ?
+   ROM Boot Enable [Y/N]= N?
+   ROM Boot at power-up only [Y/N]  = Y?
+   ROM Boot Enable search of VMEbus [Y/N] = N?
+   ROM Boot Abort Delay = 0?
+   ROM Boot Direct Starting Address = FF80?
+   ROM Boot Direct Ending Address   = FFDC?
+   Network Auto Boot Enable [Y/N]   = N?
+   Network Auto Boot at power-up only [Y/N] = Y?
+   Network Auto Boot Controller LUN = 00?
+   Network Auto Boot Device LUN = 00?
+   Network Auto Boot Abort Delay= 5?
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
+   Memory 

[PATCH v3] doc: Moving BSP Content to User Manual (#3905)

[Mritunjay]

---
 user/bsps/bsps-m68k.rst | 197 +++-
 1 file changed, 195 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..b829f5b 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -1,6 +1,13 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
 .. Copyright (C) 2018 embedded brains GmbH
+.. Copyright (C) 2008 Mriek
+.. Copyright (C) 2011 Richard Campbell
+.. Copyright (C) 2010 Daniel Code
+.. Copyright (C) 2010 Mattrajca
+.. Copyright (C) 2009,2010 Joel Sherill
+.. Copyright (C) 2020 Mritunjay Sharma
+
 
 m68k (Motorola 68000 / ColdFire)
 
@@ -53,7 +60,19 @@ TODO.
 mcf5329
 ===
 
-TODO.
+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola 
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The 
+development kit features the MCF5329 based Fire Engine, as well as a plug-in 
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
 
 mrm332
 ==
@@ -73,7 +92,181 @@ TODO.
 mvme162
 ===
 
-TODO.
+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for 
+embedded monitoring and control apllications it allows an OEM to minimize 
+engineering expenses while integrating value-added hardware and software 
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface 
+options such as floating-point, Ethernet, SCSI, and VME. The result is a 
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first 
+user submitted BSP and continues to be a fairly popular simply because at one 
+point it was the highest selling VMEBus board of all time. 
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz 
+162-Bug>env
+Bug or System environment [B/S] = B? 
+Field Service Menu Enable [Y/N] = N? 
+   Remote Start Method Switch [G/M/B/N] = B? 
+   Probe System for Supported I/O Controllers [Y/N] = Y? 
+   Negate VMEbus SYSFAIL* Always [Y/N] = N? 
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N? 
+   Local SCSI Bus Negotiations Type [A/S/N]   = A? 
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y? 
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y? 
+   Auto Boot Enable [Y/N]   = N? 
+   Auto Boot at power-up only [Y/N] = Y? 
+   Auto Boot Controller LUN = 00? 
+   Auto Boot Device LUN = 00? 
+   Auto Boot Abort Delay= 15? 
+   Auto Boot Default String [NULL for a empty string] = ? 
+   ROM Boot Enable [Y/N]= N? 
+   ROM Boot at power-up only [Y/N]  = Y? 
+   ROM Boot Enable search of VMEbus [Y/N] = N? 
+   ROM Boot Abort Delay = 0? 
+   ROM Boot Direct Starting Address = FF80? 
+   ROM Boot Direct Ending Address   = FFDC? 
+   Network Auto Boot Enable [Y/N]   = N? 
+   Network Auto Boot at power-up only [Y/N] = Y? 
+   Network Auto Boot Controller LUN = 00? 
+   Network Auto Boot Device LUN = 00? 
+   Network Auto Boot Abort Delay= 5? 
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00? 
+   Memory Search Starting Address   = ? 
+   Memory Search Ending Address = 0100? 
+   Memory Search Increment Size = 0001? 
+   Memory Search Delay Enable [Y/N] = N? 
+   Memory Search Delay Address  = D20F? 
+   Memory Size Enable [Y/N] = Y? 
+   Memory Size Starting Address = ? 
+   Memory Size Ending Address   = 0100? 
+   Base Address of Dynamic Memory   = ? 
+   Size of Parity Memory= ? 
+   Size of ECC Memory Board #0  = 0100? 
+   Size of ECC Memory Board #1  = ? 
+   Base Address of Static Memory= FFE0? 
+   Size of Static Memory= 0002? 
+   Slave Enable #1 [Y/N] = Y? 
+   Slave Starting Address #1 = ? 
+   Slave Ending Address #1   = 00FF? 
+   Slave Address Translation Address #1 = ? 
+   Slave Address Translation Select #1  = ? 
+   Slave Control #1 = 03FF? 
+   Slave Enable #2 [Y/N] = N? 
+   Slave Starting Address #2 = ? 
+   Slave Ending Address #2   = ? 
+   

Re: [PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Chris Johns]

Thanks and looking good. There is a long line with a length of 96 at the 
end ...


On 2020-04-02 08:54, Mritunjay wrote:

---
  user/bsps/bsps-m68k.rst | 196 +++-
  1 file changed, 194 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..84f5f9d 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -1,6 +1,13 @@
  .. SPDX-License-Identifier: CC-BY-SA-4.0
  
  .. Copyright (C) 2018 embedded brains GmbH

+.. Copyright (C) 2008 Mriek
+.. Copyright (C) 2011 Richard Campbell
+.. Copyright (C) 2010 Daniel Code
+.. Copyright (C) 2010 Mattrajca
+.. Copyright (C) 2009,2010 Joel Sherill
+.. Copyright (C) 2020 Mritunjay Sharma
+
  
  m68k (Motorola 68000 / ColdFire)

  
@@ -53,7 +60,19 @@ TODO.
  mcf5329
  ===
  
-TODO.

+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
+development kit features the MCF5329 based Fire Engine, as well as a plug-in
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
  
  mrm332

  ==
@@ -73,7 +92,180 @@ TODO.
  mvme162
  ===
  
-TODO.

+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for
+embedded monitoring and control apllications it allows an OEM to minimize
+engineering expenses while integrating value-added hardware and software
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface
+options such as floating-point, Ethernet, SCSI, and VME. The result is a
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first
+user submitted BSP and continues to be a fairly popular simply because at one
+point it was the highest selling VMEBus board of all time.
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz
+162-Bug>env
+Bug or System environment [B/S] = B?
+Field Service Menu Enable [Y/N] = N?
+   Remote Start Method Switch [G/M/B/N] = B?
+   Probe System for Supported I/O Controllers [Y/N] = Y?
+   Negate VMEbus SYSFAIL* Always [Y/N] = N?
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
+   Local SCSI Bus Negotiations Type [A/S/N]   = A?
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
+   Auto Boot Enable [Y/N]   = N?
+   Auto Boot at power-up only [Y/N] = Y?
+   Auto Boot Controller LUN = 00?
+   Auto Boot Device LUN = 00?
+   Auto Boot Abort Delay= 15?
+   Auto Boot Default String [NULL for a empty string] = ?
+   ROM Boot Enable [Y/N]= N?
+   ROM Boot at power-up only [Y/N]  = Y?
+   ROM Boot Enable search of VMEbus [Y/N] = N?
+   ROM Boot Abort Delay = 0?
+   ROM Boot Direct Starting Address = FF80?
+   ROM Boot Direct Ending Address   = FFDC?
+   Network Auto Boot Enable [Y/N]   = N?
+   Network Auto Boot at power-up only [Y/N] = Y?
+   Network Auto Boot Controller LUN = 00?
+   Network Auto Boot Device LUN = 00?
+   Network Auto Boot Abort Delay= 5?
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
+   Memory Search Starting Address   = ?
+   Memory Search Ending Address = 0100?
+   Memory Search Increment Size = 0001?
+   Memory Search Delay Enable [Y/N] = N?
+   Memory Search Delay Address  = D20F?
+   Memory Size Enable [Y/N] = Y?
+   Memory Size Starting Address = ?
+   Memory Size Ending Address   = 0100?
+   Base Address of Dynamic Memory   = ?
+   Size of Parity Memory= ?
+   Size of ECC Memory Board #0  = 0100?
+   Size of ECC Memory Board #1  = ?
+   Base Address of Static Memory= FFE0?
+   Size of Static Memory= 0002?
+   Slave Enable #1 [Y/N] = Y?
+   Slave Starting Address #1 = ?
+   Slave Ending Address #1   = 00FF?
+   Slave Address Translation Address #1 = ?
+   Slave Address Translation Select #1  = ?
+   Slave Control #1 = 03FF?
+   Slave Enable #2 [Y/N] = N?
+   

[PATCH v2] doc: Moving BSP Content to User Manual (#3905)

[Mritunjay]

---
 user/bsps/bsps-m68k.rst | 196 +++-
 1 file changed, 194 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..84f5f9d 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -1,6 +1,13 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
 .. Copyright (C) 2018 embedded brains GmbH
+.. Copyright (C) 2008 Mriek
+.. Copyright (C) 2011 Richard Campbell
+.. Copyright (C) 2010 Daniel Code
+.. Copyright (C) 2010 Mattrajca
+.. Copyright (C) 2009,2010 Joel Sherill
+.. Copyright (C) 2020 Mritunjay Sharma
+
 
 m68k (Motorola 68000 / ColdFire)
 
@@ -53,7 +60,19 @@ TODO.
 mcf5329
 ===
 
-TODO.
+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola 
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The 
+development kit features the MCF5329 based Fire Engine, as well as a plug-in 
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
 
 mrm332
 ==
@@ -73,7 +92,180 @@ TODO.
 mvme162
 ===
 
-TODO.
+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for 
+embedded monitoring and control apllications it allows an OEM to minimize 
+engineering expenses while integrating value-added hardware and software 
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface 
+options such as floating-point, Ethernet, SCSI, and VME. The result is a 
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first 
+user submitted BSP and continues to be a fairly popular simply because at one 
+point it was the highest selling VMEBus board of all time. 
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz 
+162-Bug>env
+Bug or System environment [B/S] = B? 
+Field Service Menu Enable [Y/N] = N? 
+   Remote Start Method Switch [G/M/B/N] = B? 
+   Probe System for Supported I/O Controllers [Y/N] = Y? 
+   Negate VMEbus SYSFAIL* Always [Y/N] = N? 
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N? 
+   Local SCSI Bus Negotiations Type [A/S/N]   = A? 
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y? 
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y? 
+   Auto Boot Enable [Y/N]   = N? 
+   Auto Boot at power-up only [Y/N] = Y? 
+   Auto Boot Controller LUN = 00? 
+   Auto Boot Device LUN = 00? 
+   Auto Boot Abort Delay= 15? 
+   Auto Boot Default String [NULL for a empty string] = ? 
+   ROM Boot Enable [Y/N]= N? 
+   ROM Boot at power-up only [Y/N]  = Y? 
+   ROM Boot Enable search of VMEbus [Y/N] = N? 
+   ROM Boot Abort Delay = 0? 
+   ROM Boot Direct Starting Address = FF80? 
+   ROM Boot Direct Ending Address   = FFDC? 
+   Network Auto Boot Enable [Y/N]   = N? 
+   Network Auto Boot at power-up only [Y/N] = Y? 
+   Network Auto Boot Controller LUN = 00? 
+   Network Auto Boot Device LUN = 00? 
+   Network Auto Boot Abort Delay= 5? 
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00? 
+   Memory Search Starting Address   = ? 
+   Memory Search Ending Address = 0100? 
+   Memory Search Increment Size = 0001? 
+   Memory Search Delay Enable [Y/N] = N? 
+   Memory Search Delay Address  = D20F? 
+   Memory Size Enable [Y/N] = Y? 
+   Memory Size Starting Address = ? 
+   Memory Size Ending Address   = 0100? 
+   Base Address of Dynamic Memory   = ? 
+   Size of Parity Memory= ? 
+   Size of ECC Memory Board #0  = 0100? 
+   Size of ECC Memory Board #1  = ? 
+   Base Address of Static Memory= FFE0? 
+   Size of Static Memory= 0002? 
+   Slave Enable #1 [Y/N] = Y? 
+   Slave Starting Address #1 = ? 
+   Slave Ending Address #1   = 00FF? 
+   Slave Address Translation Address #1 = ? 
+   Slave Address Translation Select #1  = ? 
+   Slave Control #1 = 03FF? 
+   Slave Enable #2 [Y/N] = N? 
+   Slave Starting Address #2 = ? 
+   Slave Ending Address #2   = ? 
+   

Re: [PATCH 2/3] testsuite: User input define added

[Chris Johns]

On 2020-04-01 16:40, Sebastian Huber wrote:

On 01/04/2020 00:06, Chris Johns wrote:


On 2020-03-31 21:02, Sebastian Huber wrote:

On 31/03/2020 11:56, Chris Johns wrote:


On 2020-03-31 19:57, Moyano, Gabriel wrote:
diff --git a/testsuite/arphole/test_main.c 
b/testsuite/arphole/test_main.c

index 19d67b89..45a28cc0 100644
--- a/testsuite/arphole/test_main.c
+++ b/testsuite/arphole/test_main.c
@@ -54,6 +54,7 @@
  #include 
    #define TEST_NAME "LIBBSD ARP HOLE"
+#define TEST_STATE_USER_INPUT 1


In rtems.git these test states are defined on the compiler command 
line. The user input state is OK to define in the code but it gets 
more difficult with the others to manage them in the code and so I 
am wondering how we manage the other states in libbsd? And if we 
manage those in the build system then why manage this one? 


Why should this define move to the build system of libbsd. It is a 
property of the test if it is interactive or not.


I was only highlighting the inconsistencies and problems that result. 
Placing the define in the source of a test was consider in rtems.git 
however having all data related to controlling tests in a single place 
was considered the better path. I asset this is still valid.
Yes, you are right, however, this patch is already an improvement which 
is worth to commit. Making this even better is a different topic and a 
secondary step from my point of view. Before the new build system for 
RTEMS is not integrated I am not in favour of adding more complexity to 
the libbsd build system.


Yes this makes sense. I want to make sure this is remember when the time 
comes to look at a better solution.


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

Re: [PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

On 01/04/2020 14:10, Sebastian Huber wrote:
> On 01/04/2020 14:09, Christian Mauderer wrote:
> 
>> On 01/04/2020 11:55, Sebastian Huber wrote:
>>> On 01/04/2020 11:45, Christian Mauderer wrote:
 The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
 If a MMC device has multiple hardware partitions (like eMMC which
 typically has at least one boot partition) the
 rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
 times. This doesn't work.

 Doing it right would mean to acquire and release the bus for each
 access which would have an performance impact. Beneath that it would
 mean that partition switching has to be supported by the RTEMS code too.

 There is currently no known use case where the access would be
 necessary. Therefore this patch prefers the performance and just avoids
 all further hardware partitions.
>>> Looks good.
>>>
>> Should we apply it only to master or to 5-freebsd-12 too? The problem
>> affects both so I would suggest to apply it to both branches.
> Both branches please.

Thanks. I pushed it.
-- 

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

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

Re: [PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Sebastian Huber]

On 01/04/2020 14:09, Christian Mauderer wrote:


On 01/04/2020 11:55, Sebastian Huber wrote:

On 01/04/2020 11:45, Christian Mauderer wrote:

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
If a MMC device has multiple hardware partitions (like eMMC which
typically has at least one boot partition) the
rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
times. This doesn't work.

Doing it right would mean to acquire and release the bus for each
access which would have an performance impact. Beneath that it would
mean that partition switching has to be supported by the RTEMS code too.

There is currently no known use case where the access would be
necessary. Therefore this patch prefers the performance and just avoids
all further hardware partitions.

Looks good.


Should we apply it only to master or to 5-freebsd-12 too? The problem
affects both so I would suggest to apply it to both branches.

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

Re: [PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

On 01/04/2020 11:55, Sebastian Huber wrote:
> On 01/04/2020 11:45, Christian Mauderer wrote:
>> The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
>> If a MMC device has multiple hardware partitions (like eMMC which
>> typically has at least one boot partition) the
>> rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
>> times. This doesn't work.
>>
>> Doing it right would mean to acquire and release the bus for each
>> access which would have an performance impact. Beneath that it would
>> mean that partition switching has to be supported by the RTEMS code too.
>>
>> There is currently no known use case where the access would be
>> necessary. Therefore this patch prefers the performance and just avoids
>> all further hardware partitions.
> 
> Looks good.
> 

Should we apply it only to master or to 5-freebsd-12 too? The problem
affects both so I would suggest to apply it to both branches.

-- 

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

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

Re: [PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Sebastian Huber]

On 01/04/2020 11:45, Christian Mauderer wrote:

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
If a MMC device has multiple hardware partitions (like eMMC which
typically has at least one boot partition) the
rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
times. This doesn't work.

Doing it right would mean to acquire and release the bus for each
access which would have an performance impact. Beneath that it would
mean that partition switching has to be supported by the RTEMS code too.

There is currently no known use case where the access would be
necessary. Therefore this patch prefers the performance and just avoids
all further hardware partitions.


Looks good.

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

[PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
If a MMC device has multiple hardware partitions (like eMMC which
typically has at least one boot partition) the
rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
times. This doesn't work.

Doing it right would mean to acquire and release the bus for each
access which would have an performance impact. Beneath that it would
mean that partition switching has to be supported by the RTEMS code too.

There is currently no known use case where the access would be
necessary. Therefore this patch prefers the performance and just avoids
all further hardware partitions.
---
 freebsd/sys/dev/mmc/mmcsd.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
index 077f8d74..21f54046 100644
--- a/freebsd/sys/dev/mmc/mmcsd.c
+++ b/freebsd/sys/dev/mmc/mmcsd.c
@@ -436,6 +436,15 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state state, 
const char *src, char **d
goto error;
}
 
+   /*
+* FIXME: There is no release for this acquire. Implementing
+* this would be necessary for:
+* - multiple hardware partitions of eMMC chips
+* - multiple devices on one bus
+*
+* On the other hand it would mean that the bus has to be
+* acquired on every read which would decrease the performance.
+*/
MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
 
status_code = rtems_bsd_mmcsd_set_block_size(dev, block_size);
@@ -764,6 +773,10 @@ mmcsd_add_part(struct mmcsd_softc *sc, u_int type, const 
char *name, u_int cnt,
free(part, M_DEVBUF);
return;
}
+#ifdef __rtems__
+   } else if (type != EXT_CSD_PART_CONFIG_ACC_DEFAULT) {
+   printf("%s: Additional partition. This is currently not 
supported in RTEMS.", part->name);
+#endif /* __rtems__ */
} else {
MMCSD_DISK_LOCK_INIT(part);
 
-- 
2.16.4

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

Re: [PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Christian Mauderer]

Hello Sebastian,

thanks for the review.

On 01/04/2020 10:41, Sebastian Huber wrote:
> On 01/04/2020 10:03, Christian Mauderer wrote:
> 
>> The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
>> Fix that by only acquire the bus if necessary (during initialization and
>> during read / writes).
>> ---
>>   freebsd/sys/dev/mmc/mmcsd.c | 8 ++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
>> index 077f8d74..674be6a7 100644
>> --- a/freebsd/sys/dev/mmc/mmcsd.c
>> +++ b/freebsd/sys/dev/mmc/mmcsd.c
>> @@ -268,6 +268,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev,
>> uint32_t block_size)
>>   memset(, 0, sizeof(req));
>>   memset(, 0, sizeof(cmd));
>>   +    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
>> +
>>   req.cmd = 
>>   cmd.opcode = MMC_SET_BLOCKLEN;
>>   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>> @@ -278,6 +280,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev,
>> uint32_t block_size)
>>   status_code = RTEMS_IO_ERROR;
>>   }
>>   +    MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
>> +
>>   return status_code;
>>   }
>>   @@ -316,6 +320,7 @@ rtems_bsd_mmcsd_disk_read_write(struct
>> mmcsd_part *part, rtems_blkdev_request *b
>>   data_flags = MMC_DATA_READ;
>>   }
>>   +    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
>>   MMCSD_DISK_LOCK(part);
> 
> I don't really know when you have to acquire the bus, but it is an
> expensive operation. Did you measure the performance impact of this change?
> 

No I didn't measure the performance impact.

The original FreeBSD code does the acquire and release around bus
accesses in the mmcsd_task. It covers switching partitions as well as
reading and writing.:

MMCBUS_ACQUIRE_BUS(mmcbus, dev);
sz = part->disk->d_sectorsize;
block = bp->bio_pblkno;
end = bp->bio_pblkno + (bp->bio_bcount / sz);
err = mmcsd_switch_part(mmcbus, dev, sc->rca, part->type);
if (err != MMC_ERR_NONE) {
if (ppsratecheck(>log_time, >log_count,
LOG_PPS))
device_printf(dev, "Partition switch error\n");
goto release;
}
if (bp->bio_cmd == BIO_READ || bp->bio_cmd == BIO_WRITE) {
/* Access to the remaining erase block obsoletes it. */
if (block < part->eend && end > part->eblock)
part->eblock = part->eend = 0;
block = mmcsd_rw(part, bp);
} else if (bp->bio_cmd == BIO_DELETE) {
block = mmcsd_delete(part, bp);
}
release:
MMCBUS_RELEASE_BUS(mmcbus, dev);

> I guess the use of the disk lock here was an optimization. If we really
> want to use the bus lock, then the disk lock should be removed.
> 
>>     for (i = 0; i < buffer_count; ++i) {
>> @@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part
>> *part, rtems_blkdev_request *b
>>   error:
>>     MMCSD_DISK_UNLOCK(part);
>> +    MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
>>     rtems_blkdev_request_done(blkreq, status_code);
>>   @@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state
>> state, const char *src, char **d
>>   goto error;
>>   }
>>   -    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
> 
> I think the bus acquire here is necessary to prevent an
> rtems_blkdev_create() while the bus is detached in parallel, e.g. a fast
> plug/unplug of an USB stick.
> 
> After reviewing the code I think this bus acquire without a release
> (which is in the code since the import from libusb in 2015) was a hack
> to improve the read/write performance. We didn't support hot plugging of
> MMC busses and devices. Do we need this feature now?

Sorry I didn't explain it: The problem is not hot plugging the busses or
the card. For that quite a bit more changes would be necessary. The
problem is that eMMC cards have multiple (hardware) partitions and
therefore call this code multiple times. For the second partition the
bus is already locked and therefore the MMCBUS_ACQUIRE_BUS just hangs.
The function is called from the media_server which then hangs too and
can't handle any new disks.

But I noted that there is a partition switching missing for the eMMC
cards too. Otherwise the wrong partition is used during detection of the
second one.

So another maybe better approach for now is to ignore any additional
hardware partions except the first one. That would need a hack to
mmcsd_add_part. There would be more work anyway if someone really wants
to use the second hardware partition.

Note: Hardware partitions don't have anything to do with the "normal"
disk partitions. It would be more similar to two SD cards on one bus.
It's a feature used by for example smart phones to store some stuff like
a signed kernel or some DRM keys that shouldn't be accessible in the
normal user space.

> 
>> 

Re: [PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Sebastian Huber]

On 01/04/2020 10:41, Sebastian Huber wrote:


    for (i = 0; i < buffer_count; ++i) {
@@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part 
*part, rtems_blkdev_request *b

  error:
    MMCSD_DISK_UNLOCK(part);
+    MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
    rtems_blkdev_request_done(blkreq, status_code);
  @@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state 
state, const char *src, char **d

  goto error;
  }
  -    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);


I think the bus acquire here is necessary to prevent an 
rtems_blkdev_create() while the bus is detached in parallel, e.g. a 
fast plug/unplug of an USB stick.
Sorry, this comment makes little sense, this code is not for USB sticks. 
However, if we want to support hot plugging of MMC busses and devices, 
then the rtems_blkdev_create() during a concurrent detach is something 
we have to consider.


After reviewing the code I think this bus acquire without a release 
(which is in the code since the import from libusb in 2015) was a hack 
to improve the read/write performance. We didn't support hot plugging 
of MMC busses and devices. Do we need this feature now? 


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

Re: [PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Sebastian Huber]

On 01/04/2020 10:03, Christian Mauderer wrote:


The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
Fix that by only acquire the bus if necessary (during initialization and
during read / writes).
---
  freebsd/sys/dev/mmc/mmcsd.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
index 077f8d74..674be6a7 100644
--- a/freebsd/sys/dev/mmc/mmcsd.c
+++ b/freebsd/sys/dev/mmc/mmcsd.c
@@ -268,6 +268,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
memset(, 0, sizeof(req));
memset(, 0, sizeof(cmd));
  
+	MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);

+
req.cmd = 
cmd.opcode = MMC_SET_BLOCKLEN;
cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
@@ -278,6 +280,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
status_code = RTEMS_IO_ERROR;
}
  
+	MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);

+
return status_code;
  }
  
@@ -316,6 +320,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, rtems_blkdev_request *b

data_flags = MMC_DATA_READ;
}
  
+	MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);

MMCSD_DISK_LOCK(part);


I don't really know when you have to acquire the bus, but it is an 
expensive operation. Did you measure the performance impact of this change?


I guess the use of the disk lock here was an optimization. If we really 
want to use the bus lock, then the disk lock should be removed.


  
  	for (i = 0; i < buffer_count; ++i) {

@@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, 
rtems_blkdev_request *b
  error:
  
  	MMCSD_DISK_UNLOCK(part);

+   MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
  
  	rtems_blkdev_request_done(blkreq, status_code);
  
@@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state state, const char *src, char **d

goto error;
}
  
-		MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);


I think the bus acquire here is necessary to prevent an 
rtems_blkdev_create() while the bus is detached in parallel, e.g. a fast 
plug/unplug of an USB stick.


After reviewing the code I think this bus acquire without a release 
(which is in the code since the import from libusb in 2015) was a hack 
to improve the read/write performance. We didn't support hot plugging of 
MMC busses and devices. Do we need this feature now?



-
status_code = rtems_bsd_mmcsd_set_block_size(dev, block_size);
if (status_code != RTEMS_SUCCESSFUL) {
printf("OOPS: set block size failed\n");

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

[PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Christian Mauderer]

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
Fix that by only acquire the bus if necessary (during initialization and
during read / writes).
---
 freebsd/sys/dev/mmc/mmcsd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
index 077f8d74..674be6a7 100644
--- a/freebsd/sys/dev/mmc/mmcsd.c
+++ b/freebsd/sys/dev/mmc/mmcsd.c
@@ -268,6 +268,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
memset(, 0, sizeof(req));
memset(, 0, sizeof(cmd));
 
+   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
+
req.cmd = 
cmd.opcode = MMC_SET_BLOCKLEN;
cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
@@ -278,6 +280,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
status_code = RTEMS_IO_ERROR;
}
 
+   MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
+
return status_code;
 }
 
@@ -316,6 +320,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, 
rtems_blkdev_request *b
data_flags = MMC_DATA_READ;
}
 
+   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
MMCSD_DISK_LOCK(part);
 
for (i = 0; i < buffer_count; ++i) {
@@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, 
rtems_blkdev_request *b
 error:
 
MMCSD_DISK_UNLOCK(part);
+   MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
 
rtems_blkdev_request_done(blkreq, status_code);
 
@@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state state, 
const char *src, char **d
goto error;
}
 
-   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
-
status_code = rtems_bsd_mmcsd_set_block_size(dev, block_size);
if (status_code != RTEMS_SUCCESSFUL) {
printf("OOPS: set block size failed\n");
-- 
2.16.4

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

[PATCH] libio: Remove RTEMS_FILESYSTEM_TYPE_MINIIMFS

[Sebastian Huber]

This type is unused.  Do not mention non-existing
CONFIGURE_FILESYSTEM_MINIIMFS.
---
 cpukit/include/rtems/libio.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/cpukit/include/rtems/libio.h b/cpukit/include/rtems/libio.h
index 6e0bf8ede5..b3c0e975cd 100644
--- a/cpukit/include/rtems/libio.h
+++ b/cpukit/include/rtems/libio.h
@@ -1589,7 +1589,6 @@ extern int rtems_mkdir(const char *path, mode_t mode);
 /**@{**/
 
 #define RTEMS_FILESYSTEM_TYPE_IMFS "imfs"
-#define RTEMS_FILESYSTEM_TYPE_MINIIMFS "mimfs"
 #define RTEMS_FILESYSTEM_TYPE_FTPFS "ftpfs"
 #define RTEMS_FILESYSTEM_TYPE_TFTPFS "tftpfs"
 #define RTEMS_FILESYSTEM_TYPE_NFS "nfs"
@@ -1726,7 +1725,6 @@ int unmount(
  * - RTEMS_FILESYSTEM_TYPE_FTPFS,
  * - RTEMS_FILESYSTEM_TYPE_IMFS,
  * - RTEMS_FILESYSTEM_TYPE_JFFS2,
- * - RTEMS_FILESYSTEM_TYPE_MINIIMFS,
  * - RTEMS_FILESYSTEM_TYPE_NFS,
  * - RTEMS_FILESYSTEM_TYPE_RFS, or
  * - RTEMS_FILESYSTEM_TYPE_TFTPFS.
@@ -1738,7 +1736,6 @@ int unmount(
  * - CONFIGURE_FILESYSTEM_FTPFS,
  * - CONFIGURE_FILESYSTEM_IMFS,
  * - CONFIGURE_FILESYSTEM_JFFS2,
- * - CONFIGURE_FILESYSTEM_MINIIMFS,
  * - CONFIGURE_FILESYSTEM_NFS,
  * - CONFIGURE_FILESYSTEM_RFS, and
  * - CONFIGURE_FILESYSTEM_TFTPFS.
-- 
2.16.4

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

[PATCH 1/2] c-user: Clarify config options use

[Sebastian Huber]

---
 c-user/config/general.rst   |  5 -
 c-user/config/mpci.rst  | 24 
 c-user/config/posix-api.rst | 10 ++
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index 388a8bf..c366be3 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -375,9 +375,12 @@ DESCRIPTION:
 
 NOTES:
 If there are more processors available than configured, the rest will be
-ignored.  In uniprocessor configuration, this configuration define is
 ignored.
 
+This configuration option is only evaluated in SMP configurations (e.g. 
RTEMS
+was built with the ``--enable-smp`` build configuration option).  In all
+other configurations it has no effect.
+
 .. index:: CONFIGURE_MAXIMUM_THREAD_NAME_SIZE
 .. index:: maximum thread name size
 
diff --git a/c-user/config/mpci.rst b/c-user/config/mpci.rst
index a3b5e23..854600b 100644
--- a/c-user/config/mpci.rst
+++ b/c-user/config/mpci.rst
@@ -36,8 +36,10 @@ DESCRIPTION:
 options are assumed to be provided.
 
 NOTES:
-This has no impact unless RTEMS was built with the
-``--enable-multiprocessing`` build configuration option.
+This configuration option shall be undefined if the multiprocessing support
+is not enabled (e.g. RTEMS was built without the 
``--enable-multiprocessing``
+build configuration option).  Otherwise a compile time error in the
+configuration file will occur.
 
 .. index:: CONFIGURE_EXTRA_MPCI_RECEIVE_SERVER_STACK
 
@@ -73,7 +75,8 @@ DESCRIPTION:
 :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE`.
 
 NOTES:
-None.
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
 
 .. index:: CONFIGURE_MP_MAXIMUM_GLOBAL_OBJECTS
 
@@ -103,6 +106,9 @@ NOTES:
 This value corresponds to the total number of objects which can be created
 with the ``RTEMS_GLOBAL`` attribute.
 
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
+
 .. index:: CONFIGURE_MP_MAXIMUM_NODES
 
 .. _CONFIGURE_MP_MAXIMUM_NODES:
@@ -128,7 +134,8 @@ DESCRIPTION:
 a multiprocessor system.
 
 NOTES:
-None.
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
 
 .. index:: CONFIGURE_MP_MAXIMUM_PROXIES
 
@@ -161,6 +168,9 @@ NOTES:
 remote tasks/threads which can be blocked on objects on this node, see
 :ref:`MPCIProxies`.
 
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
+
 .. index:: CONFIGURE_MP_MPCI_TABLE_POINTER
 
 .. _CONFIGURE_MP_MPCI_TABLE_POINTER:
@@ -190,6 +200,9 @@ NOTES:
 Multiprocessor System assuming the BSP provides the proper set of
 supporting methods.
 
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
+
 .. index:: CONFIGURE_MP_NODE_NUMBER
 
 .. _CONFIGURE_MP_NODE_NUMBER:
@@ -219,3 +232,6 @@ NOTES:
 the Makefile variable ``NODE_NUMBER``. The same code is compiled with the
 ``NODE_NUMBER`` set to different values. The test programs behave
 differently based upon their node number.
+
+This configuration option is only evaluated if
+:ref:`CONFIGURE_MP_APPLICATION` is defined.
diff --git a/c-user/config/posix-api.rst b/c-user/config/posix-api.rst
index 0c84012..1359909 100644
--- a/c-user/config/posix-api.rst
+++ b/c-user/config/posix-api.rst
@@ -176,6 +176,11 @@ VALUE CONSTRAINTS:
   RTEMS Workspace size calculation carried out by  
does
   not overflow an integer of type ``uintptr_t``.
 
+* It shall be zero if the POSIX API is not
+  enabled (e.g. RTEMS was built without the ``--enable-posix`` build
+  configuration option).  Otherwise a compile time error in the 
configuration
+  file will occur.
+
 DESCRIPTION:
 The value of this configuration option defines the maximum number of POSIX
 API Queued Signals that can be concurrently active.
@@ -366,6 +371,11 @@ VALUE CONSTRAINTS:
   object class, if the value passed to :c:func:`rtems_resource_unlimited`
   satisfies all other constraints of this configuration option.
 
+* It shall be zero if the POSIX API is not
+  enabled (e.g. RTEMS was built without the ``--enable-posix`` build
+  configuration option).  Otherwise a compile time error in the 
configuration
+  file will occur.
+
 DESCRIPTION:
 The value of this configuration option defines the maximum number of POSIX
 API Timers that can be concurrently active.
-- 
2.16.4

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

[PATCH 2/2] c-user: Move CONFIGURE_MAXIMUM_PRIORITY

[Sebastian Huber]

Move this option to the scheduler configuration options.
---
 c-user/config/general.rst   | 58 -
 c-user/config/scheduler-general.rst | 58 +
 2 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index c366be3..b1bca61 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -288,64 +288,6 @@ NOTES:
 The default value of three file descriptors allows RTEMS to support 
standard
 input, output, and error I/O streams on ``/dev/console``.
 
-.. index:: CONFIGURE_MAXIMUM_PRIORITY
-.. index:: maximum priority
-.. index:: number of priority levels
-
-.. _CONFIGURE_MAXIMUM_PRIORITY:
-
-CONFIGURE_MAXIMUM_PRIORITY
---
-
-CONSTANT:
-``CONFIGURE_MAXIMUM_PRIORITY``
-
-OPTION TYPE:
-This configuration option is an integer define.
-
-DEFAULT VALUE:
-The default value is 255.
-
-VALUE CONSTRAINTS:
-The value of this configuration option shall be
-an element of {3, 7, 31, 63, 127, 255}.
-
-DESCRIPTION:
-For the following schedulers
-
-* :ref:`SchedulerPriority`, which is the default in uniprocessor
-  configurations and can be configured through the
-  :ref:`CONFIGURE_SCHEDULER_PRIORITY` configuration option,
-
-* :ref:`SchedulerSMPPriority` which can be configured through the
-  :ref:`CONFIGURE_SCHEDULER_PRIORITY_SMP` configuration option, and
-
-* :ref:`SchedulerSMPPriorityAffinity` which can be configured through the
-  :ref:`CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP` configuration option
-
-this configuration option specifies the maximum numeric priority of any 
task
-for these schedulers and one less that the number of priority levels for
-these schedulers.  For all other schedulers provided by RTEMS, this
-configuration option has no effect.
-
-NOTES:
-The numerically greatest priority is the logically lowest priority in the
-system and will thus be used by the IDLE task.
-
-Priority zero is reserved for internal use by RTEMS and is not available to
-applications.
-
-Reducing the number of priorities through this configuration option reduces
-the amount of memory allocated by the schedulers listed above.  These
-schedulers use a chain control structure per priority and this structure
-consists of three pointers.  On a 32-bit architecture, the allocated memory
-is 12 bytes * (``CONFIGURE_MAXIMUM_PRIORITY`` + 1), e.g. 3072 bytes for 256
-priority levels (default), 48 bytes for 4 priority levels
-(``CONFIGURE_MAXIMUM_PRIORITY == 3``).
-
-The default value is 255, because RTEMS shall support 256 priority levels 
to
-be compliant with various standards.  These priorities range from 0 to 255.
-
 .. index:: CONFIGURE_MAXIMUM_PROCESSORS
 
 .. _CONFIGURE_MAXIMUM_PROCESSORS:
diff --git a/c-user/config/scheduler-general.rst 
b/c-user/config/scheduler-general.rst
index 0436100..438e9a3 100644
--- a/c-user/config/scheduler-general.rst
+++ b/c-user/config/scheduler-general.rst
@@ -65,6 +65,64 @@ NOTES:
 This configuration option is only evaluated if the configuration option
 :ref:`CONFIGURE_SCHEDULER_CBS` is defined.
 
+.. index:: CONFIGURE_MAXIMUM_PRIORITY
+.. index:: maximum priority
+.. index:: number of priority levels
+
+.. _CONFIGURE_MAXIMUM_PRIORITY:
+
+CONFIGURE_MAXIMUM_PRIORITY
+--
+
+CONSTANT:
+``CONFIGURE_MAXIMUM_PRIORITY``
+
+OPTION TYPE:
+This configuration option is an integer define.
+
+DEFAULT VALUE:
+The default value is 255.
+
+VALUE CONSTRAINTS:
+The value of this configuration option shall be
+an element of {3, 7, 31, 63, 127, 255}.
+
+DESCRIPTION:
+For the following schedulers
+
+* :ref:`SchedulerPriority`, which is the default in uniprocessor
+  configurations and can be configured through the
+  :ref:`CONFIGURE_SCHEDULER_PRIORITY` configuration option,
+
+* :ref:`SchedulerSMPPriority` which can be configured through the
+  :ref:`CONFIGURE_SCHEDULER_PRIORITY_SMP` configuration option, and
+
+* :ref:`SchedulerSMPPriorityAffinity` which can be configured through the
+  :ref:`CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP` configuration option
+
+this configuration option specifies the maximum numeric priority of any 
task
+for these schedulers and one less that the number of priority levels for
+these schedulers.  For all other schedulers provided by RTEMS, this
+configuration option has no effect.
+
+NOTES:
+The numerically greatest priority is the logically lowest priority in the
+system and will thus be used by the IDLE task.
+
+Priority zero is reserved for internal use by RTEMS and is not available to
+applications.
+
+Reducing the number of priorities through this configuration option reduces
+the amount of memory allocated by the schedulers listed above.  These
+schedulers 

RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

[Gabriel.Moyano]

Hi Sebastian,

Sorry to bother you for this again. 

When you say "mark a test as interactive", do you mean to add 
TEST_STATE_USER_INPUT in the test?

Regards,
Gabriel

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of gabriel.moy...@dlr.de
Sent: Dienstag, 31. März 2020 11:58
To: sebastian.hu...@embedded-brains.de; devel@rtems.org
Subject: RE: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

Is this meaning to leave them unchanged? (or there is a define for this?)

-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] 
Sent: Dienstag, 31. März 2020 11:46
To: Moyano Heredia, Victor Gabriel; devel@rtems.org
Subject: Re: [PATCH 3/3] testsuite/dhcpd0x: Tests automatized

On 31/03/2020 11:44, gabriel.moy...@dlr.de wrote:

> If both tests are interactive, should both of them include "the user input" 
> define? Otherwise RTEMS tester will be waiting until the timeout.
I would mark them as interactive for now.
___
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