[PATCH 1/2] tester: Simplify the console data handling

[chrisj]

From: Chris Johns 

---
 tester/rt/console.py | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/tester/rt/console.py b/tester/rt/console.py
index 7e09bb9..13300da 100644
--- a/tester/rt/console.py
+++ b/tester/rt/console.py
@@ -109,7 +109,6 @@ class tty(console):
 data = me.tty.read()
 if isinstance(data, bytes):
 data = data.decode('utf-8', 'ignore')
-data = [c for c in data if ord(c) < 128]
 except IOError as ioe:
 if ioe.errno == errno.EAGAIN:
 continue
@@ -117,13 +116,11 @@ class tty(console):
 except:
 raise
 for c in data:
-if len(c) == 0:
-continue
-if c != chr(0):
+if ord(c) > 0 and ord(c) < 128:
 line += c
-if c == '\n':
-me.output(line)
-line = ''
+if c == '\n':
+me.output(line)
+line = ''
 if stty and path.exists(self.dev):
 self.tty = stty.tty(self.dev)
 else:
-- 
2.24.1

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

[PATCH 2/2] tester/tftp: Fxi recovery of timed out TFTP sessions

[chrisj]

From: Chris Johns 

- Add support to retry the tftp session if the target has not
  started

- Add target handlers for the test directives to allow recovery
  on error
---
 tester/rt/config.py |  21 -
 tester/rt/exe.py|  12 +++
 tester/rt/gdb.py|  12 +++
 tester/rt/tftp.py   | 136 +---
 tester/rt/tftpserver.py |  19 ++---
 tester/rtems/testing/testing.mc |   1 +
 6 files changed, 161 insertions(+), 40 deletions(-)

diff --git a/tester/rt/config.py b/tester/rt/config.py
index a9adfd8..467de22 100644
--- a/tester/rt/config.py
+++ b/tester/rt/config.py
@@ -84,8 +84,10 @@ class file(config.file):
 self.kill_good = False
 self.kill_on_end = False
 self.test_label = None
-self.target_reset_regx = None
 self.target_start_regx = None
+self.target_reset_regx = None
+self.restarts = 0
+self.max_restarts = int(self.expand('%{max_restarts}'))
 
 def __del__(self):
 if self.console:
@@ -380,25 +382,36 @@ class file(config.file):
 if e >= 0:
 self.test_label = text[s + len('*** BEGIN OF TEST '):s 
+ e + 3 - 1]
 self._capture_console('test start: %s' % (self.test_label))
+self.process.target_start()
 ok_to_kill = '*** TEST STATE: USER_INPUT' in text or \
  '*** TEST STATE: BENCHMARK' in text
 if ok_to_kill:
 reset_target = True
 else:
 reset_target = False
-if self.test_started and self.target_start_regx is not None:
+if self.target_start_regx is not None:
 if self.target_start_regx.match(text):
-self._capture_console('target start detected')
-ok_to_kill = True
+if self.test_started:
+self._capture_console('target start detected')
+ok_to_kill = True
+else:
+self.restarts += 1
+if self.restarts > self.max_restarts:
+self._capture_console('target restart maximum 
count reached')
+ok_to_kill = True
+else:
+self.process.target_restart(self.test_started)
 if not reset_target and self.target_reset_regx is not None:
 if self.target_reset_regx.match(text):
 self._capture_console('target reset condition detected')
 self._target_command('reset')
+self.process.target_reset(self.test_started)
 if self.kill_on_end:
 if not ok_to_kill and '*** END OF TEST ' in text:
 self._capture_console('test end: %s' % (self.test_label))
 if self.test_label is not None:
 ok_to_kill = '*** END OF TEST %s ***' % 
(self.test_label) in text
+self.process.target_end()
 text = [(self.console_prefix, l) for l in text.replace(chr(13), 
'').splitlines()]
 if self.output is not None:
 if self.realtime_trace:
diff --git a/tester/rt/exe.py b/tester/rt/exe.py
index 5655073..13b9686 100644
--- a/tester/rt/exe.py
+++ b/tester/rt/exe.py
@@ -170,3 +170,15 @@ class exe(object):
 self._kill()
 finally:
 self._unlock('_kill')
+
+def target_restart(self, started):
+pass
+
+def target_reset(self, started):
+pass
+
+def target_start(self):
+pass
+
+def target_end(self):
+pass
diff --git a/tester/rt/gdb.py b/tester/rt/gdb.py
index 4abbca5..674c706 100644
--- a/tester/rt/gdb.py
+++ b/tester/rt/gdb.py
@@ -284,6 +284,18 @@ class gdb(object):
 finally:
 self._unlock('_kill')
 
+def target_restart(self, started):
+pass
+
+def target_reset(self, started):
+pass
+
+def target_start(self):
+pass
+
+def target_end(self):
+pass
+
 def gdb_expect(self):
 if self.trace:
 print('}}} gdb-expect')
diff --git a/tester/rt/tftp.py b/tester/rt/tftp.py
index 49bdb29..56c9160 100644
--- a/tester/rt/tftp.py
+++ b/tester/rt/tftp.py
@@ -41,6 +41,7 @@ import time
 import sys
 
 from rtemstoolkit import error
+from rtemstoolkit import log
 from rtemstoolkit import reraise
 
 import tester.rt.tftpserver
@@ -68,54 +69,69 @@ class tftp(object):
 self.timeout = None
 self.test_too_long = None
 self.timer = None
+self.opened = False
 self.running = False
 self.finished = False
 self.caught = None
+self.target_state = 'reset'
 
 def _lock(self, msg):
 if self.lock_trace:
 print('|[   LOCK:%s ]|' % (msg))
 self.lock.acquire()
+if self.lock

Re: [PATCH] c-user: Add "Cache Manager" chapter

[Chris Johns]

On 14/9/21 3:57 pm, Sebastian Huber wrote:
> On 10/09/2021 10:49, Sebastian Huber wrote:
>> The Cache Manager directives are available via .  Document most
>> of them in the Classic API Guide.
>>
>> Not documented are the following directive since the API is not yet
>> stable:
>>
>> * rtems_cache_coherent_allocate()
>> * rtems_cache_coherent_free()
>> * rtems_cache_coherent_add_area()
>>
>> Not documented are the following directive since the directives are not
>> implemented on maintained platforms:
>>
>> * rtems_cache_freeze_data()
>> * rtems_cache_freeze_instruction()
>> * rtems_cache_unfreeze_data()
>> * rtems_cache_unfreeze_instruction()
>>
>> Close #4513.
>> ---
>> Here is the updated document for review:
>>
>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 
> Any objections to add this new chapter?
> 

Not from me. Looks good and a welcome addition.

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

Re: [PATCH] eng: Add register block specification types

[Sebastian Huber]

On 10/09/2021 16:41, Sebastian Huber wrote:

A register block may be used to specify the memory-mapped interface to
the hardware.  Register blocks consist of register block members.
Register block members are either instances of registers or instances of
other register blocks.  Registers consists of bit fields.

Update #3715.


Any objections to integrate this? The hardware specification is work in 
progress. What I have currently is a proof of concept for the GR740 and 
the GR712RC. It should cause no harm to have it documented. If this 
stuff is generally useful is an open question.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] c-user: Define lower and higher priority

[Sebastian Huber]

---
 c-user/glossary.rst | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 16a8b8d..b0cf7df 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -398,6 +398,17 @@ Glossary
 heterogeneous
 A multiprocessor computer system composed of dissimilar processors.
 
+higher priority
+A :term:`task` ``H`` has a higher priority than a task ``L``, if task 
``H``
+is more important that task ``L``.  For example, priority based 
schedulers
+will only allocate processors to the highest priority tasks.  In
+:term:`RTEMS`, task priorities are represented by non-negative 
integers.
+For the Classic :term:`API`, if a numerical priority value ``R`` is 
less
+than a numerical priority value ``S``, then ``R`` expresses a higher 
priority
+than ``S``.  For the :term:`POSIX` API, if a numerical priority value 
``P``
+is greater than a numerical priority value ``Q``, then ``P`` expresses 
a
+higher priority than ``Q``.
+
 home scheduler
 The home scheduler of a :term:`task` is a :term:`scheduler` which is an
 :term:`eligible scheduler` and which is assigned to the task during its
@@ -498,6 +509,17 @@ Glossary
 A multiprocessor configuration where shared memory is not used for
 communication.
 
+lower priority
+A :term:`task` ``L`` has a lower priority than a task ``H``, if task 
``L``
+is less important that task ``H``.  For example, priority based 
schedulers
+will only allocate processors to the highest priority tasks.  In
+:term:`RTEMS`, task priorities are represented by non-negative 
integers.
+For the Classic :term:`API`, if a numerical priority value ``R`` is 
greater
+than a numerical priority value ``S``, then ``R`` expresses a lower 
priority
+than ``S``.  For the :term:`POSIX` API, if a numerical priority value 
``P``
+is less than a numerical priority value ``Q``, then ``P`` expresses a 
lower
+priority than ``Q``.
+
 major number
 The index of a device driver in the Device Driver Table.
 
-- 
2.31.1

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

Re: [PATCH] c-user: Define lower and higher priority

[Joel Sherrill]

The text looks ok. But there is duplication. Could the discussion of
classic vs posix priorities be in the definition of priority? And
referenced?

I assume it formats ok

On Tue, Sep 14, 2021, 9:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  c-user/glossary.rst | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 16a8b8d..b0cf7df 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -398,6 +398,17 @@ Glossary
>  heterogeneous
>  A multiprocessor computer system composed of dissimilar
> processors.
>
> +higher priority
> +A :term:`task` ``H`` has a higher priority than a task ``L``, if
> task ``H``
> +is more important that task ``L``.  For example, priority based
> schedulers
> +will only allocate processors to the highest priority tasks.  In
> +:term:`RTEMS`, task priorities are represented by non-negative
> integers.
> +For the Classic :term:`API`, if a numerical priority value ``R``
> is less
> +than a numerical priority value ``S``, then ``R`` expresses a
> higher priority
> +than ``S``.  For the :term:`POSIX` API, if a numerical priority
> value ``P``
> +is greater than a numerical priority value ``Q``, then ``P``
> expresses a
> +higher priority than ``Q``.
> +
>  home scheduler
>  The home scheduler of a :term:`task` is a :term:`scheduler` which
> is an
>  :term:`eligible scheduler` and which is assigned to the task
> during its
> @@ -498,6 +509,17 @@ Glossary
>  A multiprocessor configuration where shared memory is not used for
>  communication.
>
> +lower priority
> +A :term:`task` ``L`` has a lower priority than a task ``H``, if
> task ``L``
> +is less important that task ``H``.  For example, priority based
> schedulers
> +will only allocate processors to the highest priority tasks.  In
> +:term:`RTEMS`, task priorities are represented by non-negative
> integers.
> +For the Classic :term:`API`, if a numerical priority value ``R``
> is greater
> +than a numerical priority value ``S``, then ``R`` expresses a
> lower priority
> +than ``S``.  For the :term:`POSIX` API, if a numerical priority
> value ``P``
> +is less than a numerical priority value ``Q``, then ``P``
> expresses a lower
> +priority than ``Q``.
> +
>  major number
>  The index of a device driver in the Device Driver Table.
>
> --
> 2.31.1
>
> ___
> 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

[PATCH rtems-tools] check.py: Fix incorrect use of os.linesep

[Ryan Long]

Replaced a couple of calls to os.linesep() with os.linesep because
os.linesep() does not exist.
---
 tester/rt/check.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rt/check.py b/tester/rt/check.py
index 95fa47e..c01c25d 100755
--- a/tester/rt/check.py
+++ b/tester/rt/check.py
@@ -966,13 +966,13 @@ class builder:
 def _create_config(self, job, commands):
 filename = 'config-%s-%s-%s.ini' % (job.arch, job.bsp, job.build)
 cfg_file = open(path.join(self.rtems, filename),'w+')
-cfg_file.write('[%s/%s]' + os.linsep() % (job.arch, job.bsp))
+cfg_file.write('[%s/%s]' % (job.arch, job.bsp) + os.linesep)
 new_cfg_cmds = []
 for option in commands['configure'].split():
 if 'waf' in option or '--' in option or 'configure' in option:
 new_cfg_cmds += [option]
 else:
-cfg_file.write(option + os.linesep())
+cfg_file.write(option + os.linesep)
 commands['configure'] = ' '.join(new_cfg_cmds)
 cfg_file.close()
 
-- 
1.8.3.1

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

[PATCH] c-user: Fix message manager documentation

[Sebastian Huber]

Remove bogus return status from rtems_message_queue_receive().  Clarify
rtems_message_queue_flush().

Close #4508.
---
 c-user/message/directives.rst | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/c-user/message/directives.rst b/c-user/message/directives.rst
index f320350..7317eb4 100644
--- a/c-user/message/directives.rst
+++ b/c-user/message/directives.rst
@@ -891,10 +891,6 @@ queue.
 :c:macro:`RTEMS_UNSATISFIED`
 The queue was empty.
 
-:c:macro:`RTEMS_UNSATISFIED`
-The queue was flushed while the calling task was waiting to receive a
-message.
-
 :c:macro:`RTEMS_TIMEOUT`
 The timeout happened while the calling task was waiting to receive a
 message
@@ -1039,17 +1035,22 @@ present on the queue, count is set to zero.
 The ``count`` parameter was `NULL
 `_.
 
+.. rubric:: NOTES:
+
+The directive does not flush tasks waiting to receive a message from the
+:term:`wait queue` of the message queue.
+
 .. rubric:: CONSTRAINTS:
 
 The following constraints apply to this directive:
 
-* The directive may be called from within task context.
-
 * The directive may be called from within interrupt context.
 
-* When the directive operates on a remote object, the directive sends a message
-  to the remote node and waits for a reply.  This will preempt the calling
-  task.
+* The directive may be called from within device driver initialization context.
+
+* The directive may be called from within task context.
+
+* The directive will not cause the calling task to be preempted.
 
 .. Generated from spec:/rtems/message/if/buffer
 
-- 
2.31.1

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

[PATCH v2] c-user: Define lower and higher priority

[Sebastian Huber]

---
 c-user/glossary.rst | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 16a8b8d..94bf773 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -398,6 +398,10 @@ Glossary
 heterogeneous
 A multiprocessor computer system composed of dissimilar processors.
 
+higher priority
+A :term:`task` ``H`` has a higher :term:`priority` than a task ``L``, 
if
+task ``H`` is more important than task ``L``.
+
 home scheduler
 The home scheduler of a :term:`task` is a :term:`scheduler` which is an
 :term:`eligible scheduler` and which is assigned to the task during its
@@ -498,6 +502,10 @@ Glossary
 A multiprocessor configuration where shared memory is not used for
 communication.
 
+lower priority
+A :term:`task` ``L`` has a lower :term:`priority` than a task ``H``, if
+task ``L`` is less important than task ``H``.
+
 major number
 The index of a device driver in the Device Driver Table.
 
@@ -664,8 +672,22 @@ Glossary
 
 priority
 The priority is a mechanism used to represent the relative importance 
of an
-element in a set of items.  RTEMS uses :term:`task priorities ` to determine
-which :term:`task` should execute.
+element in a set of items.
+
+For example, :term:`RTEMS` uses :term:`task priorities ` to determine which
+:term:`task` should execute on a processor.  In RTEMS, priorities are
+represented by non-negative integers.
+
+For the Classic :term:`API`, if a numerical priority value ``A`` is 
greater
+than a numerical priority value ``B``, then ``A`` expresses a
+:term:`higher priority` than ``B``.  If a numerical priority value 
``C`` is
+less than a numerical priority value ``D``, then ``C`` expresses a
+:term:`lower priority` than ``D``.
+
+For the :term:`POSIX` API, if a numerical priority value ``R`` is less 
than
+a numerical priority value ``S``, then ``R`` expresses a lower 
priority than
+``S``.  If a numerical priority value ``T`` is greater than a numerical
+priority value ``U``, then ``T`` expresses a higher priority than 
``U``.
 
 priority boosting
 A simple approach to extend the priority inheritance protocol for
@@ -999,13 +1021,18 @@ Glossary
 and resumes execution on another processor.
 
 task priority
-A task priority of a :term:`task` determines its importance relative to
-other tasks.  The scheduler use task priorities to determine which
-:term:`ready task` gets a processor allocated, see :term:`scheduled 
task`.  The
+A task :term:`priority` of a :term:`task` determines its importance
+relative to other tasks.
+
+The scheduler use task priorities to determine which :term:`ready 
task` gets
+a processor allocated, see :term:`scheduled task`.  The
 :term:`eligible priorities ` of a task define the 
position of the task in a
 :term:`wait queue` which uses the priority discipline.  Each task has 
at
 least the :term:`real priority`.
 
+Task priorities are used in :term:`wait queues ` which use 
the priority
+discipline to determine the dequeueing order of tasks.
+
 task processor affinity
 The set of processors on which a task is allowed to execute.
 
-- 
2.31.1

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

[PATCH] c-user: Clarify task priorities

[Sebastian Huber]

---
 c-user/scheduling-concepts/background.rst |  5 +
 c-user/scheduling-concepts/smp-schedulers.rst |  9 +
 c-user/task/background.rst| 14 ++
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/c-user/scheduling-concepts/background.rst 
b/c-user/scheduling-concepts/background.rst
index 7f8a63d..1fe7089 100644
--- a/c-user/scheduling-concepts/background.rst
+++ b/c-user/scheduling-concepts/background.rst
@@ -117,10 +117,7 @@ Task Priority and Scheduling
 
 The most significant task scheduling modification mechanism is the ability for
 the user to assign a priority level to each individual task when it is created
-and to alter a task's priority at run-time.  The maximum priority level depends
-on the configured scheduler.  A lower priority level means higher priority
-(higher importance).  The maximum priority level of the default uniprocessor
-scheduler is 255.
+and to alter a task's priority at run-time, see :ref:`TaskPriority`.
 
 .. index:: preemption
 
diff --git a/c-user/scheduling-concepts/smp-schedulers.rst 
b/c-user/scheduling-concepts/smp-schedulers.rst
index cfab04f..d6c1dc6 100644
--- a/c-user/scheduling-concepts/smp-schedulers.rst
+++ b/c-user/scheduling-concepts/smp-schedulers.rst
@@ -45,7 +45,7 @@ Deterministic Priority SMP Scheduler
 A fixed-priority scheduler which uses a table of chains with one chain per
 priority level for the ready tasks.  The maximum priority level is
 configurable.  By default, the maximum priority level is 255 (256 priority
-levels).
+levels), see :ref:`CONFIGURE_MAXIMUM_PRIORITY`.
 
 .. _SchedulerSMPPrioritySimple:
 
@@ -64,6 +64,7 @@ Arbitrary Processor Affinity Priority SMP Scheduler
 A fixed-priority scheduler which uses a table of chains with one chain per
 priority level for the ready tasks.  The maximum priority level is
 configurable.  By default, the maximum priority level is 255 (256 priority
-levels).  This scheduler supports arbitrary task processor affinities.  The
-worst-case run-time complexity of some scheduler operations exceeds
-:math:`O(n)` while :math:`n` is the count of ready tasks.
+levels), see :ref:`CONFIGURE_MAXIMUM_PRIORITY`.  This scheduler supports
+arbitrary task processor affinities.  The worst-case run-time complexity of
+some scheduler operations exceeds :math:`O(n)` while :math:`n` is the count of
+ready tasks.
diff --git a/c-user/task/background.rst b/c-user/task/background.rst
index a55f743..da6cabf 100644
--- a/c-user/task/background.rst
+++ b/c-user/task/background.rst
@@ -127,13 +127,19 @@ scheduling of a task is based on its current state and 
priority.
 .. index:: priority, task
 .. index:: rtems_task_priority
 
+.. _TaskPriority:
+
 Task Priority
 -
 
-A task's priority determines its importance in relation to the other tasks
-executing on the same processor.  RTEMS supports 255 levels of priority ranging
-from 1 to 255.  The data type ``rtems_task_priority`` is used to store task
-priorities.
+A task's :term:`priority` determines its importance in relation to the other
+tasks executing on the processor set owned by a :term:`scheduler`.  Normally,
+RTEMS supports 256 levels of priority ranging from 0 to 255.  The priority
+level 0 represents a special priority reserved for the operating system.  The
+data type :c:type:`rtems_task_priority` is used to store task priorities.  The
+maximum priority level depends on the configured scheduler, see
+:ref:`CONFIGURE_MAXIMUM_PRIORITY`, :ref:`ConfigurationSchedulersClustered`, and
+:ref:`RTEMSAPIClassicScheduler`.
 
 Tasks of numerically smaller priority values are more important tasks than
 tasks of numerically larger priority values.  For example, a task at priority
-- 
2.31.1

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

Re: RSB

[Joel Sherrill]

On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill  wrote:

> On Mon, Sep 13, 2021 at 6:54 PM Chris Johns  wrote:
> >
> > On 13/9/21 11:20 pm, Joel Sherrill wrote:
> > > Hi
> > >
> > > If building a bset tar file, does it matter if the installation prefix
> > > is writable?
> > >
> > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> > > --prefix=/rtems/tools 5/rtems-i386
> > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
> > > error: prefix is not writable: /rtems/tools
> > >
> > > It does if you are planning to immediately install but if building for
> > > later installation, I don't think it matters.
> > >
> > > Thoughts?
> >
> > What happens if you add --no-install?
>
> It skips the test.
>

And doesn't install anything.

>
> >
> > If this does help the question moves to if making a bset is packaging
> around an
> > install or is it the only output option?
>
> With a bset-tar, I don't think it did an install anyway. But it's been
> a long day. I can
> check again tomorrow if you want me to.
>

Builds and installs tools unless you specify no install.

Tar files is an additive behavior.

I am off today but will try to review the help and user docs to make sure
this is clear.

Any thoughts on the tools tarballs not having the architecture name in it?
If you build multiple architectures or just want to maintain tool tarballs
for multiple architectures, you have to manually rename them.

--joel

>
> Thanks for the quick response.
>
> --joel
>
> >
> > Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] eng: Add register block specification types

[Chris Johns]

On 14/9/21 8:08 pm, Sebastian Huber wrote:
> On 10/09/2021 16:41, Sebastian Huber wrote:
>> A register block may be used to specify the memory-mapped interface to
>> the hardware.  Register blocks consist of register block members.
>> Register block members are either instances of registers or instances of
>> other register blocks.  Registers consists of bit fields.
>>
>> Update #3715.
> 
> Any objections to integrate this? 

I am sorry but in it's current form I do.

> The hardware specification is work in
> progress. What I have currently is a proof of concept for the GR740 and the
> GR712RC. It should cause no harm to have it documented. If this stuff is
> generally useful is an open question.

Who fixes the spec for the other bus models? Will those fixes be compatible and
if not who fixes the existing specs or drivers?

Those questions expose the liability the project is left with. For me to make
changes and look after the GR740 and GR712RC it would be a lot of work because I
have not worked with those devices and they are important to some users.

I do not see the value in us hosting a custom or subset solution for a model to
access hardware we should not be encouraging. I see value in a solution that can
support all bus solutions.

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

Re: [PATCH rtems-tools] check.py: Fix incorrect use of os.linesep

[Chris Johns]

OK and thanks

Chris

On 15/9/21 1:29 am, Ryan Long wrote:
> Replaced a couple of calls to os.linesep() with os.linesep because
> os.linesep() does not exist.
> ---
>  tester/rt/check.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/rt/check.py b/tester/rt/check.py
> index 95fa47e..c01c25d 100755
> --- a/tester/rt/check.py
> +++ b/tester/rt/check.py
> @@ -966,13 +966,13 @@ class builder:
>  def _create_config(self, job, commands):
>  filename = 'config-%s-%s-%s.ini' % (job.arch, job.bsp, job.build)
>  cfg_file = open(path.join(self.rtems, filename),'w+')
> -cfg_file.write('[%s/%s]' + os.linsep() % (job.arch, job.bsp))
> +cfg_file.write('[%s/%s]' % (job.arch, job.bsp) + os.linesep)
>  new_cfg_cmds = []
>  for option in commands['configure'].split():
>  if 'waf' in option or '--' in option or 'configure' in option:
>  new_cfg_cmds += [option]
>  else:
> -cfg_file.write(option + os.linesep())
> +cfg_file.write(option + os.linesep)
>  commands['configure'] = ' '.join(new_cfg_cmds)
>  cfg_file.close()
>  
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB

[Chris Johns]

On 15/9/21 4:49 am, Joel Sherrill wrote:
> On Mon, Sep 13, 2021, 7:02 PM Joel Sherrill  > wrote:
> On Mon, Sep 13, 2021 at 6:54 PM Chris Johns  > wrote:
> > On 13/9/21 11:20 pm, Joel Sherrill wrote:
> > > Hi
> > >
> > > If building a bset tar file, does it matter if the installation prefix
> > > is writable?
> > >
> > > ../source-builder/sb-set-builder --bset-tar-file --log=l-i386.txt
> > > --prefix=/rtems/tools 5/rtems-i386
> > > RTEMS Source Builder - Set Builder, 5 (c7870f6e6199)
> > > error: prefix is not writable: /rtems/tools
> > >
> > > It does if you are planning to immediately install but if building for
> > > later installation, I don't think it matters.
> > >
> > > Thoughts?
> >
> > What happens if you add --no-install?
> 
> It skips the test.
> 
> And doesn't install anything.

Excellent.

> > If this does help the question moves to if making a bset is packaging
> around an
> > install or is it the only output option?
> 
> With a bset-tar, I don't think it did an install anyway. But it's been
> a long day. I can
> check again tomorrow if you want me to.
> 
> Builds and installs tools unless you specify no install.
> 
> Tar files is an additive behavior.

OK and thanks

> I am off today but will try to review the help and user docs to make sure this
> is clear.
> 
> Any thoughts on the tools tarballs not having the architecture name in it? If
> you build multiple architectures or just want to maintain tool tarballs for
> multiple architectures, you have to manually rename them.

Could you please remind me about the naming and then what you would like?

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

Re: [PATCH] eng: Add register block specification types

[Sebastian Huber]

On 15/09/2021 00:48, Chris Johns wrote:

On 14/9/21 8:08 pm, Sebastian Huber wrote:

On 10/09/2021 16:41, Sebastian Huber wrote:

A register block may be used to specify the memory-mapped interface to
the hardware.  Register blocks consist of register block members.
Register block members are either instances of registers or instances of
other register blocks.  Registers consists of bit fields.

Update #3715.


Any objections to integrate this?


I am sorry but in it's current form I do.


The hardware specification is work in
progress. What I have currently is a proof of concept for the GR740 and the
GR712RC. It should cause no harm to have it documented. If this stuff is
generally useful is an open question.


Who fixes the spec for the other bus models?


The register block specification doesn't need to be fixed. It is 
independent of bus models, device driver frameworks, and programming 
languages. The register block specification contains the same 
information as a hardware manual in terms of register blocks, registers, 
and bit fields. The only difference is that the register block 
specification is machine readable and a hardware manual not really in 
general.



Will those fixes be compatible and
if not who fixes the existing specs or drivers?


In order to support a particular device driver implementation framework 
you just have to write a code generator which reads the register block 
specification and outputs the code. The existing code generator just 
outputs a header file with C structures and defines for the bit fields. 
You could use this header file with the FreeBSD bus space API.




Those questions expose the liability the project is left with. For me to make
changes and look after the GR740 and GR712RC it would be a lot of work because I
have not worked with those devices and they are important to some users.


The existing GRLIB header files are incomplete. What we have now is a 
complete set of register block header files for the GR740.




I do not see the value in us hosting a custom or subset solution for a model to
access hardware we should not be encouraging.


We don't have a general bus space API in RTEMS. Basically every BSP has 
its own solution. No matter which model you have to access the hardware, 
you need something which tells you how the hardware looks like. This 
could be a manual or a machine readable description.



I see value in a solution that can
support all bus solutions.


I don't know if the register block specification supports all bus 
solutions, but it could support all I know currently. It is just a 
machine readable hardware description.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

V4 Zynq/ZynqMP UART driver

[chrisj]

Hi,

This is version 4 of the UART driver changes. This change adds:

- Wait for the TX FITO to empty and the TX state to be idle
  before setting the baudrate in the first open and setting
  the attributes.

- Read any data in the RX FIFO.

The change commit log highlights the purpose of the change.

I have tested this on zynqmp with no UART issues and I have tested
it on a zynq application. All testing is in hardware.

Chris 


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

[PATCH v4] arm/xilinx: Fix zynq-uart interrupt receive

[chrisj]

From: Chris Johns 

- Trigger on a single character entering the RX FIFO

- Disable the RX timeout

- Send up to a FIFO full of data
---
 bsps/include/dev/serial/zynq-uart.h   |  1 +
 bsps/shared/dev/serial/zynq-uart-polled.c | 45 ++---
 bsps/shared/dev/serial/zynq-uart.c| 78 +--
 3 files changed, 67 insertions(+), 57 deletions(-)

diff --git a/bsps/include/dev/serial/zynq-uart.h 
b/bsps/include/dev/serial/zynq-uart.h
index 220d9b7717..b21e16f6de 100644
--- a/bsps/include/dev/serial/zynq-uart.h
+++ b/bsps/include/dev/serial/zynq-uart.h
@@ -52,6 +52,7 @@ extern "C" {
 typedef struct {
   rtems_termios_device_context base;
   volatile struct zynq_uart *regs;
+  int tx_queued;
   bool transmitting;
   rtems_vector_number irq;
 } zynq_uart_context;
diff --git a/bsps/shared/dev/serial/zynq-uart-polled.c 
b/bsps/shared/dev/serial/zynq-uart-polled.c
index 95c51dea11..6865fa8d6f 100644
--- a/bsps/shared/dev/serial/zynq-uart-polled.c
+++ b/bsps/shared/dev/serial/zynq-uart-polled.c
@@ -121,35 +121,35 @@ void zynq_uart_initialize(rtems_termios_device_context 
*base)
   volatile zynq_uart *regs = ctx->regs;
   uint32_t brgr = 0x3e;
   uint32_t bauddiv = 0x6;
+  uint32_t mode_clks = regs->mode & ZYNQ_UART_MODE_CLKS;
 
-  zynq_uart_reset_tx_flush(ctx);
+  while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TEMPTY) == 0 ||
+ (regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TACTIVE) != 0) {
+/* Wait */
+  }
 
-  zynq_cal_baud_rate(ZYNQ_UART_DEFAULT_BAUD, &brgr, &bauddiv, regs->mode);
+  zynq_cal_baud_rate(ZYNQ_UART_DEFAULT_BAUD, &brgr, &bauddiv, mode_clks);
 
-  regs->control &= ~(ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN);
-  regs->control = ZYNQ_UART_CONTROL_RXDIS
-| ZYNQ_UART_CONTROL_TXDIS;
-  regs->mode = ZYNQ_UART_MODE_CHMODE(ZYNQ_UART_MODE_CHMODE_NORMAL)
-| ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE)
-| ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8);
+  regs->control = 0;
+  regs->control = ZYNQ_UART_CONTROL_RXDIS | ZYNQ_UART_CONTROL_TXDIS;
   regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
   regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
   /* A Tx/Rx logic reset must be issued after baud rate manipulation */
-  regs->control = ZYNQ_UART_CONTROL_RXDIS
-| ZYNQ_UART_CONTROL_TXDIS
-| ZYNQ_UART_CONTROL_RXRES
-| ZYNQ_UART_CONTROL_TXRES;
+  regs->control = ZYNQ_UART_CONTROL_RXDIS | ZYNQ_UART_CONTROL_TXDIS;
+  regs->control = ZYNQ_UART_CONTROL_RXRES | ZYNQ_UART_CONTROL_TXRES;
   regs->rx_fifo_trg_lvl = ZYNQ_UART_RX_FIFO_TRG_LVL_RTRIG(0);
   regs->rx_timeout = ZYNQ_UART_RX_TIMEOUT_RTO(0);
-  regs->control = ZYNQ_UART_CONTROL_RXEN
-| ZYNQ_UART_CONTROL_TXEN
-| ZYNQ_UART_CONTROL_RSTTO;
+  regs->control = ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
+  regs->mode = ZYNQ_UART_MODE_CHMODE(ZYNQ_UART_MODE_CHMODE_NORMAL)
+| ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE)
+| ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8)
+| mode_clks;
 
-  /*
-   * Some ZynqMP UARTs have a hardware bug that causes TX/RX logic restarts to
-   * require a kick after baud rate registers are initialized.
-   */
-  zynq_uart_write_polled(base, 0);
+  while (zynq_uart_read_polled(base) >= 0) {
+/* Drop */
+  }
+
+  zynq_uart_reset_tx_flush(ctx);
 }
 
 int zynq_uart_read_polled(rtems_termios_device_context *base)
@@ -172,7 +172,7 @@ void zynq_uart_write_polled(
   zynq_uart_context *ctx = (zynq_uart_context *) base;
   volatile zynq_uart *regs = ctx->regs;
 
-  while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TFUL) != 0) {
+  while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TNFUL) != 0) {
 /* Wait */
   }
 
@@ -187,7 +187,8 @@ void zynq_uart_reset_tx_flush(zynq_uart_context *ctx)
   while (c-- > 0)
 zynq_uart_write_polled(&ctx->base, '\r');
 
-  while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TEMPTY) == 0) {
+  while ((regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TEMPTY) == 0 ||
+ (regs->channel_sts & ZYNQ_UART_CHANNEL_STS_TACTIVE) != 0) {
 /* Wait */
   }
 }
diff --git a/bsps/shared/dev/serial/zynq-uart.c 
b/bsps/shared/dev/serial/zynq-uart.c
index 8503e31d49..8ff1d25da0 100644
--- a/bsps/shared/dev/serial/zynq-uart.c
+++ b/bsps/shared/dev/serial/zynq-uart.c
@@ -37,24 +37,24 @@ static void zynq_uart_interrupt(void *arg)
   rtems_termios_tty *tty = arg;
   zynq_uart_context *ctx = rtems_termios_get_device_context(tty);
   volatile zynq_uart *regs = ctx->regs;
-  uint32_t channel_sts;
 
-  if ((regs->irq_sts & (ZYNQ_UART_TIMEOUT | ZYNQ_UART_RTRIG)) != 0) {
-regs->irq_sts = ZYNQ_UART_TIMEOUT | ZYNQ_UART_RTRIG;
-
-do {
-  char c = (char) ZYNQ_UART_TX_RX_FIFO_FIFO_GET(regs->tx_rx_fifo);
-
-  rtems_termios_enqueue_raw_characters(tty, &c, 1);
-
-  channel_sts = regs->channel_sts;
-} while ((channel_sts & ZYNQ_UART_CHANNEL_STS_REMPTY) == 0);
-  } else {
-channel_sts = regs->channel_sts;
+  if ((regs->irq_sts & ZYNQ_UART_RTRIG) != 0) {
+char buf[32];
+int c = 0;
+regs->irq_sts = ZYNQ_UART_RTRI