from:"Tanu Hari Dixit"

Quitting the GSoC program

2017-06-23 Thread Tanu Hari Dixit

Hello all,

I am writing to inform that I will be quitting the Google Summer of
Code program. This is because I feel I am unable to do justice to the
work and also because in the quest for justice, I am hurting my
health. It is really difficult for me to take this decision and I hope
you understand.
I want to thank the RTEMS community for making me feel welcomed all
along and answering my stupid questions since a long time. I will not
leave RTEMS and will be back to contributing. Thank you all for
instilling in me the open-source values of helping and collaborating
Here is the status of my project:
The format for the ini files that explain the configuration macros
required for different bsps in
rtems-tools.git/tester/rtems/testing/bsps is decided and is documented
here(https://tokencolour.github.io/2017/05/29/Community-Bonding.html).
I had started to include the functionality of reading the INI files
and the necessary changes are in the read_ini branch in my fork of
rtems-tools (https://github.com/tokencolour/rtems-tools/tree/read_ini).
There are a few issues here, I'll work on them if I get the time and
if somebody else is interested can contact me. I will be happy to
explain where this gets stuck.
Thank you and I hope I'll be able to make it up to RTEMS in the future.

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

Re: [PATCH v4] User Manual: Added rtems-tester in the docs

2017-06-13 Thread Tanu Hari Dixit

Hi Chris,
I will keep this in mind.
Thank you.
Tanu.

On Wed, Jun 14, 2017 at 7:10 AM, Chris Johns  wrote:
> On 02/06/2017 08:39, Tanu Hari Dixit wrote:
>> Added as part of Tools.
>> Made changes according to Chris' review
>> Also removed the ini format part inline with
>> the new release that is expected.
>
> I pushed this patch after I removed the trailing white space. Please remove
> trailing white space from the lines. Git complains when I apply the patch.
>
> Thank you for the patch.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Review and help

2017-06-11 Thread Tanu Hari Dixit

Hello Chris,

What do you think of the changes above? Did you imagine it this way?
Right now:
python rtems-test --log=erc32_winpdb_5 --rtems-bsp=erc32-run
--rtems-tools=$HOME/development/rtems/4.12
/home/thd/development/rtems/src/builds/erc32_new_state/sparc-rtems4.12/c/erc32/testsuites/samples/hello/

shows the following error:

RTEMS Testing - Tester, 4.12 (ab4e5399d172 modified)
error: config: cannot find configuration: _/bsps/erc32-run.ini

It hasn't expanded %{_configdir} properly, probably. Can you spot the problem?
I'm still debugging.

Thank you,
Tanu.

On Mon, Jun 12, 2017 at 8:21 AM, Tanu Hari Dixit  wrote:
> Few of the new ini files
> ---
>  tester/rtems/testing/bsps/erc32-run.ini |  54 ++
>  tester/rtems/testing/bsps/erc32.ini |  56 ++
>  tester/rtems/testing/defaults.ini   | 126 
> 
>  tester/rtems/testing/testing.ini|  57 +++
>  4 files changed, 293 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/erc32-run.ini
>  create mode 100644 tester/rtems/testing/bsps/erc32.ini
>  create mode 100644 tester/rtems/testing/defaults.ini
>  create mode 100644 tester/rtems/testing/testing.ini
>
> diff --git a/tester/rtems/testing/bsps/erc32-run.ini 
> b/tester/rtems/testing/bsps/erc32-run.ini
> new file mode 100644
> index 000..4135426
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/erc32-run.ini
> @@ -0,0 +1,54 @@
> +;
> +; RTEMS Tools Project (http://www.rtems.org/)
> +; Copyright 2015 On-Line Applications Research Corporation (OAR).
> +; All rights reserved.
> +;
> +; This file is part of the RTEMS Tools package in 'rtems-tools'.
> +;
> +; Redistribution and use in source and binary forms, with or without
> +; modification, are permitted provided that the following conditions are met:
> +;
> +; 1. Redistributions of source code must retain the above copyright notice,
> +; this list of conditions and the following disclaimer.
> +;
> +; 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +; this list of conditions and the following disclaimer in the documentation
> +; and/or other materials provided with the distribution.
> +;
> +; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +; AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +; ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +; LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +; CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +; SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +; INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +; CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +; ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +; POSSIBILITY OF SUCH DAMAGE.
> +;
> +
> +;
> +; All paths in defaults must be Unix format. Do not store any Windows format
> +; paths in the defaults.
> +;
> +; Every entry must describe the type of checking a host must pass.
> +;
> +; Records:
> +;  key: type, attribute, value
> +;   type : none, dir, exe, triplet
> +;   attribute: none, required, optional
> +;   value: 'single line', '''multi line'''
> +;
> +
> +;
> +; The erc32 BSP
> +;
> +[erc32]
> +bsp = erc32
> +arch = sparc
> +
> +[run]
> +run = %{_rtscripts}/run.cfg
> +bsp_run_cmd = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run
> +bsp_run_opts = ''
> diff --git a/tester/rtems/testing/bsps/erc32.ini 
> b/tester/rtems/testing/bsps/erc32.ini
> new file mode 100644
> index 000..c510893
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/erc32.ini
> @@ -0,0 +1,56 @@
> +;
> +; RTEMS Tools Project (http://www.rtems.org/)
> +; Copyright 2015 On-Line Applications Research Corporation (OAR).
> +; All rights reserved.
> +;
> +; This file is part of the RTEMS Tools package in 'rtems-tools'.
> +;
> +; Redistribution and use in source and binary forms, with or without
> +; modification, are permitted provided that the following conditions are met:
> +;
> +; 1. Redistributions of source code must retain the above copyright notice,
> +; this list of conditions and the following disclaimer.
> +;
> +; 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +; this list of conditions and the following disclaimer in the documentation
> +; and/or other materials provided with the distribution.
> +;
> +; THIS SOFTWAR

[PATCH 2/2] Review and help

2017-06-11 Thread Tanu Hari Dixit

Few of the new ini files
---
 tester/rtems/testing/bsps/erc32-run.ini |  54 ++
 tester/rtems/testing/bsps/erc32.ini |  56 ++
 tester/rtems/testing/defaults.ini   | 126 
 tester/rtems/testing/testing.ini|  57 +++
 4 files changed, 293 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/erc32-run.ini
 create mode 100644 tester/rtems/testing/bsps/erc32.ini
 create mode 100644 tester/rtems/testing/defaults.ini
 create mode 100644 tester/rtems/testing/testing.ini

diff --git a/tester/rtems/testing/bsps/erc32-run.ini 
b/tester/rtems/testing/bsps/erc32-run.ini
new file mode 100644
index 000..4135426
--- /dev/null
+++ b/tester/rtems/testing/bsps/erc32-run.ini
@@ -0,0 +1,54 @@
+;
+; RTEMS Tools Project (http://www.rtems.org/)
+; Copyright 2015 On-Line Applications Research Corporation (OAR).
+; All rights reserved.
+;
+; This file is part of the RTEMS Tools package in 'rtems-tools'.
+;
+; Redistribution and use in source and binary forms, with or without
+; modification, are permitted provided that the following conditions are met:
+;
+; 1. Redistributions of source code must retain the above copyright notice,
+; this list of conditions and the following disclaimer.
+;
+; 2. Redistributions in binary form must reproduce the above copyright notice,
+; this list of conditions and the following disclaimer in the documentation
+; and/or other materials provided with the distribution.
+;
+; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+; AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+; ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+; LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+; CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+; SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+; INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+; CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+; ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+; POSSIBILITY OF SUCH DAMAGE.
+;
+
+;
+; All paths in defaults must be Unix format. Do not store any Windows format
+; paths in the defaults.
+;
+; Every entry must describe the type of checking a host must pass.
+;
+; Records:
+;  key: type, attribute, value
+;   type : none, dir, exe, triplet
+;   attribute: none, required, optional
+;   value: 'single line', '''multi line'''
+;
+
+;
+; The erc32 BSP
+;
+[erc32]
+bsp = erc32
+arch = sparc
+
+[run]
+run = %{_rtscripts}/run.cfg
+bsp_run_cmd = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run
+bsp_run_opts = ''
diff --git a/tester/rtems/testing/bsps/erc32.ini 
b/tester/rtems/testing/bsps/erc32.ini
new file mode 100644
index 000..c510893
--- /dev/null
+++ b/tester/rtems/testing/bsps/erc32.ini
@@ -0,0 +1,56 @@
+;
+; RTEMS Tools Project (http://www.rtems.org/)
+; Copyright 2015 On-Line Applications Research Corporation (OAR).
+; All rights reserved.
+;
+; This file is part of the RTEMS Tools package in 'rtems-tools'.
+;
+; Redistribution and use in source and binary forms, with or without
+; modification, are permitted provided that the following conditions are met:
+;
+; 1. Redistributions of source code must retain the above copyright notice,
+; this list of conditions and the following disclaimer.
+;
+; 2. Redistributions in binary form must reproduce the above copyright notice,
+; this list of conditions and the following disclaimer in the documentation
+; and/or other materials provided with the distribution.
+;
+; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+; AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+; ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+; LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+; CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+; SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+; INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+; CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+; ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+; POSSIBILITY OF SUCH DAMAGE.
+;
+
+;
+; All paths in defaults must be Unix format. Do not store any Windows format
+; paths in the defaults.
+;
+; Every entry must describe the type of checking a host must pass.
+;
+; Records:
+;  key: type, attribute, value
+;   type : none, dir, exe, triplet
+;   attribute: none, required, optional
+;   value: 'single line', '''multi line'''
+;
+
+;
+; The erc32 BSP
+;
+[erc32]
+bsp = erc32
+arch = sparc
+
+[gdb_script]
+gdb = %{_rtscri

[PATCH] Review and help

2017-06-11 Thread Tanu Hari Dixit

These are the changes I made to read the ini files
also, this does succeed in reading them.
But there are a lot of problems to solve.
---
 rtemstoolkit/configuration.py | 11 ---
 rtemstoolkit/git.py   |  1 +
 rtemstoolkit/macros.py| 16 +++-
 rtemstoolkit/options.py   |  1 +
 tester/rt/bsps.py |  4 +++-
 tester/rt/options.py  |  2 +-
 tester/rt/test.py |  9 ++---
 7 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/rtemstoolkit/configuration.py b/rtemstoolkit/configuration.py
index 71ab3ca..459276e 100644
--- a/rtemstoolkit/configuration.py
+++ b/rtemstoolkit/configuration.py
@@ -41,9 +41,14 @@ try:
 import configparser
 except:
 import ConfigParser as configparser
-
-from rtemstoolkit import error
-from rtemstoolkit import path
+
+try :
+from . import error
+from . import path
+except (ValueError, SystemError):
+import error
+import path
+
 
 class configuration:
 
diff --git a/rtemstoolkit/git.py b/rtemstoolkit/git.py
index 5f3af58..4a6f2f8 100644
--- a/rtemstoolkit/git.py
+++ b/rtemstoolkit/git.py
@@ -80,6 +80,7 @@ class repo:
 self.git = 'git'
 else:
 self.git = self.macros.expand('%{__git}')
+#self.git = self.macros.config.get_item('global', '__git')
 
 def git_version(self):
 ec, output = self._run(['--version'], True)
diff --git a/rtemstoolkit/macros.py b/rtemstoolkit/macros.py
index 31f5a7e..4772562 100644
--- a/rtemstoolkit/macros.py
+++ b/rtemstoolkit/macros.py
@@ -48,10 +48,13 @@ try:
 from . import error
 from . import log
 from . import path
+from . import configuration
 except (ValueError, SystemError):
 import error
 import log
 import path
+import configuration
+
 
 #
 # Macro tables
@@ -123,7 +126,16 @@ class macros:
 self.read_map_locked = copy.copy(original.read_map_locked)
 self.write_map = copy.copy(original.write_map)
 if name is not None:
-self.load(name)
+#self.load(name)
+self.config = configuration.configuration()
+self.config.load(name)
+self.add_macros()
+#self.config.load(name)
+
+def add_macros(self):
+for section in self.config.config.sections():
+for label in self.config.config.options(section):
+self.macros[section][label] = 
self.config.get_item(section, label)
 
 def __copy__(self):
 return macros(original = self)
@@ -474,6 +486,8 @@ class macros:
 for m in self.macro_filter.findall(_str):
 name = m[2:-1]
 macro = self.get(name)
+#for section in self.config.config.sections():
+#macro = self.config.get_item(section, name)
 if macro is None:
 raise error.general('cannot expand default macro: %s in 
"%s"' %
 (m, _str))
diff --git a/rtemstoolkit/options.py b/rtemstoolkit/options.py
index 70e9786..3b27a95 100644
--- a/rtemstoolkit/options.py
+++ b/rtemstoolkit/options.py
@@ -427,6 +427,7 @@ class command_line(object):
 return None
 um = []
 configs = self.defaults.expand('%{_configdir}').split(':')
+#configs = self.defaults.config.get_item('%{_configdir}').split(':')
 for m in self.opts['macros'].split(','):
 if path.exists(m):
 um += [m]
diff --git a/tester/rt/bsps.py b/tester/rt/bsps.py
index 91f5f62..048d85c 100644
--- a/tester/rt/bsps.py
+++ b/tester/rt/bsps.py
@@ -33,7 +33,9 @@ from rtemstoolkit import log
 from rtemstoolkit import path
 
 def list(opts):
-path_ = opts.defaults.expand('%%{_configdir}/bsps/*.mc')
+#path_ = opts.defaults.expand('%%{_configdir}/bsps/*.mc')
+path_ = opts.defaults.expand('%%{_configdir}/bsps/*.ini')
+#path_ = opts.defaults.config.get_item('%%{_configdir}/bsps/*.mc')
 bsps = path.collect_files(path_)
 log.notice(' BSP List:')
 for bsp in bsps:
diff --git a/tester/rt/options.py b/tester/rt/options.py
index d41b721..85888d2 100644
--- a/tester/rt/options.py
+++ b/tester/rt/options.py
@@ -52,7 +52,7 @@ from rtemstoolkit import version
 #
 # The path for the defaults.
 #
-defaults_mc = 'rtems/testing/defaults.mc'
+defaults_mc = 'rtems/testing/defaults.ini'
 
 class command_line(options.command_line):
 """Process the command line in a common way for all Tool Builder 
commands."""
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 7a35f59..7056667 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -219,7 +219,9 @@ def _job_trace(tst, msg, total, exe, active, reporting):
 reporting, total, exe, s))
 
 def list_bsps(opts):
-path_ = opts.defaults.expand('%%{_configdir}/bsps/*.mc')
+#path_ = opts.defaults.expand('%%{_configdir}/bsps/*.mc')
+path_ = opts.defaults.e

Re: [PATCH v3] User Manual: Added rtems-tester in the docs

2017-06-01 Thread Tanu Hari Dixit

Thank you, Chris, for the review. I have made the changes and sent
again as version 4 patches. I have split the commits into 2 parts (one
not containing the ini bits for v4.12 release and the other one
containing it). Kindly review them.
Thank you for your time.
Tanu.

On Thu, Jun 1, 2017 at 7:10 AM, Chris Johns  wrote:
> Thanks for patch. Comments in the email.
>
> Note, I seem to have broken the section headings and will fix soon.
>
> On 31/05/2017 23:33, Tanu Hari Dixit wrote:
>> Adds as part of Tools
>> ---
>>  user/tools/index.rst|   1 +
>>  user/tools/rtems-tester.rst | 636 
>> 
>>  2 files changed, 637 insertions(+)
>>  create mode 100644 user/tools/rtems-tester.rst
>>
>> diff --git a/user/tools/index.rst b/user/tools/index.rst
>> index d77a7ca..9e2ca89 100644
>> --- a/user/tools/index.rst
>> +++ b/user/tools/index.rst
>> @@ -21,3 +21,4 @@ executables.
>>  .. include:: exeinfo.rst
>>  .. include:: trace-linker.rst
>>  .. include:: bsp-builder.rst
>> +.. include:: rtems-tester.rst
>
> Please call the file 'tester.rst'. This makes the naming consistent with the
> other commands (hint: git mv ...).
>
>> diff --git a/user/tools/rtems-tester.rst b/user/tools/rtems-tester.rst
>> new file mode 100644
>> index 000..425a1fb
>> --- /dev/null
>> +++ b/user/tools/rtems-tester.rst
>> @@ -0,0 +1,636 @@
>> +.. comment SPDX-License-Identifier: CC-BY-SA-4.0
>> +
>> +.. comment: Copyright (c) 2017 Chris Johns 
>> +.. comment: All rights reserved.
>> +
>> +RTEMS Tester
>> +
>> +
>> +.. index:: Tools, rtems-tester
>> +
>> +The RTEMS Tester is a test framework. It includes a command line interface 
>> to
>> +run tests on supported targets. The framework provides back-end support for
>> +common simulators and debuggers. The board support package (BSP) 
>> configurations
>> +for RTEMS are provided and can be used to run all the tests provided with
>> +RTEMS. The framework is not specific to RTEMS and can be configured to run 
>> any
>> +suitable application.
>> +
>> +RTEMS is an embedded operating system and is cross-compiled on a range of 
>> host
>> +machines. The executables run on the target hardware and this can vary 
>> widely
>> +from open source simulators, commercial simulators, debuggers with 
>> simulators,
>> +to debuggers with hardware specific pods and devices. Testing RTEMS requires
>> +the cross-compiled test executable is transferred to the target hardware,
>> +executed and the output returned to the host where it is analyzed to 
>> determine
>> +the test result. The RTEMS Tester provides a framework to do this.
>> +
>> +Running all the RTEMS tests on your target is very important. It provides 
>> you
>> +with a traceable record showing that your RTEMS version and its tools are
>> +working at the level the RTEMS development team expect when releasing
>> +RTEMS. Being able to easily run the tests and verify the results is 
>> critical in
>> +maintaining a high standard.
>> +
>> +The RTEMS Tester contains:
>> +
>> +* Command line tool (``rtems-test``)
>
> Please use ":program:`rtems-test`". There are other places that need updating.
>
>> +* BSP Configuration scripts
>> +* Back-end Configuration scripts
>> +* Back-end Python classes
>> +* Python based framework
>> +
>> +This document is for users of the RTEMS Tester as well as those wanting to
>> +develop, extend and investigate the RTEMS Tester.
>
> I think "The RTEMS Tester contains:" ... here can be removed.
>
>> +
>> +License
>> +---
>> +
>> +The RTEMS Tester is part of the RTEMS Tools Project. The code is released 
>> under
>> +the OSI approved "The BSD 2-Clause License". It is free to use and we 
>> encourage
>> +this, including on operating systems other than RTEMS.
>> +
>> +The code and command line tools must retain the same names and always 
>> reference
>> +the RTEMS Tools Project.
>> +
>
> This section can be removed.
>
>> +Quick Start
>> +---
>> +
>> +The quick start will show you how to run the test suite for a BSP. It will
>> +explain how to get the RTEMS Tester, set it up and run the tests for the 
>> erc32
>> +BSP. It assumes you have a valid SPARC tool chain and have built the erc32 
>> BSP
>> +version of RTEMS 4.12.
>> +
>> +Setup
>> +-
>> +
>> +Set

[PATCH v4 2/2] User Manual: Added ini format in rtems-tester

2017-06-01 Thread Tanu Hari Dixit

Added specification for ini format for configuration
files in documentation of rtems-tester
---
 user/tools/tester.rst | 134 ++
 1 file changed, 134 insertions(+)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index ae8c3b6..966a373 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -66,6 +66,140 @@ There is the ``erc32`` tester which uses the GDB back-end 
and the
 how to use :program:`rtems-test` command with the erc32 BSP because it is easy 
 to build an use.
 
+Adding support for a BSP to the tester
+--
+
+To add support for a BSP, one should add a configuration file in 
+``rtems-tools.git/tester/rtems/testing/bsps``. The configuration files 
+should be specified in an INI file. The configuration files provide a 
+means to the backend of `rtems-tester` to automate the running of tests.
+There is the  tester which uses the GDB back-end and the 
``-run`` 
+tester which uses the command line version of the respective simulator.
+The general format for specifying an INI configuration file is as follows:
+
+``.ini``:
+
+.. code-block:: shell
+
+[]
+bsp = ''
+gdb = '%{_rtscripts}/gdb.cfg'
+arch = ''
+
+[gdb_script]
+gdb_script ='_gdb_script'
+_gdb_script =   ''
+
+``-run.ini``:
+
+.. code-block:: shell
+
+[]
+bsp = ''
+
+[run]
+run = '%{_rtscripts}/run.cfg'
+arch = ''
+bsp_run_cmd = '%{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run'
+bsp_run_opts = ''
+
+Here is an example:
+
+``arm7tdmi.ini``:
+
+.. code-block:: shell
+
+[arm7tdmi]
+bsp = 'arm7tdmi'
+gdb = '%{_rtscripts}/gdb.cfg'
+arch = 'arm'
+
+[gdb_script]
+gdb_script ='arm7tdmi_gdb_script'
+arm7tdmi_gdb_script =   'target sim
+load
+run'
+
+``arm7tdmi-run.ini``:
+
+.. code-block:: shell
+
+[arm7tdmi]
+bsp = 'arm7tdmi'
+
+[run]
+run = '%{_rtscripts}/run.cfg'
+arch = 'arm'
+bsp_run_cmd = '%{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-run'
+bsp_run_opts = '-a -nouartrx'
+
+If the tester should run the tests on qemu for a bsp, the given pattern can 
+be followed:
+
+.. code-block:: shell
+
+[]
+bsp = ''
+
+[qemu-script]
+run = '%{_rtscripts}/qemu.cfg'
+arch = ''
+opts = '%{qemu_opts_base} %{qemu_opts_no_net} -m 32M'
+
+For instance,
+
+``generic_or1k.ini``:
+
+.. code-block:: shell
+
+[generic_or1k]
+bsp = 'generic_or1k'
+
+[qemu-script]
+run = '%{_rtscripts}/qemu.cfg'
+arch = 'or32'
+opts = '%{qemu_opts_base} %{qemu_opts_no_net} -m 32M'
+
+User can also provide a "settings.ini" file in case a configuration file needs 
+a path to, for instance, a first stage bootloader (fsbl) that is placed 
+somewhere in the host machine. The settings.ini file can be passed with 
+``rtems-test --with-settings = /path/to/settings/file`` option. The 
+.ini can contain defaults and the settings file can contain the 
+user-specified configuration.
+
+
+``xilinx_zynq_zc706.ini``:
+
+.. code-block:: shell
+
+[xilinx_zynq_zc706]
+bsp = 'xilinx_zynq_zc706'
+jobs = '1'
+
+[gdb-script]
+gdb = '%{_rtscripts}/gdb.cfg'
+arch = 'arm'
+bsp_tty_dev =  ${settings:bsp_tty_dev}
+gdb_script = 'xilinx_zynq_zc706_gdb_script'
+xilinx_zynq_zc706_gdb_script = 'target remote kaka:
+mon load_image ${settings:path_to_fsbl} 0 elf
+mon resume 0
+mon sleep 4000
+mon halt
+load
+b bsp_reset
+continue'
+
+``settings.ini``:
+
+.. code-block:: shell
+
+[settings]
+bsp_tty_dev = '/dev/cu.SLAB_USBtoUART'
+path_to_fsbl = '/path/to/fsbl'
+
 Building RTEMS Tests
 
 
-- 
2.1.4

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

[PATCH v4] User Manual: Added rtems-tester in the docs

2017-06-01 Thread Tanu Hari Dixit

Added as part of Tools.
Made changes according to Chris' review
Also removed the ini format part inline with
the new release that is expected.
---
 user/tools/index.rst  |   1 +
 user/tools/tester.rst | 446 ++
 2 files changed, 447 insertions(+)
 create mode 100644 user/tools/tester.rst

diff --git a/user/tools/index.rst b/user/tools/index.rst
index d77a7ca..613ceb9 100644
--- a/user/tools/index.rst
+++ b/user/tools/index.rst
@@ -21,3 +21,4 @@ executables.
 .. include:: exeinfo.rst
 .. include:: trace-linker.rst
 .. include:: bsp-builder.rst
+.. include:: tester.rst
diff --git a/user/tools/tester.rst b/user/tools/tester.rst
new file mode 100644
index 000..ae8c3b6
--- /dev/null
+++ b/user/tools/tester.rst
@@ -0,0 +1,446 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2017 Chris Johns 
+.. comment: All rights reserved.
+
+RTEMS Tester
+
+
+.. index:: Tools, rtems-tester
+
+The RTEMS Tester is a test framework. It includes a command line interface to
+run tests on supported targets. The framework provides back-end support for
+common simulators and debuggers. The board support package (BSP) configurations
+for RTEMS are provided and can be used to run all the tests provided with
+RTEMS. The framework is not specific to RTEMS and can be configured to run any
+suitable application.
+
+RTEMS is an embedded operating system and is cross-compiled on a range of host
+machines. The executables run on the target hardware and this can vary widely
+from open source simulators, commercial simulators, debuggers with simulators,
+to debuggers with hardware specific pods and devices. Testing RTEMS requires
+the cross-compiled test executable is transferred to the target hardware,
+executed and the output returned to the host where it is analyzed to determine
+the test result. The RTEMS Tester provides a framework to do this.
+
+Running all the RTEMS tests on your target is very important. It provides you
+with a traceable record showing that your RTEMS version and its tools are
+working at the level the RTEMS development team expect when releasing
+RTEMS. Being able to easily run the tests and verify the results is critical in
+maintaining a high standard.
+
+This document is for users of the RTEMS Tester as well as those wanting to
+develop, extend and investigate the RTEMS Tester.
+
+Available BSP testers
+-
+
+You can list the available BSP testers with:
+
+.. code-block:: shell
+
+$ rtems-test --list-bsps
+arm920
+beagleboardxm
+jmr3904-run
+jmr3904
+mcf5235
+psim-run
+psim
+realview_pbx_a9_qemu
+sis-run
+sis
+xilinx_zynq_a9_qemu
+xilinx_zynq_a9_qemu_smp
+xilinx_zynq_zc706
+xilinx_zynq_zc706_qemu
+
+.. note:: The list is growing all the time and if your BSP is not supported we 
+  encourage you to add it and submit the configuration back to the 
+  project.
+
+Some of the BSPs may appear more than once in the list. These are aliased BSP
+configurations that may use a different back-end. An example is the erc32 BSP. 
+There is the ``erc32`` tester which uses the GDB back-end and the 
+``erc32-run`` tester which uses the ``run`` command for erc32. We will show 
+how to use :program:`rtems-test` command with the erc32 BSP because it is easy 
+to build an use.
+
+Building RTEMS Tests
+
+
+Build the RTEMS Kernel (See :ref:`rtems-kernel`) by cloning the repository, 
+running the ``bootstrap`` procecure, building and finally installing the 
+kernel. Be sure to enable tests by using ``--enable-tests`` option with 
+configure after running ``bootstrap``.
+
+.. code-block:: shell
+
+$ ../../rtems.git/configure --target=sparc-rtems4.12 \
+--enable-tests --enable-rtemsbsp=erc32
+$ make 
+
+Add the -j option to the make command with the number of cores to run the 
+build parallel where it can.
+
+Building all the tests takes time and it uses more disk so be patient. When
+finished all the tests will be built and ready to run. Before running all the 
+tests it is a good idea to run the ``hello`` test. The ``hello`` test is an 
+RTEMS version of the classic "Hello World" example and running it shows you 
+have a working tool chain and build of RTEMS ready to run the tests. Using the 
+run command:
+
+.. code-block:: shell
+
+$ sparc-rtems4.12-run 
sparc-rtems4.12/c/erc32/testsuites/samples/hello/hello.exe
+
+*** BEGIN OF TEST HELLO WORLD ***
+Hello World
+*** END OF TEST HELLO WORLD ***
+
+The run command is the GDB simulator without the GDB part.
+
+Running the example using GDB:
+
+.. code-block:: shell
+
+$ sparc-rtems4.12-gdb 
sparc-rtems4.12/c/erc32/testsuites/samples/hello/hello.exe
+GNU gdb (GDB) 7.12
+Copyright (C) 2016 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later 

+This is free softwa

Re: [PATCH] Added documentation for rtems-tester in rtems-docs

2017-05-31 Thread Tanu Hari Dixit

Hello Chris, Gedare,
I have revised the patch and sent it again. Thank you.
Tanu.

On Wed, May 31, 2017 at 6:09 AM, Chris Johns  wrote:
> On 31/05/2017 03:10, Tanu Hari Dixit wrote:
>>
>>
>> I just added the image following what was already in rtems-tools.git
>> repo. Maybe it is not really needed there. Maybe it was added to the
>> previous doc because it was a stand-alone doc.
>
>
> Yes this is correct. The User Manual is newer and has a consistent feel we
> must maintain.
>
>> I will pull that out.
>> What do you think? What does Chris think?
>
>
> The text needs to be merged into the User Manual converting it to ReST
> format. I suggest you review the RTEMS BSP Builder [1] command as an
> example. That format _must_ be followed for the Tools. Please create a new
> file for this command and include after the RTEMS BSP Builder command.
>
> Thanks
> Chris
>
> [1]
> https://docs.rtems.org/branches/master/user/tools/index.html#rtems-bsp-builder
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] User Manual: Added rtems-tester in the docs

2017-05-31 Thread Tanu Hari Dixit

Adds as part of Tools
---
 user/tools/index.rst|   1 +
 user/tools/rtems-tester.rst | 636 
 2 files changed, 637 insertions(+)
 create mode 100644 user/tools/rtems-tester.rst

diff --git a/user/tools/index.rst b/user/tools/index.rst
index d77a7ca..9e2ca89 100644
--- a/user/tools/index.rst
+++ b/user/tools/index.rst
@@ -21,3 +21,4 @@ executables.
 .. include:: exeinfo.rst
 .. include:: trace-linker.rst
 .. include:: bsp-builder.rst
+.. include:: rtems-tester.rst
diff --git a/user/tools/rtems-tester.rst b/user/tools/rtems-tester.rst
new file mode 100644
index 000..425a1fb
--- /dev/null
+++ b/user/tools/rtems-tester.rst
@@ -0,0 +1,636 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2017 Chris Johns 
+.. comment: All rights reserved.
+
+RTEMS Tester
+
+
+.. index:: Tools, rtems-tester
+
+The RTEMS Tester is a test framework. It includes a command line interface to
+run tests on supported targets. The framework provides back-end support for
+common simulators and debuggers. The board support package (BSP) configurations
+for RTEMS are provided and can be used to run all the tests provided with
+RTEMS. The framework is not specific to RTEMS and can be configured to run any
+suitable application.
+
+RTEMS is an embedded operating system and is cross-compiled on a range of host
+machines. The executables run on the target hardware and this can vary widely
+from open source simulators, commercial simulators, debuggers with simulators,
+to debuggers with hardware specific pods and devices. Testing RTEMS requires
+the cross-compiled test executable is transferred to the target hardware,
+executed and the output returned to the host where it is analyzed to determine
+the test result. The RTEMS Tester provides a framework to do this.
+
+Running all the RTEMS tests on your target is very important. It provides you
+with a traceable record showing that your RTEMS version and its tools are
+working at the level the RTEMS development team expect when releasing
+RTEMS. Being able to easily run the tests and verify the results is critical in
+maintaining a high standard.
+
+The RTEMS Tester contains:
+
+* Command line tool (``rtems-test``)
+* BSP Configuration scripts
+* Back-end Configuration scripts
+* Back-end Python classes
+* Python based framework
+
+This document is for users of the RTEMS Tester as well as those wanting to
+develop, extend and investigate the RTEMS Tester.
+
+License
+---
+
+The RTEMS Tester is part of the RTEMS Tools Project. The code is released under
+the OSI approved "The BSD 2-Clause License". It is free to use and we encourage
+this, including on operating systems other than RTEMS.
+
+The code and command line tools must retain the same names and always reference
+the RTEMS Tools Project.
+
+Quick Start
+---
+
+The quick start will show you how to run the test suite for a BSP. It will
+explain how to get the RTEMS Tester, set it up and run the tests for the erc32
+BSP. It assumes you have a valid SPARC tool chain and have built the erc32 BSP
+version of RTEMS 4.12.
+
+Setup
+-
+
+Set up a development work space:
+
+.. code-block:: shell
+
+$ cd
+$ mkdir -p development/rtems/test
+$ cd development/rtems/test
+
+First fetch the RTEMS tester from the RTEMS Tools repository:
+
+.. code-block:: shell
+
+$ git clone git://git.rtems.org/rtems-tools.git rtems-tools.git
+$ cd rtems-tools.git/tester
+
+Available BSP testers
+-
+
+You can list the available BSP testers with:
+
+.. code-block:: shell
+
+$ ./rtems-test --list-bsps
+arm920
+beagleboardxm
+jmr3904-run
+jmr3904
+mcf5235
+psim-run
+psim
+realview_pbx_a9_qemu
+sis-run
+sis
+xilinx_zynq_a9_qemu
+xilinx_zynq_a9_qemu_smp
+xilinx_zynq_zc706
+xilinx_zynq_zc706_qemu
+
+.. note:: The list is growing all the time and if your BSP is not supported we 
+  encourage you to add it and submit the configuration back to the 
project.
+
+Some of the BSPs may appear more than once in the list. These are aliased BSP
+configurations that may use a different back-end. An example is the SPARC
+Instruction Simulator (SIS) BSP. There is the 'sis' tester which uses the GDB
+back-end and the 'sis-run' tester which uses the command line version of the 
SIS
+simulator. We will show how to use ``rtems-test`` command with the SIS BSP
+because it is easy to build an use.
+
+Adding support for a BSP to the tester
+--
+
+To add support for a BSP, one should add a configuration file in 
+``rtems-tools.git/tester/rtems/testing/bsps``. The configuration files 
+should be specified in an INI file. The configuration files provide a 
+means to the backend of `rtems-tester` to automate the running of tests.
+There is the  tester which uses the GDB back-end and the 
``-run`` 
+tester which uses the command line version of the

Re: [PATCH] Fixes typos in README.txt

2017-05-31 Thread Tanu Hari Dixit

Hello Chris,
I have fixed the above authorship issue and sent the patch again. Thank you.
Regards,
Tanu.

On Wed, May 31, 2017 at 7:26 AM, Chris Johns  wrote:
> On 29/05/2017 22:29, Tanu Hari Dixit wrote:
>>
>> From: tokencolour 
>
>
> Could we please have your name in the commit? It make the git log much more
> meaningful. For example:
>
> From: Tanu Hari Dixit 
>
> Thanks
> Chris
>
>
>>
>> 2 typos fixed
>> ---
>>   README.txt | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/README.txt b/README.txt
>> index f09317e..c1b7e6f 100644
>> --- a/README.txt
>> +++ b/README.txt
>> @@ -316,7 +316,7 @@ existing documentation for an example and if unsure
>> ask.
>> Heading   Description
>> 1  ## Part
>> 2  ** Section
>> -  3  == Sub-ection
>> +  3  == Sub-section
>> 4  -- Sub-sub-section
>> 5  ^^ Sub-sub-sub-section
>> 6  ~~ Sub-sub-sub-sub-section
>> @@ -392,7 +392,7 @@ existing documentation for an example and if unsure
>> ask.
>>users: Users Mailing List
>>vc   : Version Control Mailing List
>>   -  The valif URLs are:
>> +  The valid URLs are:
>>  trac : https://devel.rtems.org/
>>devel: https://devel.rtems.org/
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Fixes typos in README.txt

2017-05-31 Thread Tanu Hari Dixit

2 typos fixed
---
 README.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.txt b/README.txt
index f09317e..c1b7e6f 100644
--- a/README.txt
+++ b/README.txt
@@ -316,7 +316,7 @@ existing documentation for an example and if unsure ask.
   Heading   Description
   1  ## Part
   2  ** Section
-  3  == Sub-ection
+  3  == Sub-section
   4  -- Sub-sub-section
   5  ^^ Sub-sub-sub-section
   6  ~~ Sub-sub-sub-sub-section
@@ -392,7 +392,7 @@ existing documentation for an example and if unsure ask.
  users: Users Mailing List
  vc   : Version Control Mailing List
 
-  The valif URLs are:
+  The valid URLs are:
 
  trac : https://devel.rtems.org/
  devel: https://devel.rtems.org/
-- 
2.1.4

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

Re: rtems-test runtime errors qemu.cfg

2017-05-30 Thread Tanu Hari Dixit

Hi Cillian,

I usually do a git grep -i "" to find out where possibly a
macro or variable is used elsewhere in the code. Not the best way, but
works mostly.
Also %{qemu_cmd} has been defined here in the same file
(https://devel.rtems.org/browser/rtems-tools/tester/rtems/testing/qemu.cfg#L60).
I also sometimes use winpdb to see what value a macro has but this is
a long process to step into each line.
I wanted to ask what command did you use exactly with rtems-test? I
couldn't find a recipe for qemu simulation for pc386 in
rtems-tools.git/tester/rtems/testing/bsps.

Regards,
Tanu Hari Dixit.

On Wed, May 31, 2017 at 12:42 AM, Cillian O'Donnell
 wrote:
> Hi,
>
> I'm trying to run rtems-test for pc386 with the added --coverage tag for
> couverture-qemu. All tests default to dry-run because of errors in qemu.cfg
>
> error: qemu.cfg:81: execute failed: qemu-system-i386 -m 128 -boot b -hda
> /home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/rtems-boot.img
> -no-reboot -serial null -serial mon:stdio -nographic -append
> "--console=com1;boot;" -kernel
> /home/cpod/development/rtems/pc386/i386-rtems4.12/c/pc386/testsuites/samples/unlimited/unlimited.exe
> -exec-trace coverage/unlimited.exe.cov: exit-code:2
> warning: switched to dry run due to errors
>
> The exit code I believe refers to 'no such file or directory'. In qemu.cfg
> the line is:
>
> %execute %{qemu_cmd} %{qemu_opts} -kernel %{test_executable} %{coverage_arg}
>
> It's a bit tricky to trace those macros back to different files and see what
> they have. Is there any way to just print those out when it runs so I can
> take a look at them.
>
> I tried %print %{qemu_cmd} and  %echo %{qemu_cmd}. Is there any way to do
> this in a config file?
>
> Thanks,
>
> Cillian.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added documentation for rtems-tester in rtems-docs

2017-05-30 Thread Tanu Hari Dixit

Hello Gedare,

I have sent the patches separately.

Thank you,
Tanu.

On Tue, May 30, 2017 at 10:50 PM, Gedare Bloom  wrote:
> On Tue, May 30, 2017 at 1:10 PM, Tanu Hari Dixit  
> wrote:
>> Hello Gedare,
>>
>> I just added the image following what was already in rtems-tools.git
>> repo. Maybe it is not really needed there. Maybe it was added to the
>> previous doc because it was a stand-alone doc. I will pull that out.
>> What do you think? What does Chris think?
>>
>> Regards,
>> Tanu.
>>
>
> Send the text change separately for review from the image. thanks.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] Added the logo for documentation of rtems-tester

2017-05-30 Thread Tanu Hari Dixit

---
 images/user/rtemswhitebg.jpg | Bin 0 -> 117890 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 images/user/rtemswhitebg.jpg

diff --git a/images/user/rtemswhitebg.jpg b/images/user/rtemswhitebg.jpg
new file mode 100644
index 
..f883f2c495d4d91ef94d35e28995b9d2b7a863f7
GIT binary patch
literal 117890
zcmeFZ2V4}%wm;tF43dMupyX^KNf;4HA|go?gi#OykqnY&35)?%QB?yQx3J6FV
za!_C-tHdE^7~%jEevP|#ckk}Ld+&Sy_ul8e&wtxb569}N?mDMVo%){Br<(kgJO&&%
zt7oVOP*6|+2H-z{JkET{P)7%L!OTR@@SHAq0RWf{&bhdIP#ypPH+NreGyT&dmo8h2
z&~*Zo00Te^90h=D4nCg7=6V(Yco^#Hi1>h&_UWGw@E%+J0Qd_4J@N(@L_~fr|5yL8
zJ9v8g0szGYu)*=`jy?_`9R||3{Cz$5%U3~~%ieXLrlj7dy}=HGG~Yh$^b;-jqs~wC
zseSsooBMUJ&VHXgue)8}ryD`~!EHZBkfu5Z(h;{^9Q{GM7o^2*`MJ4(G#;e6+#Ij@
z001@fez~usgEL4U0cmD$3o{*%)&Kx{W~blK_P?Qh9Rt9A0)UQ(XP~!>le4dgl!LU$
zQ8hJH5d%m6TaLcI@)xc-xL)(VE~4Y%=6TIM5CDGSdA}9Fu`gQ@P{_(h)s&Uxk12rS
z|K<3H7k{bskBR-U{i(*f>5nm^;A#K0?ANxxmU(0Vfa)eFn@7Kv**^n-vTy+4`~GX0
z*h>Il3j=^s%y0PN+1D3mUtiCYii-aJ{t7OR4hs7M{pI+l6@IDt9}~ZMp2Gg~evzHX
z8OIyf{BHS*>yv0K)}PEwuyGoJ;`Kl{D}Q
z#V_M_j^QG(Kl7|0Ge7A)NQ2jZ{Qlh!B@+BErH_k~$bPYonT3dhpZD#38k`gRKQsU%
zzy@#u{D3eZ3P=I+z%f7tPzO!{y1-e$1h4=u19pG|;0(9{-he+40^9{6fEeHr@EAw|
z(t#`>4=4nRfHI&8r~{gT&%hU;4;Tc-fGJ=BSOvC#JOQt(qiD8wmbDUMO7
zQfN`=QkCJRETycY{7l(LIYzla
zxk&|3F;VeQ9ioz_Ql-+NGNH1jx!RY+Aq)k4)nHAb~awL?uy%}Fgn
zEl;gZZ9r{F?Lh5C4X2K!PNB}FE~Rdy?xDs~uTqm}SZD-kWNA*)7}8v#aia03iJ*Bx
z^P1)ZO%qKY%@oZREiEk%tt71qtpV+2+MBe&w6U}=Xi>Dav|Y3lw3~Evbo_L(beeP~
zbl2#7=_2T!(Y>WZ({D}q?(LbSoLtjJRO+Q1w$8dl_oZ%#c
z3Bz@UKn5g37DELChGB|fkCB~Gl2MbL#rTM*k5wqiC6+u{L+0}=;x4qQ6`Kk)p(#{&Zg
zHrYAZkFuMvyRpZzzhQ4A-oPGmEo{bBc?W
zOOnfw>n2wWR{>Wi*D5y$_X+Nc+yUIrxvROyc&K;u5GX>iPH-&_S^o2Zyo(VMwEei7ppAx<)oFrT$JO|-~XhB>c
zNf0z-UW8jjTjZ9=Q;|lI)kA`Z3=a7ndUdGt(B5Im!bP~FF7Q|A_bN5lFE?k
zm8O+em3EbWA^k;$QbtL}S?0M6MwU`mS=L4Ng>07`jhvdCyIh9cfIPFjw)}1Re0i(_
zkHR^HdkSR=%Zg%(){60pEsCTgN=I%T$vQH4l;h~xqxX(h99=smbIjq`^JBfoS&r)+
zM;tFdjyoZH!tq4fiLXkWO2$f&O7%)aWff&_h-A^ZE5YB+HbX&Paiq$efq=cZJm=kp*po^sLtr0i9XY*%b{zjo1#0S
zcUaF!FJEs}Ur9e$zt(`pz{nupV8Bqw(7`azaP_Rp+0e6%M$AU$Mkz+)=VZ=#pQ|vY
zG(KybXgqXY{Ji`5G84eW&?M1h_=4mGuM3r?w5AtKpPNpb9W@IvYcc0Ehnc@I-?BJu
zfwUO3l(O`*tiQ;1@yf-#i`!ObtP-roE-79Lz4ZCAz-5=q<<@l87p-4gZ`$bEJhqv-
zqI4zVO24h7ZGdf?oq*jfyJ{F4>>8~2D$P}^t8cCnu9;lRxVC9;XrF4o>Y(G0?67eC
z)b*t6bB>yh363*2G;bu_n03;0N_3iYhB`lSUUboMNpZp5G`N|5bKBL#HOG~F%jy=&
zjo$65+edc}cUSjD4`Gi0k1kJH&j`;kuajPny;i-AykGlJ_}KcC`*ML`s@+e@FWe7%
zTkH1o+j#$r{>1_80qz0qfii(nfippRLD|97!4ARoA%{ZlhG0XrLtnuu;P&u(geW2m
zF?C1(PVQaCyRLUT?j5<8aBt(j)%}Vvp|Cq)6XE*d`4OxU-VpXGRWs2{jI=!`lZ
z^(=}MeLeb9%#oNUF@#u$*iR3SK79I+9CstG6RC_$dqn%l{ZW5BG(I~Y(Z6Hn5U8I%2z$DW>hTK-Jz*`sHK6z7z_=ck{eQUz0^Qnz1Rf6<+G
zDy=YGC_N^9_od6rudno9m1am}JjtZZyq!6nbup_YTQxiHwZQ9`*Tfw6oUvT9+{QeW
zyu3GpZ;<(v`F{CxZ?C-lQgEiAyimUI6^aKH^A33D_iq0E)%X2HMn(0-s>OvR;w7mc
zI6p*}Qj`Xku9i8Mjg?<6@A`Q5V||5s#fM6T%ABf0RnM!rtC2N~HDNVmbP#&8*0Xl8
z&Z%yq9#%itaH*lU(X_F%$*8HdS+BXFMY{#vs@YoAcCzi`C)H17pOrtCwkx%N=uqnT
z(5c*6ic!Ioe^L8V(WTK<(+%ye>p9cY+-unTx$k^mSHETd*MTboV_&a-o&9#}8}9q<
z?|XxHhG>SOhYt)t84(=G7?mDHjVX^+W6xmQ$IZtFCmbdgCVeIeQ(@CA(@$m~GkLSe
zW~=7(=Dy6^%ug+NF6=EvEU_=8E=w(!tejeDU%j+Ch4aRd*J9WC*K;;bY}9XF*c{n%
z+uGZX#`EKIcT{&;cCB`2_WTKSgr`JlVg<>FG(>hIlgU`1S2w`r1^^fv12P~Qpaxm@rIML%S|6&zuW!+fkF4f
z!XqLdL`5egCOv+V{PbB$MrKy_>zv%YH$}xIA4<#0KUUN?G&VK2w6=Zf?&w>@Gdm>G)Ug>lj3jo2_!&dv`JNh@HTS&S(n9)`e><_lz*N7{xV20
zq)ke-P{319N1P~ZaycDmY#BWKY)r}gW4Wc7&-afuL{o>T2ku7~E?K_S-YkUlqgRYgS#6n);Oc*ZOJx$uVxVetXN<42KWf_{a2jlAL_i09mED{&ug
zL`$Osf;Uhv+TXL%6Yt+!Q;N#x>cZfW&EpJ^?Q%k})l*{}H_u#>$!M=tEPkPhqe-sv
zx?~zU3Pn+gOI^r?j41mDTg_Y=!Zin{e|z*V11F@gkqNzGVKUHj%PD%8XAv
z&pFekwYlSlHQ_zC-Suc@9aW@3fjU7tKP|HBG-vnP{P`!hn<0u1w1my;wM&pSCyezw
z42p(bzbxHgzMr-^2IsDJ5kbm-@kcrL2$mQaVhZ5l_uot+C(;go?h|-;Y5vP{UFS{f
z0`{GNe9inG{U*c9;asNLhjh6vQ2cfN+sc4i0dd=vV}s-2M!~?9ytmIwT1CGXJsSwS
z9Y1L&ZswLg2NMa=O_2(jok~%ilzmii_V->dK*{dHLj)j-h_Kaj(>g6TY3QZEY>wc#dvL&R&@t~$}?=_{o
zyy1A&nVT1HJL%HbrxcyEV5lX?cy(8Yzuy@e{#s(Hd+aaF@b8VAXg`=gI~F#PYB@w@
z`tB3N`k6da*kY%OS&1V1M5@)e6M>6%baAxQBhn(4XVtF~F*!9$dc2pXp$ua6EE5b0;0>(&fg#BII(ZJJeEf6Xnk)7?4KVj~2cyY_njMIqS^F
zH9xB#$7QMu{B{1D%it+j$pz|j(ZN>OZ30*JY0|JT7vMmWGJ+8m(5Rs+RItd=RkIPO
zJDPzEe2oMRV)no$?n($6E54h#KFTFd2I$RTBT+jOx?EP+$aMp&f)Hwc;ztrw-fT!<
z<_sC2dW8~4S>tKQfMnmQ4XLFALI#Xp6;{#hbwF{79YWt6$iS^^k`&3A^!)MBC399i
z6N$$`W&<1J(4xU|(CcmdONai=b?E1L&W#TSjgmYWNL*M=CqB51-nB)*$}Rt_l(%Jc
zO&T$-Ka(bfXpMu7|Exbw>lZ-%p#twPhX?QDFcJ^y+n0fafj=p`BKC+HkgV$xqq^M6BW_Q&b}tm5#$PQ=irOy2KNx;%At)Hh99`HKCw
z>+fkFl3o{g)IsV;A0N3g^^s-AwB2QqKNlj}pUQgko>94HR$sV1BJ9hH_8|c|Q)5`=
z`PZlZ3h({zhWD(nD+I1Gk_oCFv32M>8JP1U!m)o+7y^SJTC>SO6eKO+6&X0JhKQD&
zdB|l73s3LRw)?QkMl#76Dv>y`mfhbejea|6oY@`AcDCNwjC=eHL>F`cTNJoTCQ`c2GIF#6+7c)U5^iwXXgAc7)}m%!yP
zF;XCh{(9SvVYRv#@n%meX`AECUP;lh_uJp;%1|k`@FD02mR3I~=Tx*ZiI1R}qmO*W
zvqN;9n#V^zZu%w-J%hf8j75zX8q+y9dv6$RCO}^m>|_sxF6?xYfrw8;a1zYEnNPhGkcIdeL
z6l{GS;fvT2-90)KI{RyfUPJ#;f1u-{Q)B>a8MzZl(5=cRg_5H#3ul?)sq0}sj`BQSYH
zuzQop*%q(uOs{R!jQXE-pXKr1IYgIbA9U5$i3~J5gKd$?WB`*#f=okjJZq?(O=ty_
z5KrV=*4l8_+9b^UL7Y%*5!wa0D^rm}VtPvk@Es5w`x+Sl8#WL?QIA-HqR!dYCj$x4
zOre&Mhb<%M)RjN>|4+pI(=g@W5l<0~HlNTly`

[PATCH] Added documentation for rtems-tester in rtems-docs

2017-05-30 Thread Tanu Hari Dixit

Contains the ReST file for documentation for rtems-tester.
Also contains the new format for the ini configuration files.
---
 user/tools/rtems-tester.rst | 639 
 1 file changed, 639 insertions(+)
 create mode 100644 user/tools/rtems-tester.rst

diff --git a/user/tools/rtems-tester.rst b/user/tools/rtems-tester.rst
new file mode 100644
index 000..24c62dd
--- /dev/null
+++ b/user/tools/rtems-tester.rst
@@ -0,0 +1,639 @@
+RTEMS Tester
+
+
+.. image:: ../../images/user/rtemswhitebg.jpg
+   :width: 400
+   :align: center
+   
+Chris Johns 
+1.0, June 2014
+
+RTEMS Tester
+
+
+The RTEMS Tester is a test framework. It includes a command line interface to
+run tests on supported targets. The framework provides back-end support for
+common simulators and debuggers. The board support package (BSP) configurations
+for RTEMS are provided and can be used to run all the tests provided with
+RTEMS. The framework is not specific to RTEMS and can be configured to run any
+suitable application.
+
+RTEMS is an embedded operating system and is cross-compiled on a range of host
+machines. The executables run on the target hardware and this can vary widely
+from open source simulators, commercial simulators, debuggers with simulators,
+to debuggers with hardware specific pods and devices. Testing RTEMS requires
+the cross-compiled test executable is transferred to the target hardware,
+executed and the output returned to the host where it is analyzed to determine
+the test result. The RTEMS Tester provides a framework to do this.
+
+Running all the RTEMS tests on your target is very important. It provides you
+with a traceable record showing that your RTEMS version and its tools are
+working at the level the RTEMS development team expect when releasing
+RTEMS. Being able to easily run the tests and verify the results is critical in
+maintaining a high standard.
+
+The RTEMS Tester contains:
+
+* Command line tool (``rtems-test``)
+* BSP Configuration scripts
+* Back-end Configuration scripts
+* Back-end Python classes
+* Python based framework
+
+This document is for users of the RTEMS Tester as well as those wanting to
+develop, extend and investigate the RTEMS Tester.
+
+License
+===
+
+The RTEMS Tester is part of the RTEMS Tools Project. The code is released under
+the OSI approved "The BSD 2-Clause License". It is free to use and we encourage
+this, including on operating systems other than RTEMS.
+
+The code and command line tools must retain the same names and always reference
+the RTEMS Tools Project.
+
+Quick Start
+===
+
+The quick start will show you how to run the test suite for a BSP. It will
+explain how to get the RTEMS Tester, set it up and run the tests for the erc32
+BSP. It assumes you have a valid SPARC tool chain and have built the erc32 BSP
+version of RTEMS 4.12.
+
+Setup
+=
+
+Set up a development work space:
+
+.. code-block:: shell
+
+$ cd
+$ mkdir -p development/rtems/test
+$ cd development/rtems/test
+
+First fetch the RTEMS tester from the RTEMS Tools repository:
+
+.. code-block:: shell
+
+$ git clone git://git.rtems.org/rtems-tools.git rtems-tools.git
+$ cd rtems-tools.git/tester
+
+Available BSP testers
+=
+
+You can list the available BSP testers with:
+
+.. code-block:: shell
+
+$ ./rtems-test --list-bsps
+arm920
+beagleboardxm
+jmr3904-run
+jmr3904
+mcf5235
+psim-run
+psim
+realview_pbx_a9_qemu
+sis-run
+sis
+xilinx_zynq_a9_qemu
+xilinx_zynq_a9_qemu_smp
+xilinx_zynq_zc706
+xilinx_zynq_zc706_qemu
+
+.. note:: The list is growing all the time and if your BSP is not supported we 
+  encourage you to add it and submit the configuration back to the 
project.
+
+Some of the BSPs may appear more than once in the list. These are aliased BSP
+configurations that may use a different back-end. An example is the SPARC
+Instruction Simulator (SIS) BSP. There is the 'sis' tester which uses the GDB
+back-end and the 'sis-run' tester which uses the command line version of the 
SIS
+simulator. We will show how to use ``rtems-test`` command with the SIS BSP
+because it is easy to build an use.
+
+Adding support for a BSP to the tester
+==
+
+To add support for a BSP, one should add a configuration file in 
+``rtems-tools.git/tester/rtems/testing/bsps``. The configuration files 
+should be specified in an INI file. The configuration files provide a 
+means to the backend of `rtems-tester` to automate the running of tests.
+There is the  tester which uses the GDB back-end and the 
``-run`` 
+tester which uses the command line version of the respective simulator.
+The general format for specifying an INI configuration file is as follows:
+
+.ini:
+
+.. code-block:: shell
+
+[]
+bsp = ''
+gdb = '%{_rtscripts}/gdb.cfg'
+arch = ''
+
+[gdb_script]
+gdb_script ='_g

[PATCH] Added documentation for rtems-tester in rtems-docs

2017-05-30 Thread Tanu Hari Dixit

This documentation is in ReST and has been ported
from rtems-tools.git. There are a few changes and
it contains the format for the ini configuration
files.
---
 images/user/rtemswhitebg.jpg | Bin 0 -> 117890 bytes
 user/tools/rtems-tester.rst  | 639 +++
 2 files changed, 639 insertions(+)
 create mode 100644 images/user/rtemswhitebg.jpg
 create mode 100644 user/tools/rtems-tester.rst

diff --git a/images/user/rtemswhitebg.jpg b/images/user/rtemswhitebg.jpg
new file mode 100644
index 
..f883f2c495d4d91ef94d35e28995b9d2b7a863f7
GIT binary patch
literal 117890
zcmeFZ2V4}%wm;tF43dMupyX^KNf;4HA|go?gi#OykqnY&35)?%QB?yQx3J6FV
za!_C-tHdE^7~%jEevP|#ckk}Ld+&Sy_ul8e&wtxb569}N?mDMVo%){Br<(kgJO&&%
zt7oVOP*6|+2H-z{JkET{P)7%L!OTR@@SHAq0RWf{&bhdIP#ypPH+NreGyT&dmo8h2
z&~*Zo00Te^90h=D4nCg7=6V(Yco^#Hi1>h&_UWGw@E%+J0Qd_4J@N(@L_~fr|5yL8
zJ9v8g0szGYu)*=`jy?_`9R||3{Cz$5%U3~~%ieXLrlj7dy}=HGG~Yh$^b;-jqs~wC
zseSsooBMUJ&VHXgue)8}ryD`~!EHZBkfu5Z(h;{^9Q{GM7o^2*`MJ4(G#;e6+#Ij@
z001@fez~usgEL4U0cmD$3o{*%)&Kx{W~blK_P?Qh9Rt9A0)UQ(XP~!>le4dgl!LU$
zQ8hJH5d%m6TaLcI@)xc-xL)(VE~4Y%=6TIM5CDGSdA}9Fu`gQ@P{_(h)s&Uxk12rS
z|K<3H7k{bskBR-U{i(*f>5nm^;A#K0?ANxxmU(0Vfa)eFn@7Kv**^n-vTy+4`~GX0
z*h>Il3j=^s%y0PN+1D3mUtiCYii-aJ{t7OR4hs7M{pI+l6@IDt9}~ZMp2Gg~evzHX
z8OIyf{BHS*>yv0K)}PEwuyGoJ;`Kl{D}Q
z#V_M_j^QG(Kl7|0Ge7A)NQ2jZ{Qlh!B@+BErH_k~$bPYonT3dhpZD#38k`gRKQsU%
zzy@#u{D3eZ3P=I+z%f7tPzO!{y1-e$1h4=u19pG|;0(9{-he+40^9{6fEeHr@EAw|
z(t#`>4=4nRfHI&8r~{gT&%hU;4;Tc-fGJ=BSOvC#JOQt(qiD8wmbDUMO7
zQfN`=QkCJRETycY{7l(LIYzla
zxk&|3F;VeQ9ioz_Ql-+NGNH1jx!RY+Aq)k4)nHAb~awL?uy%}Fgn
zEl;gZZ9r{F?Lh5C4X2K!PNB}FE~Rdy?xDs~uTqm}SZD-kWNA*)7}8v#aia03iJ*Bx
z^P1)ZO%qKY%@oZREiEk%tt71qtpV+2+MBe&w6U}=Xi>Dav|Y3lw3~Evbo_L(beeP~
zbl2#7=_2T!(Y>WZ({D}q?(LbSoLtjJRO+Q1w$8dl_oZ%#c
z3Bz@UKn5g37DELChGB|fkCB~Gl2MbL#rTM*k5wqiC6+u{L+0}=;x4qQ6`Kk)p(#{&Zg
zHrYAZkFuMvyRpZzzhQ4A-oPGmEo{bBc?W
zOOnfw>n2wWR{>Wi*D5y$_X+Nc+yUIrxvROyc&K;u5GX>iPH-&_S^o2Zyo(VMwEei7ppAx<)oFrT$JO|-~XhB>c
zNf0z-UW8jjTjZ9=Q;|lI)kA`Z3=a7ndUdGt(B5Im!bP~FF7Q|A_bN5lFE?k
zm8O+em3EbWA^k;$QbtL}S?0M6MwU`mS=L4Ng>07`jhvdCyIh9cfIPFjw)}1Re0i(_
zkHR^HdkSR=%Zg%(){60pEsCTgN=I%T$vQH4l;h~xqxX(h99=smbIjq`^JBfoS&r)+
zM;tFdjyoZH!tq4fiLXkWO2$f&O7%)aWff&_h-A^ZE5YB+HbX&Paiq$efq=cZJm=kp*po^sLtr0i9XY*%b{zjo1#0S
zcUaF!FJEs}Ur9e$zt(`pz{nupV8Bqw(7`azaP_Rp+0e6%M$AU$Mkz+)=VZ=#pQ|vY
zG(KybXgqXY{Ji`5G84eW&?M1h_=4mGuM3r?w5AtKpPNpb9W@IvYcc0Ehnc@I-?BJu
zfwUO3l(O`*tiQ;1@yf-#i`!ObtP-roE-79Lz4ZCAz-5=q<<@l87p-4gZ`$bEJhqv-
zqI4zVO24h7ZGdf?oq*jfyJ{F4>>8~2D$P}^t8cCnu9;lRxVC9;XrF4o>Y(G0?67eC
z)b*t6bB>yh363*2G;bu_n03;0N_3iYhB`lSUUboMNpZp5G`N|5bKBL#HOG~F%jy=&
zjo$65+edc}cUSjD4`Gi0k1kJH&j`;kuajPny;i-AykGlJ_}KcC`*ML`s@+e@FWe7%
zTkH1o+j#$r{>1_80qz0qfii(nfippRLD|97!4ARoA%{ZlhG0XrLtnuu;P&u(geW2m
zF?C1(PVQaCyRLUT?j5<8aBt(j)%}Vvp|Cq)6XE*d`4OxU-VpXGRWs2{jI=!`lZ
z^(=}MeLeb9%#oNUF@#u$*iR3SK79I+9CstG6RC_$dqn%l{ZW5BG(I~Y(Z6Hn5U8I%2z$DW>hTK-Jz*`sHK6z7z_=ck{eQUz0^Qnz1Rf6<+G
zDy=YGC_N^9_od6rudno9m1am}JjtZZyq!6nbup_YTQxiHwZQ9`*Tfw6oUvT9+{QeW
zyu3GpZ;<(v`F{CxZ?C-lQgEiAyimUI6^aKH^A33D_iq0E)%X2HMn(0-s>OvR;w7mc
zI6p*}Qj`Xku9i8Mjg?<6@A`Q5V||5s#fM6T%ABf0RnM!rtC2N~HDNVmbP#&8*0Xl8
z&Z%yq9#%itaH*lU(X_F%$*8HdS+BXFMY{#vs@YoAcCzi`C)H17pOrtCwkx%N=uqnT
z(5c*6ic!Ioe^L8V(WTK<(+%ye>p9cY+-unTx$k^mSHETd*MTboV_&a-o&9#}8}9q<
z?|XxHhG>SOhYt)t84(=G7?mDHjVX^+W6xmQ$IZtFCmbdgCVeIeQ(@CA(@$m~GkLSe
zW~=7(=Dy6^%ug+NF6=EvEU_=8E=w(!tejeDU%j+Ch4aRd*J9WC*K;;bY}9XF*c{n%
z+uGZX#`EKIcT{&;cCB`2_WTKSgr`JlVg<>FG(>hIlgU`1S2w`r1^^fv12P~Qpaxm@rIML%S|6&zuW!+fkF4f
z!XqLdL`5egCOv+V{PbB$MrKy_>zv%YH$}xIA4<#0KUUN?G&VK2w6=Zf?&w>@Gdm>G)Ug>lj3jo2_!&dv`JNh@HTS&S(n9)`e><_lz*N7{xV20
zq)ke-P{319N1P~ZaycDmY#BWKY)r}gW4Wc7&-afuL{o>T2ku7~E?K_S-YkUlqgRYgS#6n);Oc*ZOJx$uVxVetXN<42KWf_{a2jlAL_i09mED{&ug
zL`$Osf;Uhv+TXL%6Yt+!Q;N#x>cZfW&EpJ^?Q%k})l*{}H_u#>$!M=tEPkPhqe-sv
zx?~zU3Pn+gOI^r?j41mDTg_Y=!Zin{e|z*V11F@gkqNzGVKUHj%PD%8XAv
z&pFekwYlSlHQ_zC-Suc@9aW@3fjU7tKP|HBG-vnP{P`!hn<0u1w1my;wM&pSCyezw
z42p(bzbxHgzMr-^2IsDJ5kbm-@kcrL2$mQaVhZ5l_uot+C(;go?h|-;Y5vP{UFS{f
z0`{GNe9inG{U*c9;asNLhjh6vQ2cfN+sc4i0dd=vV}s-2M!~?9ytmIwT1CGXJsSwS
z9Y1L&ZswLg2NMa=O_2(jok~%ilzmii_V->dK*{dHLj)j-h_Kaj(>g6TY3QZEY>wc#dvL&R&@t~$}?=_{o
zyy1A&nVT1HJL%HbrxcyEV5lX?cy(8Yzuy@e{#s(Hd+aaF@b8VAXg`=gI~F#PYB@w@
z`tB3N`k6da*kY%OS&1V1M5@)e6M>6%baAxQBhn(4XVtF~F*!9$dc2pXp$ua6EE5b0;0>(&fg#BII(ZJJeEf6Xnk)7?4KVj~2cyY_njMIqS^F
zH9xB#$7QMu{B{1D%it+j$pz|j(ZN>OZ30*JY0|JT7vMmWGJ+8m(5Rs+RItd=RkIPO
zJDPzEe2oMRV)no$?n($6E54h#KFTFd2I$RTBT+jOx?EP+$aMp&f)Hwc;ztrw-fT!<
z<_sC2dW8~4S>tKQfMnmQ4XLFALI#Xp6;{#hbwF{79YWt6$iS^^k`&3A^!)MBC399i
z6N$$`W&<1J(4xU|(CcmdONai=b?E1L&W#TSjgmYWNL*M=CqB51-nB)*$}Rt_l(%Jc
zO&T$-Ka(bfXpMu7|Exbw>lZ-%p#twPhX?QDFcJ^y+n0fafj=p`BKC+HkgV$xqq^M6BW_Q&b}tm5#$PQ=irOy2KNx;%At)Hh99`HKCw
z>+fkFl3o{g)IsV;A0N3g^^s-AwB2QqKNlj}pUQgko>94HR$sV1BJ9hH_8|c|Q)5`=
z`PZlZ3h({zhWD(nD+I1Gk_oCFv32M>8JP1U!m)o+7y^SJTC>SO6eKO+6&X0JhKQD&
zdB|l73s3LRw)?QkMl#76Dv>y`mfhbejea|6oY@`AcDCNwjC=eHL>F`cTNJoTCQ`c2GIF#6+7c)U5^iwXXgAc7)}m%!yP
zF;XCh{(9SvVYRv#@n%meX`AECUP;lh_uJp;%1|k`@FD02mR3I~=Tx*ZiI1R}qmO*W
zvqN;9n#V^zZu%w-J%hf8j75zX8q+y9dv6$RCO}^m>|

[PATCH] Fixes typos in README.txt

2017-05-29 Thread Tanu Hari Dixit

From: tokencolour 

2 typos fixed
---
 README.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.txt b/README.txt
index f09317e..c1b7e6f 100644
--- a/README.txt
+++ b/README.txt
@@ -316,7 +316,7 @@ existing documentation for an example and if unsure ask.
   Heading   Description
   1  ## Part
   2  ** Section
-  3  == Sub-ection
+  3  == Sub-section
   4  -- Sub-sub-section
   5  ^^ Sub-sub-sub-section
   6  ~~ Sub-sub-sub-sub-section
@@ -392,7 +392,7 @@ existing documentation for an example and if unsure ask.
  users: Users Mailing List
  vc   : Version Control Mailing List
 
-  The valif URLs are:
+  The valid URLs are:
 
  trac : https://devel.rtems.org/
  devel: https://devel.rtems.org/
-- 
2.1.4

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

gem5 with ARM

2017-05-22 Thread Tanu Hari Dixit

n the simulator for sparc64/usiii and
arm/realview_pbx_a9_qemu BSPs and eventually automate it with
rtems-tester (as part of GSoC, '17).

Thank you,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Tanu Hari Dixit

Hello Joel,

I git grepped for the above lines in src/rtems but couldn't find it. I
couldn't find it in
/src/rtems/cpukit/posix/include/rtems/posix/pthread.h. I don't know
how to define _GNU_SOURCE. Can you please help me with this?

Thank you,
Tanu Hari Dixit.

On Wed, Apr 19, 2017 at 9:38 PM, Joel Sherrill  wrote:
> Hi,
>
> This is prototyped in pthread.h in the current tools:
>
>  #if __GNU_VISIBLE
> int pthread_getname_np(pthread_t, char *, size_t) __nonnull(2);
>
> int pthread_setname_np(pthread_t, const char *) __nonnull(2);
> #endif
>
> Do you have current tools? Did you define _GNU_SOURCE so this
> prototype is visible?
>
> --joel
>
>
> Are you sure your to
>
> On Wed, Apr 19, 2017 at 10:00 AM, tokencolour  wrote:
>>
>> Gets rid of 1 warning -->
>> warning: no previous prototype for 'pthread_getname_np'
>> [-Wmissing-prototypes]
>> ---
>>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> index 90a60b6..51a1a2a 100644
>> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
>> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>>const pthread_attr_t *attr2
>>  );
>>
>> +/*
>> + * pthread_getname_np
>> + */
>> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
>> +
>>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>>  {
>>_Objects_Allocator_lock();
>> diff --git a/cpukit/posix/src/pthreadgetnamenp.c
>> b/cpukit/posix/src/pthreadgetnamenp.c
>> index e753823..b1a99f0 100644
>> --- a/cpukit/posix/src/pthreadgetnamenp.c
>> +++ b/cpukit/posix/src/pthreadgetnamenp.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>
>>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>>  {
>> --
>> 2.1.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added declaration of method pthread_getname_np

2017-04-19 Thread Tanu Hari Dixit

Hello all,

Please let me know if this is okay.

Thanks,
Tanu Hari Dixit.

On Wed, Apr 19, 2017 at 8:30 PM, tokencolour  wrote:
> Gets rid of 1 warning -->
> warning: no previous prototype for 'pthread_getname_np' [-Wmissing-prototypes]
> ---
>  cpukit/posix/include/rtems/posix/pthreadimpl.h | 5 +
>  cpukit/posix/src/pthreadgetnamenp.c| 1 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/cpukit/posix/include/rtems/posix/pthreadimpl.h 
> b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> index 90a60b6..51a1a2a 100644
> --- a/cpukit/posix/include/rtems/posix/pthreadimpl.h
> +++ b/cpukit/posix/include/rtems/posix/pthreadimpl.h
> @@ -111,6 +111,11 @@ int rtems_pthread_attribute_compare(
>const pthread_attr_t *attr2
>  );
>
> +/*
> + * pthread_getname_np
> + */
> +int pthread_getname_np( pthread_t thread, char *name, size_t len );
> +
>  RTEMS_INLINE_ROUTINE Thread_Control *_POSIX_Threads_Allocate(void)
>  {
>_Objects_Allocator_lock();
> diff --git a/cpukit/posix/src/pthreadgetnamenp.c 
> b/cpukit/posix/src/pthreadgetnamenp.c
> index e753823..b1a99f0 100644
> --- a/cpukit/posix/src/pthreadgetnamenp.c
> +++ b/cpukit/posix/src/pthreadgetnamenp.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  int pthread_getname_np( pthread_t thread, char *name, size_t len )
>  {
> --
> 2.1.4
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] RTEMS Tester Improvements

2017-04-03 Thread Tanu Hari Dixit

Thank you for the reply, Joel. I have edited my proposal to include
gem5 as of now. If time will permit, I will look into Skyeye.

Thanks,
Tanu Hari Dixit.

On Sat, Apr 1, 2017 at 8:13 PM, Joel Sherrill  wrote:
>
>
> On Apr 1, 2017 8:12 AM, "Tanu Hari Dixit"  wrote:
>
> Hello Chris, All,
>
> I have added PyYAML as the tool I'll be using to parse the yml files
> in my proposal. Thank you for clearing that. Can you please look at
> the proposal and give comments on the methods I have proposed to solve
> the various problems? (In particular the "Proposed Schedule" section).
>
> I had questions regarding the simulator recipes that need to be
> supported in rtems-tester and I would be grateful if they are
> answered.
>
> The listed bsps are those that are supported by sim-scripts and not
> rtems-tester:
>
> Blackfin/bf537Stamp support on skyeye
> ARM/CSB337 support on skyeye
> MIPS/CSB350 support on skyeye
> M68K-Coldfire/CSB360
> ARM/EDB7312 support on skyeye
> Blackfin/ezkit533 support on skyeye
> ARM/Gumstix support on skyeye
> SPARC/LEON2 support on skyeye
> ARM/RTL22xx support on skyeye
> ARM/SMDK2410 support on skyeye
> arm/lm3s6965 support on qemu
> i386/pc386 support on qemu
> ARM/GumStix Connex support on qemu
> SPARC/LEON2 support on qemu
> lm32/lm32_evr support on qemu
> OpenRISC/or1k support on or1ksim
> PowerPC/QemuPPC support on qemu
> arm/realview_pbx_a9_qemu_smp support on qemu
> m68k/uc5282 support on qemu
>
>
> I see a bf537Stamp-skyeye.in in sim-scripts but I don't see it listed
> in https://devel.rtems.org/wiki/Developer/Simulators/SkyEye. Also
> couldn't find ARM/Gumstix and ARM/SMDK2410 listed there. Are these
> configurations supported? Should I be adding support for these?
>
>
> Skyeye is a sad project to me. They had a lot of functionality and ran a
> number of RTEMS BSPs. Then they undertook an overly ambitious rearchitecting
> and seem to have killed the project.
>
> It might be worth checking the status of skyeye to see if it improved but I
> wouldn't put it anywhere near your critical path or put a lot of time in it.
> It may be that RTEMS needs to make a decision that we use old releases or
> simply abandon it if the current source is broken and the project inactive.
>
>
>
>
> It is given on the same web-page that arm/csb337 will run hello.exe
> and ticker.exe on Skyeye. Would it be worth adding support for this
> bsp if they can run a few tests only?
> It is written that RTEMS BSP Csb350 should work once support in Skyeye
> comes further along. What does this indicate?
>
>
> That we we're hopeful. :(
>
>
> Are these the simulator recipes that the devs wanted to see in
> rtems-tester (other than for running RTEMS on gem5  for sparc64/usiii
> and arm/realview_pbx_a9_qemu BSPs) ? Should I be focusing on a few
> relevant ones? If so, which ones are more important?
>
>
> The uc5282 had working networking at one point. In general ai would say
> assess and don't waste time doing more than that on any specific BSPs. Focus
> on the ones that work to improve the overall capabilities. If we know which
> BSPs need work, we can nibble at known BSP specific issues.
>
> I hope this helps. It would be better to have high rtems-tester
> functionality on a few BSPs than to get hung up on BSP specific issues. We
> just need them recorded with tickets.
>
>
> Thank you,
> Tanu Hari Dixit.
>
> On Mon, Mar 27, 2017 at 6:37 AM, Chris Johns  wrote:
>> On 27/03/2017 04:34, Tanu Hari Dixit wrote:
>>>
>>> Also, do you suggest against using PyYAML to parse .yml configuration
>>> files (since that will add a dependency into rtems-tester)?
>>
>>
>> PyYAML might be perfect for the task. We will need to find a suitable
>> solution as part of the change to Yaml. The YAML support maybe added to
>> the
>> rtemstoolkit.
>>
>> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2017 -- initial proof

2017-04-02 Thread Tanu Hari Dixit

Thanks Joel for the correction.

Regards,
Tanu Hari Dixit.

On Sun, Apr 2, 2017 at 11:23 PM, Joel Sherrill  wrote:
>
>
> On Sun, Apr 2, 2017 at 12:33 PM, Tanu Hari Dixit 
> wrote:
>>
>> Hi Andy,
>>
>> Joel and Gedare pointed me to the following:
>>
>>
>> https://devel.rtems.org/wiki/Developer/Projects/Open/PythonCoverageReporting
>> https://devel.rtems.org/ticket/2261
>> http://kmiesowicz.blogspot.in/p/esa-socis-2014.html
>>
>> Last link is to the work done by a previous student.
>> Hope this helps.
>> My proposal does not take covoar into consideration. Though, I have
>> planned to produce xml reports from rtems-tester that can be
>> integrated into coverage testing. Also, I have planned to use this xml
>> data to get plots (for visualizing results) as a stretch goal (you can
>> look in the "Future Improvements" Section in my proposal).
>
>
> covoar directly produces the html and text reports we have now. My
> recollection is that it doesn't have to be touched and that the trick
> is invoking it on a more focused basis than Core vs Developmental.
> So invoke covoar from rtems-tester mulitple times on a single run
> of the tests rather than twice at most.
>
> Personally, I think Core is still a good description for the core of
> the tasking (e.g. score, rtems, sapi, and posix) and that each
> directory other than that should be individual. But that's my marketing
> view. I could easily be argued that for consistency, it should all
> be on a per directory basis.
>
> At some point, we might discuss covoar writing a neutral format
> and using Python to do more but that is pure conjecture. I have
> no idea what the intermediate format would be. Writing Sphinx
> output for reports would be desirable from covoar. :)
>
> --joel
>
>>
>>
>> Regards,
>> Tanu Hari Dixit.
>>
>> On Sun, Apr 2, 2017 at 6:50 PM, Gedare Bloom  wrote:
>> > Joel's e-mail client messed up my reply thread. ;) Andy, have a read
>> > through https://gedare.github.io/pdf/FelShe15A.pdf if you haven't
>> > found it already.
>> >
>> > Getting qemu-couverture to build via RSB and then integrating the
>> > coverage scripts into rtems-test, would be a good start to a project.
>> > There is a student (Tanu)oar dir who has proposed rtems-test
>> > improvements, so
>>
>> > you two would need to coordinate efforts for this piece to avoid too
>> > much duplicated work/waste. Improvements to the reports etc are also
>> > welcome, and then of course using the reports to guide code
>> > refactoring to improve coverage is somewhat open-ended.
>> >
>> > -Gedare
>> >
>> > On Sat, Apr 1, 2017 at 9:34 PM, Joel Sherrill  wrote:
>> >>
>> >>
>> >> On Apr 1, 2017 7:59 PM, "Andy MacGregor" 
>> >> wrote:
>> >>
>> >> On 03/31/2017 09:52 PM, Gedare Bloom wrote:
>> >>
>> >> Don't forget the deadline is Monday to submit your Final
>> >> PDF and proof of enrollment. The "Final" PDF can be submitted multiple
>> >> times, so go ahead and submit it when you finish a first draft. Add
>> >> your draft proposal to the tracking table at
>> >> https://devel.rtems.org/wiki/GSoC/2017 also, to get some possible
>> >> feedback.
>> >>
>> >>
>> >> Thanks for the welcome! (I realize I am late to the GSOC application
>> >> table).
>> >>
>> >> I'm set on improving code coverage of the testsuite, but I found some
>> >> questions as I'm starting to look into how its done.
>> >>
>> >> The link on the wiki to the current code status is currently broken, so
>> >> I
>> >> tried to generate a sample coverage report for 4.12 using
>> >> ./do_coverage,
>> >> ./run_coverage and ./coverage_cron as suggested on the wiki here but
>> >> without
>> >> any luck. Is there an up to date coverage report available?
>> >> I modified the VERSIONS-COVERAGE file like the wiki said, and once that
>> >> didn't work dug around in the script but fix it myself quickly.
>> >>
>> >> Could updating these coverage analysis scripts be a viable component of
>> >> a
>> >> GSOC proposal?
>> >>
>> >>
>> >> Yes. In fact, the idea was to rework the coverage scripts in shell to
>> >> be
>> >> part of the rtems-tester package and in Python. There i

Re: GSoC 2017 -- initial proof

2017-04-02 Thread Tanu Hari Dixit

Hi Andy,

Joel and Gedare pointed me to the following:

https://devel.rtems.org/wiki/Developer/Projects/Open/PythonCoverageReporting
https://devel.rtems.org/ticket/2261
http://kmiesowicz.blogspot.in/p/esa-socis-2014.html

Last link is to the work done by a previous student.
Hope this helps.
My proposal does not take covoar into consideration. Though, I have
planned to produce xml reports from rtems-tester that can be
integrated into coverage testing. Also, I have planned to use this xml
data to get plots (for visualizing results) as a stretch goal (you can
look in the "Future Improvements" Section in my proposal).

Regards,
Tanu Hari Dixit.

On Sun, Apr 2, 2017 at 6:50 PM, Gedare Bloom  wrote:
> Joel's e-mail client messed up my reply thread. ;) Andy, have a read
> through https://gedare.github.io/pdf/FelShe15A.pdf if you haven't
> found it already.
>
> Getting qemu-couverture to build via RSB and then integrating the
> coverage scripts into rtems-test, would be a good start to a project.
> There is a student (Tanu) who has proposed rtems-test improvements, so
> you two would need to coordinate efforts for this piece to avoid too
> much duplicated work/waste. Improvements to the reports etc are also
> welcome, and then of course using the reports to guide code
> refactoring to improve coverage is somewhat open-ended.
>
> -Gedare
>
> On Sat, Apr 1, 2017 at 9:34 PM, Joel Sherrill  wrote:
>>
>>
>> On Apr 1, 2017 7:59 PM, "Andy MacGregor" 
>> wrote:
>>
>> On 03/31/2017 09:52 PM, Gedare Bloom wrote:
>>
>> Don't forget the deadline is Monday to submit your Final
>> PDF and proof of enrollment. The "Final" PDF can be submitted multiple
>> times, so go ahead and submit it when you finish a first draft. Add
>> your draft proposal to the tracking table at
>> https://devel.rtems.org/wiki/GSoC/2017 also, to get some possible
>> feedback.
>>
>>
>> Thanks for the welcome! (I realize I am late to the GSOC application table).
>>
>> I'm set on improving code coverage of the testsuite, but I found some
>> questions as I'm starting to look into how its done.
>>
>> The link on the wiki to the current code status is currently broken, so I
>> tried to generate a sample coverage report for 4.12 using ./do_coverage,
>> ./run_coverage and ./coverage_cron as suggested on the wiki here but without
>> any luck. Is there an up to date coverage report available?
>> I modified the VERSIONS-COVERAGE file like the wiki said, and once that
>> didn't work dug around in the script but fix it myself quickly.
>>
>> Could updating these coverage analysis scripts be a viable component of a
>> GSOC proposal?
>>
>>
>> Yes. In fact, the idea was to rework the coverage scripts in shell to be
>> part of the rtems-tester package and in Python. There is some work on this
>> by a previous student which you can find or one of us can dig out. Starting
>> with it, making it work across multiple BSPs, independent of any hard coded
>> paths, improving the output (we did not get far enough that I recall
>> worrying about the quality of the output), etc could be a fair amount of
>> work.
>>
>> Also we have privately discussed switching the RSB qemu upstream source to
>> GNATCoverage at GitHub. This is a coverage and embedded focused downstream
>> which includes the coverage trace output I used for the qemu support in
>> covoar. I'm
>>
>> In addition, I'd like to actually make some improvements the code coverage
>> itself.
>> The most recent information I could find was these bar graphs from 2009.
>> If these graphs reflect the current coverage state, I think that improving
>> coverage for the i386/pc386,
>> would be interesting because there is room for improvement in both the
>> Baseline and Developmental groups (if these coverage statistics are up to
>> date).
>>
>>
>> It doesn't matter which BSP you choose for coverage since the code and tests
>> are the same.
>>
>> This also reminds me of the other improvements we had wanted. We wanted to
>> switch from Baseline and developmental to a more directory oriented approach
>> for the reports. For example, the reports should be at a granularity of say
>> the Dos file system or shell as reports. The way reports are generated now
>> it results in a skewed view when a large body of code is added to the
>> developmental set. Adding the Dos filesystem resulted in a 15-20% drop in
>> the coverage reported in the Developmental set. That is a

Re: [GSoC] RTEMS Tester Improvements

2017-04-01 Thread Tanu Hari Dixit

Hello Chris, All,

I have added PyYAML as the tool I'll be using to parse the yml files
in my proposal. Thank you for clearing that. Can you please look at
the proposal and give comments on the methods I have proposed to solve
the various problems? (In particular the "Proposed Schedule" section).

I had questions regarding the simulator recipes that need to be
supported in rtems-tester and I would be grateful if they are
answered.

The listed bsps are those that are supported by sim-scripts and not
rtems-tester:

Blackfin/bf537Stamp support on skyeye
ARM/CSB337 support on skyeye
MIPS/CSB350 support on skyeye
M68K-Coldfire/CSB360
ARM/EDB7312 support on skyeye
Blackfin/ezkit533 support on skyeye
ARM/Gumstix support on skyeye
SPARC/LEON2 support on skyeye
ARM/RTL22xx support on skyeye
ARM/SMDK2410 support on skyeye
arm/lm3s6965 support on qemu
i386/pc386 support on qemu
ARM/GumStix Connex support on qemu
SPARC/LEON2 support on qemu
lm32/lm32_evr support on qemu
OpenRISC/or1k support on or1ksim
PowerPC/QemuPPC support on qemu
arm/realview_pbx_a9_qemu_smp support on qemu
m68k/uc5282 support on qemu

I see a bf537Stamp-skyeye.in in sim-scripts but I don't see it listed
in https://devel.rtems.org/wiki/Developer/Simulators/SkyEye. Also
couldn't find ARM/Gumstix and ARM/SMDK2410 listed there. Are these
configurations supported? Should I be adding support for these?

It is given on the same web-page that arm/csb337 will run hello.exe
and ticker.exe on Skyeye. Would it be worth adding support for this
bsp if they can run a few tests only?
It is written that RTEMS BSP Csb350 should work once support in Skyeye
comes further along. What does this indicate?

Are these the simulator recipes that the devs wanted to see in
rtems-tester (other than for running RTEMS on gem5  for sparc64/usiii
and arm/realview_pbx_a9_qemu BSPs) ? Should I be focusing on a few
relevant ones? If so, which ones are more important?

Thank you,
Tanu Hari Dixit.

On Mon, Mar 27, 2017 at 6:37 AM, Chris Johns  wrote:
> On 27/03/2017 04:34, Tanu Hari Dixit wrote:
>>
>> Also, do you suggest against using PyYAML to parse .yml configuration
>> files (since that will add a dependency into rtems-tester)?
>
>
> PyYAML might be perfect for the task. We will need to find a suitable
> solution as part of the change to Yaml. The YAML support maybe added to the
> rtemstoolkit.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] RTEMS Tester Improvements

2017-03-26 Thread Tanu Hari Dixit

Thank you, Gedare, for the comments.

Regards,
Tanu Hari Dixit.

On Sun, Mar 26, 2017 at 11:04 PM, Tanu Hari Dixit  wrote:
> Hello Chris, all,
>
> Thank you for the explanatory answers.
>
> I have updated my proposal as linked in the GSoC
> wiki(https://devel.rtems.org/wiki/GSoC/2017). I'll be grateful if you
> and the community members can view it and provide your valuable
> feedback.
>
> The portion where adding simulator support is discussed might look a
> bit under-researched. I am working on it. Also, I am bit confused
> whether to add coverity issues into the proposal. I still have to look
> into it. Furthermore,  I would like to know if the work mentioned in
> the proposal is enough work for the summer.
>
> Also, do you suggest against using PyYAML to parse .yml configuration
> files (since that will add a dependency into rtems-tester)?
>
> Thank you,
> Tanu Hari Dixit.
>
> On Wed, Mar 22, 2017 at 10:54 AM, Chris Johns  wrote:
>> On 22/03/2017 03:46, Tanu Hari Dixit wrote:
>>>
>>> Thank you so much Chris for the elaborate answers.  I have a clearer
>>> idea of the project now. Thank you Gedare for the tip, it definitely
>>> comes in handy.
>>> I'm sorry for the late reply. I have more questions and I will be
>>> grateful if the devs can help me with these.
>>
>>
>> Just to clarify something, the YAML change is for the .mc files and not the
>> .cfg files. The configuration is to stay as is using the config module in
>> the toolkit.
>>
>>> How does one use the console?
>>
>>
>> The console refers to the RTEMS console output and the tester needs to
>> support the various ways we can access a console. We currently have stdio
>> (stdout/stdin) and termios on Unix. The task is to allow more consoles and
>> to have Windows supported.
>>
>>> I see extensive use of termios in
>>> rtems-tools.git/tester/rt/stty.py which is in turn used in
>>> tester/rt/console.py
>>
>>
>> The tty class is based on termios and this is the issue on Windows. I would
>> leave stty.py as is and add a new serial.py file and class which is based on
>> PySerial. The console module is the collection of all console interface
>> methods the tester supports. You can see the stdio and tty classes, they are
>> a kind of console class. Serial would added as a kinbd of console as well.
>> The base console class defines the interface.
>>
>>> Can you please demonstrate one example so that I
>>> get an idea?
>>
>>
>> The stdio and tty. The configuration file parser ends up here on a
>> `%console` directive (see console.cfg):
>>
>> https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n87
>>
>>> I believe PySerial will need to be configured in a
>>> similar way i.e. making objects of class tty and assigning them
>>> attributes with Pyserial instead of termios (like ignbrk and the
>>> rest). Please correct me if I am wrong.
>>
>>
>> I have not looked at the detail. It would follow a similar pattern to tty
>> and tty_defaults:
>>
>> https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/console.cfg#n47
>>
>>> Moreover, about the telnet console, I went through the ser2net
>>> package. It serves as a good way to convert (or maybe the right word
>>> is "use") serial connections via telnet.
>>
>>
>> It is very useful.
>>
>>> I can make a simple bash
>>> script to install ser2net and then change its conf file to fix the
>>> appropriate port numbers and banners(which I can take as entry from
>>> user).
>>
>>
>> The set up and installation of ser2net is outside the scope of the work and
>> we should not step into that topic. There are too many hosts and
>> differences, for example I do not have bash installed.
>>
>>> Then I shall use them via telnetlib to communicate to the hosts
>>> and then I can run tests via the console on the target. Is this the
>>> right direction or should I be thinking differently?
>>
>>
>> Yes, telnetlib would be another console. We would wrap telnetlib in a module
>> and then add it to the console module.
>>
>>> Also I am really confused as to how rtemstoolkit comes into the
>>> picture. Can you please provide me with a rough workflow of the
>>> console?
>>
>>
>> The tool kit provides a common based of functionality that can be used
>> across a range of applications. The toolkit currently contains C++ and
>> Python code. Code in the rtem

Re: [GSoC] RTEMS Tester Improvements

2017-03-26 Thread Tanu Hari Dixit

Hello Chris, all,

Thank you for the explanatory answers.

I have updated my proposal as linked in the GSoC
wiki(https://devel.rtems.org/wiki/GSoC/2017). I'll be grateful if you
and the community members can view it and provide your valuable
feedback.

The portion where adding simulator support is discussed might look a
bit under-researched. I am working on it. Also, I am bit confused
whether to add coverity issues into the proposal. I still have to look
into it. Furthermore,  I would like to know if the work mentioned in
the proposal is enough work for the summer.

Also, do you suggest against using PyYAML to parse .yml configuration
files (since that will add a dependency into rtems-tester)?

Thank you,
Tanu Hari Dixit.

On Wed, Mar 22, 2017 at 10:54 AM, Chris Johns  wrote:
> On 22/03/2017 03:46, Tanu Hari Dixit wrote:
>>
>> Thank you so much Chris for the elaborate answers.  I have a clearer
>> idea of the project now. Thank you Gedare for the tip, it definitely
>> comes in handy.
>> I'm sorry for the late reply. I have more questions and I will be
>> grateful if the devs can help me with these.
>
>
> Just to clarify something, the YAML change is for the .mc files and not the
> .cfg files. The configuration is to stay as is using the config module in
> the toolkit.
>
>> How does one use the console?
>
>
> The console refers to the RTEMS console output and the tester needs to
> support the various ways we can access a console. We currently have stdio
> (stdout/stdin) and termios on Unix. The task is to allow more consoles and
> to have Windows supported.
>
>> I see extensive use of termios in
>> rtems-tools.git/tester/rt/stty.py which is in turn used in
>> tester/rt/console.py
>
>
> The tty class is based on termios and this is the issue on Windows. I would
> leave stty.py as is and add a new serial.py file and class which is based on
> PySerial. The console module is the collection of all console interface
> methods the tester supports. You can see the stdio and tty classes, they are
> a kind of console class. Serial would added as a kinbd of console as well.
> The base console class defines the interface.
>
>> Can you please demonstrate one example so that I
>> get an idea?
>
>
> The stdio and tty. The configuration file parser ends up here on a
> `%console` directive (see console.cfg):
>
> https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n87
>
>> I believe PySerial will need to be configured in a
>> similar way i.e. making objects of class tty and assigning them
>> attributes with Pyserial instead of termios (like ignbrk and the
>> rest). Please correct me if I am wrong.
>
>
> I have not looked at the detail. It would follow a similar pattern to tty
> and tty_defaults:
>
> https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/console.cfg#n47
>
>> Moreover, about the telnet console, I went through the ser2net
>> package. It serves as a good way to convert (or maybe the right word
>> is "use") serial connections via telnet.
>
>
> It is very useful.
>
>> I can make a simple bash
>> script to install ser2net and then change its conf file to fix the
>> appropriate port numbers and banners(which I can take as entry from
>> user).
>
>
> The set up and installation of ser2net is outside the scope of the work and
> we should not step into that topic. There are too many hosts and
> differences, for example I do not have bash installed.
>
>> Then I shall use them via telnetlib to communicate to the hosts
>> and then I can run tests via the console on the target. Is this the
>> right direction or should I be thinking differently?
>
>
> Yes, telnetlib would be another console. We would wrap telnetlib in a module
> and then add it to the console module.
>
>> Also I am really confused as to how rtemstoolkit comes into the
>> picture. Can you please provide me with a rough workflow of the
>> console?
>
>
> The tool kit provides a common based of functionality that can be used
> across a range of applications. The toolkit currently contains C++ and
> Python code. Code in the rtemstoolkit is not specific to any application,
> for example you could argue stty.py could be moved into the tool kit. We
> would do this later.
>
>> I also had questions regarding extending support for "expected-fail"
>> and "user-input" state as mentioned here
>> (https://devel.rtems.org/ticket/2946). What follows is my
>> understanding of what I need to do to extend support for
>> "user-input"(and "expected-fail"), please correct me if I am wrong.
>
>
> Expected fail is already

Re: Dates in the proposal templates

2017-03-22 Thread Tanu Hari Dixit

Hi Gedare,

Thank you for clarifying.

Regards,
Tanu Hari Dixit.

On Wed, Mar 22, 2017 at 8:59 PM, Gedare Bloom  wrote:
> You aren't missing anything. I believe this is already mentioned that
> you may need to adapt the template. Thanks.
>
> On Wed, Mar 22, 2017 at 11:22 AM, Tanu Hari Dixit  
> wrote:
>> Hello all,
>>
>> The dates in the "Proposed Schedule" section in the GSoC template
>> (https://devel.rtems.org/wiki/GSoC) are off by a few days, probably.
>> They are last year's dates, probably. There are three phases this time
>> as opposed to two halves for evaluation. Am I missing something? Can
>> somebody confirm?
>>
>> Thanks,
>> Tanu Hari Dixit.
>> ___
>> 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

Dates in the proposal templates

2017-03-22 Thread Tanu Hari Dixit

Hello all,

The dates in the "Proposed Schedule" section in the GSoC template
(https://devel.rtems.org/wiki/GSoC) are off by a few days, probably.
They are last year's dates, probably. There are three phases this time
as opposed to two halves for evaluation. Am I missing something? Can
somebody confirm?

Thanks,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: timeouts and failure

2017-03-21 Thread Tanu Hari Dixit

Hello Chris, All,

Regarding the ticket https://devel.rtems.org/ticket/2946
for the test spcontext01 do we need to add a tag in a new .tcfg file  ?
If so what would be the name of the tcfg file?

Also, can you please help me investigate why 5 more test fail?

Thanks,
Tanu Hari Dixit.

On Tue, Mar 21, 2017 at 12:36 PM, Tanu Hari Dixit  wrote:
>> I noticed you have 17 tests more than I do enabled. How did you configure?
>
> ../../rtems/configure --target=sparc-rtems4.12 --enable-tests
> --enable-rtemsbsp=erc32
> --prefix=/home/thd/development/rtems/install_path_erc32_alltest_new
>
> I used Joel's configuration, that is:
> ../../rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=erc32
> --prefix=/home/thd/development/rtems/install_path_erc32_js
> --disable-networking --enable-posix --disable-multiprocessing
> --disable-smp --enable-tests --enable-cxx --enable-maintainer-mode
>
> I got the following results:
> Passed:   540
> Failed: 6
> Timeouts:   9
> Invalid:0
> -
> Total:555
>
> Failures:
>  spcontext01.exe
>  mdosfs_fsscandir01.exe
>  jffs2_fsscandir01.exe
>  imfs_fsscandir01.exe
>  mimfs_fsscandir01.exe
>  mrfs_fsscandir01.exe
> Timeouts:
>  fsdosfsname01.exe
>  fsdosfswrite01.exe
>  fsimfsconfig02.exe
>  fsimfsgeneric01.exe
>  fsjffs2gc01.exe
>  fsdosfsformat01.exe
>  fsrfsbitmap01.exe
>  imfs_fserror.exe
>  crypt01.exe
> Average test time: 0:00:01.434556
> Testing time : 0:13:16.178701
>
>
> This is still one more test than Joel's total. I understand
> spcontext01.exe is expected to fail. But I can't figure out why the
> rest fail on my host. (My rtems source tree is updated.)
>
> Also, how can we change the number of cores operational? I found the
> --timeout option but none regarding the cores.
>
> Can the devs please help me with this?
>
> Thanking you,
> Tanu Hari Dixit.
>
> On Tue, Mar 21, 2017 at 5:55 AM, Chris Johns  wrote:
>> On 20/03/2017 17:20, Sebastian Huber wrote:
>>>
>>>
>>>
>>> On 18/03/17 21:52, Joel Sherrill wrote:
>>>>
>>>>
>>>> FWIW here are my results for sparc/erc32:
>>>>
>>>> Passed:   548
>>>> Failed: 1
>>>> Timeouts:   5
>>>> Invalid:0
>>>> -
>>>> Total:554
>>>>
>>>> Failures:
>>>>  spcontext01.exe
>>>
>>>
>>> Yes, this is expected.
>>>
>>>> Timeouts:
>>>>  fileio.exe
>>>>  top.exe
>>>>  termios.exe
>>>>  capture.exe
>>>>  monitor.exe
>>>
>>>
>>> These tests should terminate after 20 seconds or so without input. A
>>> timeout should therefore not occur.
>>
>>
>> That is 20 seconds of target time and not real-time if running on a heavily
>> loaded machine running simulators in parallel. The test tool's timeout is
>> real time.
>>
>> I have created https://devel.rtems.org/ticket/2946 to look into this.
>>
>> Chris
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] RTEMS Tester Improvements

2017-03-21 Thread Tanu Hari Dixit

Thank you so much Chris for the elaborate answers.  I have a clearer
idea of the project now. Thank you Gedare for the tip, it definitely
comes in handy.
I'm sorry for the late reply. I have more questions and I will be
grateful if the devs can help me with these.

How does one use the console? I see extensive use of termios in
rtems-tools.git/tester/rt/stty.py which is in turn used in
tester/rt/console.py Can you please demonstrate one example so that I
get an idea? I believe PySerial will need to be configured in a
similar way i.e. making objects of class tty and assigning them
attributes with Pyserial instead of termios (like ignbrk and the
rest). Please correct me if I am wrong.

Moreover, about the telnet console, I went through the ser2net
package. It serves as a good way to convert (or maybe the right word
is "use") serial connections via telnet. I can make a simple bash
script to install ser2net and then change its conf file to fix the
appropriate port numbers and banners(which I can take as entry from
user). Then I shall use them via telnetlib to communicate to the hosts
and then I can run tests via the console on the target. Is this the
right direction or should I be thinking differently?
Also I am really confused as to how rtemstoolkit comes into the
picture. Can you please provide me with a rough workflow of the
console?

I also had questions regarding extending support for "expected-fail"
and "user-input" state as mentioned here
(https://devel.rtems.org/ticket/2946). What follows is my
understanding of what I need to do to extend support for
"user-input"(and "expected-fail"), please correct me if I am wrong. I
need to make a directive like DTEST_STATE_USER_INPUT and declare it to
be 1 in /rtems/src/rtems/tools/build/rtems-test-check and choose a
suitable TEST_STATE_STRING in buffer_test_io.h. Consequently, parse
for it in tester/rt/report.py. (probably this has to be done for
"expected-fail" state also). Also, I would need to extend the
attributes of class report that already has
self.passed = 0
self.failed = 0
self.timeouts = 0
self.invalids = 0
to also include self.expected_fails and self.user_inputs. Please
correct me if I am wrong. Can you please point me to the commit with
which you added support for "extended-fail"?

Furthermore, I was able to run the hello world example on
arm/xilinx_zync_a9_qemu with rtems-test as you demonstrated. Thank
you. Also, I understand why you emphasize on keeping a plotting tool
different from rtems-tester.

An aside question: Do you use winpdb to debug the python scripts in
rtems-tester? Do you recommend some other tool?

Thanking you,
Tanu Hari Dixit.

On Sat, Mar 18, 2017 at 1:53 AM, Gedare Bloom  wrote:
> On Wed, Mar 15, 2017 at 6:57 PM, Chris Johns  wrote:
>> On 16/03/2017 08:44, Tanu Hari Dixit wrote:
>>> Hello Chris, Gedare, Joel,
>>> Thank you for answering my questions. Sorry for the late reply, it
>>> took me time to go through the tasks suggested.
>>>>
>>>> What platforms have you run tester on?
>>>
>>> I was searching for a way to compile and execute a single test and the
>>> community suggetsed rtems-tester. So I ran the tester on sparc/erc32
>>> (and no simulator).
>>
>> Great, this is what the tool is for.
>>
>>> I am unable to find a relevant doc on how to run rtems-tester on qemu.
>>> Though there is this rtems-tools.git/tester/rtems/testing/qemu.cfg so
>>> I know that it is supported.
>>
>> The `--list-bsps` gives some hints however not all BSPs that use qemu have 
>> this in the test BSP name. After a waf configure and build try:
>>
>> ruru rtems-tools.git $ pwd
>> /opt/work/chris/rtems/tools/rtems-tools.git
>> ruru rtems-tools.git $ ./tester/rtems-test --list-bsps | grep qemu
>>   realview_pbx_a9_qemu
>>   xilinx_zynq_a9_qemu
>>   xilinx_zynq_a9_qemu_smp
>>   xilinx_zynq_zc706_qemu
>>
>> The low level and simplest way to currently see is:
>>
>> ruru rtems-tools.git $ grep -r qemu.cfg tester/rtems
>> tester/rtems/testing/bsps/xilinx_zynq_a9_qemu.mc:xilinx_zynq_a9_qemu:  
>> none,none,  '%{_rtscripts}/qemu.cfg'
>> tester/rtems/testing/bsps/generic_or1k.mc:generic_or1k:  none,none,  
>> '%{_rtscripts}/qemu.cfg'
>> tester/rtems/testing/bsps/xilinx_zynq_zc706_qemu.mc:xilinx_zynq_zc706:  
>> none,none,  '%{_rtscripts}/qemu.cfg'
>> tester/rtems/testing/bsps/xilinx_zynq_a9_qemu_smp.mc:xilinx_zynq_a9_qemu:
>>   none,none,  '%{_rtscripts}/qemu.cfg'
>> tester/rtems/testing/bsps/realview_pbx_a9_qemu.mc:realview_pbx_a9_qemu:  
>> none,none,  '%{_rtscripts}/qemu.cfg'
>

Re: timeouts and failure

2017-03-21 Thread Tanu Hari Dixit

> I noticed you have 17 tests more than I do enabled. How did you configure?

../../rtems/configure --target=sparc-rtems4.12 --enable-tests
--enable-rtemsbsp=erc32
--prefix=/home/thd/development/rtems/install_path_erc32_alltest_new

I used Joel's configuration, that is:
../../rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=erc32
--prefix=/home/thd/development/rtems/install_path_erc32_js
--disable-networking --enable-posix --disable-multiprocessing
--disable-smp --enable-tests --enable-cxx --enable-maintainer-mode

I got the following results:
Passed:   540
Failed: 6
Timeouts:   9
Invalid:0
-
Total:555

Failures:
 spcontext01.exe
 mdosfs_fsscandir01.exe
 jffs2_fsscandir01.exe
 imfs_fsscandir01.exe
 mimfs_fsscandir01.exe
 mrfs_fsscandir01.exe
Timeouts:
 fsdosfsname01.exe
 fsdosfswrite01.exe
 fsimfsconfig02.exe
 fsimfsgeneric01.exe
 fsjffs2gc01.exe
 fsdosfsformat01.exe
 fsrfsbitmap01.exe
 imfs_fserror.exe
 crypt01.exe
Average test time: 0:00:01.434556
Testing time : 0:13:16.178701


This is still one more test than Joel's total. I understand
spcontext01.exe is expected to fail. But I can't figure out why the
rest fail on my host. (My rtems source tree is updated.)

Also, how can we change the number of cores operational? I found the
--timeout option but none regarding the cores.

Can the devs please help me with this?

Thanking you,
Tanu Hari Dixit.

On Tue, Mar 21, 2017 at 5:55 AM, Chris Johns  wrote:
> On 20/03/2017 17:20, Sebastian Huber wrote:
>>
>>
>>
>> On 18/03/17 21:52, Joel Sherrill wrote:
>>>
>>>
>>> FWIW here are my results for sparc/erc32:
>>>
>>> Passed:   548
>>> Failed: 1
>>> Timeouts:   5
>>> Invalid:0
>>> -
>>> Total:554
>>>
>>> Failures:
>>>  spcontext01.exe
>>
>>
>> Yes, this is expected.
>>
>>> Timeouts:
>>>  fileio.exe
>>>  top.exe
>>>  termios.exe
>>>  capture.exe
>>>  monitor.exe
>>
>>
>> These tests should terminate after 20 seconds or so without input. A
>> timeout should therefore not occur.
>
>
> That is 20 seconds of target time and not real-time if running on a heavily
> loaded machine running simulators in parallel. The test tool's timeout is
> real time.
>
> I have created https://devel.rtems.org/ticket/2946 to look into this.
>
> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: timeouts and failure

2017-03-18 Thread Tanu Hari Dixit

Gedare,
By erc32 under gdb do you mean using --debug-trace=gdb option with rtems-test ?
I ran a normal
 ./rtems-test --log=log_erc32_run_alltest_new --rtems-bsp=erc32-run
--rtems-tools=$HOME/development/rtems/4.12
/home/thd/development/rtems/src/builds/b-erc32_allt/sparc-rtems4.12/c/erc32/testsuites

without the debug trace option and got the following results:

Passed:   543
Failed: 6
Timeouts:  12
Invalid:0
-
Total:561

Failures:
 mdosfs_fsscandir01.exe
 spcontext01.exe
 jffs2_fsscandir01.exe
 mrfs_fsscandir01.exe
 imfs_fsscandir01.exe
 mimfs_fsscandir01.exe
Timeouts:
 mdosfs_fsrdwr.exe
 mimfs_fserror.exe
 fsdosfsname01.exe
 mimfs_fspatheval.exe
 mouse01.exe
 fsdosfswrite01.exe
 malloctest.exe
 math.exe
 crypt01.exe
 fsdosfsformat01.exe
 mdosfs_fstime.exe
 mimfs_fsrdwr.exe

Regards,
Tanu Hari Dixit.

On Sat, Mar 18, 2017 at 11:47 AM, Chris Johns  wrote:
> On 18/3/17 11:46 am, Gedare Bloom wrote:
>> I just ran tests and observe the following on erc32 under gdb, can
>> anyone confirm/replicate the timeouts and failure, and know why this
>> is happening?
>
> How many cores are you using with rtems-test and so how many tests are
> running in parallel? This can effect the time per test and it is
> difficult to know the effect this has on the timeout per host machine
> being used.
>
> Chris
>
>>
>> Passed:   554
>> Failed: 1
>> Timeouts:   6
>> Invalid:0
>> Total:561
>>
>> Result: timeoutTime: 0:03:00.219154 fsdosfsformat01.exe
>> Result: timeoutTime: 0:03:00.228353 fsdosfsname01.exe
>> Result: timeoutTime: 0:03:00.217955 fsdosfsname02.exe
>> Result: timeoutTime: 0:03:00.189769 fsrfsbitmap01.exe
>> Result: timeoutTime: 0:03:00.203202 imfs_fserror.exe
>> Result: timeoutTime: 0:03:00.207983 crypt01.exe
>> Result: failed Time: 0:00:02.056732 spcontext01.exe
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Potential GSoC Students Proposal Drafts

2017-03-17 Thread Tanu Hari Dixit

I have added a google doc to the table but I still have to work on
most of the draft.
Thank you, Gedare.

Regards,
Tanu Hari Dixit.

On Fri, Mar 17, 2017 at 11:22 PM, Gedare Bloom  wrote:
> Dear Aspiring GSoC Students:
>
> If you are planning to submit an application to RTEMS, please add your
> preliminary draft and some basic information to the "Proposals" table
> at https://devel.rtems.org/wiki/GSoC/2017
>
> Thanks!
> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] RTEMS Tester Improvements

2017-03-15 Thread Tanu Hari Dixit

Hello Chris, Gedare, Joel,
Thank you for answering my questions. Sorry for the late reply, it
took me time to go through the tasks suggested.
>
> What platforms have you run tester on?

I was searching for a way to compile and execute a single test and the
community suggetsed rtems-tester. So I ran the tester on sparc/erc32
(and no simulator).

I am unable to find a relevant doc on how to run rtems-tester on qemu.
Though there is this rtems-tools.git/tester/rtems/testing/qemu.cfg so
I know that it is supported. Also I couldn't find any other hint in
the rtems-tools repository as to which simulators (except for qemu)
are supported. rtems-testing/sim-scripts support gdbsim, skyeye and
tsim (other than qemu). So we can add support for these and gem5 (as
Gedare suggested). Please correct me if I am wrong.

Furthermore, if you could please point me to a doc that explains using
rtems-tester on qemu? I have tested qemu for running an application,
the steps for which I have documented here
(http://tokencolour.github.io/2017/03/16/how-to-run-applications-on-qemu-rtems.html).

I can play with visualizing aggregated testing results with plotting
techniques (like matplotlib or maybe something that the devs
recommend) :).

Also, where can I find more about "expected fail" state? Is it for
those tests that fail nevertheless and need to be skipped? Can you
please point me to an example? Also, what kind of regression will one
need to perform? Do the final states of the test need to maintain an
overall state of the system so as to recommend/predict the state of
affairs next time the tests are run (i.e. a predictor (which has
memory) kind of thing)?

I also think that converting macro files to yaml won't be very
difficult. I might be very myopic here and it would be great if I get
a heads up. What will be the challenge here?

For the generic serial console, will pySerial do the trick, on
Windows? Do you have some other package in mind?

I have a problem here, though. I don't own a Zedboard and can't afford
one. I can check with my department at college once I reach there, but
I don't have my hopes too high. Will this pose a problem in the course
of the project?

I am yet to build for xilinx_zynq_zc706, so I'll ask more questions on
the configuration control once I am done with it. Also, I'm trying out
the old and new approach for Coverage reporting. I'll ask questions on
it, once I try it.

Thank you,
Tanu Hari Dixit.

On Wed, Mar 15, 2017 at 2:37 AM, Chris Johns  wrote:
> On 15/3/17 1:02 am, Gedare Bloom wrote:
>> On Tue, Mar 14, 2017 at 9:58 AM, Gedare Bloom  wrote:
>>> On Tue, Mar 14, 2017 at 1:50 AM, Chris Johns  wrote:
>>>> On 14/3/17 9:18 am, Chris Johns wrote:
>>>>>
>>>>> The follow is the work I see needing to be done.
>>>>>
>>>>
>>>> I have created a ticket for this project. Please update and add
>>>> BSP/Simulator section to track those tasks.
>>>>
>>>>  https://devel.rtems.org/ticket/2927
>>>>
>>> Does this supersede https://devel.rtems.org/ticket/2919
>>>
>>
>> Note: I classify Testing Tool Improvements as part of improving our
>> Developer Ecosystem rather than as a Testing project. A subtle
>> distinction perhaps, but I feel it is important to understand where we
>> draw these kinds of lines.
>>
>
> I agree, one side is what a test is and how to create a test executable
> and as you say this project is about the ecosystem used to execute these
> tests and manage the results.
>
> Chris
> ___
> 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

[GSoC] RTEMS Tester Improvements

2017-03-13 Thread Tanu Hari Dixit

Hello all,

I am interested in applying for GSoC under RTEMS. I am interested in the
idea RTEMS Tester Improvements (https://devel.rtems.org/ticket/2919). I
have used rtems-tester in the past and also have a working knowledge of
python.

I have a few questions and will be grateful if they are answered.
1) Which simulator recipes need to be added?
2) What are the improvements that need to be done? I couldn't find the
appropriate tickets or pointers.
3) Do I need to start a Google doc for the proposal or is there some other
platform, I need to write on? Is there a template, I should be aware of?
4) Is the implementation of this idea in general interest of the community?
5) Will this be enough work for the GSoC term or will I have to club this
with another idea (maybe the one where we have to design simple examples
(different from tests) for user documentation so that it is easy for users
to see how to use a call.) or will that be a stretch goal?

Thank you,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Tanu Hari Dixit

Hello Devs,

I wanted to build the toolset for Beaglebone following the blog (
http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
).
However, the build failed.
I got the following message.

download:
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2 ->
sources/gcc-6-20160526.tar.bz2
download:
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2:
error: 
error: downloading
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
paths have failed, giving up
Build FAILED
  See error report:
rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
error: downloading
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all
paths have failed, giving up
Build Set: Time 0:01:46.366099
Build FAILED

Probably, the link is broken.

It is probably using
rtems-source-builder/rtems/config/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg

which sets this url which ultimately is used by
rtems-source-builder/source-builder/config/gcc-common-1.cfg . Please
correct me if I am wrong.

How do I fix this? Is there something I am missing?

Thanks,
Tanu Hari Dixit.
RTEMS Tools Project - Source Builder Error Report
 Build: error: downloading 
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2: all 
paths have failed, giving up
 Command Line: ../source-builder/sb-set-builder --log=beagle.txt 
--prefix=/home/thd/development/rtems/4.12 devel/beagle.bset
 Python: 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2]
 
https://github.com/bengras/rtems-source-builder.git/origin/c4db36683559bdb9facf6ea918ea1ba098aa11c6
 Linux thd-Inspiron-5537 3.19.0-68-generic #76~14.04.1-Ubuntu SMP Fri Aug 12 
11:46:25 UTC 2016 x86_64
Tail of the build log:
test -z "/home/thd/development/rtems/4.12/bin" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin"
  /bin/sh ./libtool   --mode=install /usr/bin/install -c gprof 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin/./arm-rtems4.12-gprof'
libtool: install: /usr/bin/install -c gprof 
/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/bin/./arm-rtems4.12-gprof
test -z "/home/thd/development/rtems/4.12/share/info" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info"
 /usr/bin/install -c -m 644 ../../binutils-2.26/gprof/gprof.info 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info'
 install-info 
--info-dir='/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info'
 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/info/gprof.info'
This is not dpkg install-info anymore, but GNU install-info
See the man page for ginstall-info for command line arguments
test -z "/home/thd/development/rtems/4.12/share/man/man1" || /bin/mkdir -p 
"/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/man/man1"
 /usr/bin/install -c -m 644 '../../binutils-2.26/gprof/gprof.1' 
'/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/tmp/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1-root-thd/home/thd/development/rtems/4.12/share/man/man1/arm-rtems4.12-gprof.1'
make[5]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[4]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[3]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[2]: Leaving directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/gprof'
make[2]: Entering directory 
`/home/thd/development/rtems/src/rtems-source-builder-beng/rtems/build/arm-rtems4.12-binutils-2.26-x86_64-linux-gnu-1/build/intl

Re: Using helper functions

2017-02-07 Thread Tanu Hari Dixit

Oh, yes. Thanks for the heads up. I'll rebuild it.

Regards,
Tanu Hari Dixit.

On Tue, Feb 7, 2017 at 8:14 PM, punit vara  wrote:

> If you are trying to build my gpio sample then its just for arm
> architecture and specifically for beagle bone black. Sparc is
> completely different architecture so sample won't build in it.
>
> On Tue, Feb 7, 2017 at 7:12 PM, Tanu Hari Dixit 
> wrote:
> > Hello Punit,
> >
> > Thank you for the explanation. I did as you suggested.  I copied the gpio
> > folder to testsuites/samples/ and edited configure.ac, ran bootstrap,
> > configure and make for the new build. It ran fine (without errors).
> However,
> > I could see all executables except for one in
> > /home/thd/development/rtems/src/builds/erc32_gpio/sparc-
> rtems4.12/c/erc32/testsuites/samples/gpio
> > for the gpio application. I am unable to figure out what might be the
> fault.
> > The bootstrap and configure are as below. The make output is attached.
> > Something strange that I observed in the make output is, that unlike
> other
> > subdirectories in samples, there never appears a line like:
> > make[6]: Entering directory
> > `/home/thd/development/rtems/src/builds/erc32_gpio/sparc-
> rtems4.12/c/erc32/testsuites/samples/gpio'
> > Also the gpio folder in
> > home/thd/development/rtems/src/builds/erc32_gpio/sparc-
> rtems4.12/c/erc32/testsuites/samples/gpio
> > just has Makefile in it.
> > I (just experimenting) ran the Makefile and I got the following output:
> >
> > thd@thd-Inspiron-5537:~/development/rtems/src/builds/
> erc32_gpio/sparc-rtems4.12/c/erc32/testsuites/samples/gpio$
> > make
> > sparc-rtems4.12-gcc -B../../../../../erc32/lib/ -specs bsp_specs -qrtems
> > -DHAVE_CONFIG_H -I.
> > -I../../../../../../../../rtems/c/src/../../testsuites/samples/gpio -I..
> > -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall
> > -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> > -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o
> > ../../../../../../../../rtems/c/src/../../testsuites/samples/gpio/init.c
> > ../../../../../../../../rtems/c/src/../../testsuites/
> samples/gpio/init.c:6:70:
> > fatal error: bsp/beagleboneblack.h: No such file or directory
> >  #include  /* Calls the BBB specific library */
> >   ^
> > compilation terminated.
> > make: *** [init.o] Error 1
> >
> > Maybe that is the error I am facing. I don't know how to rectify it. I
> > searched for similar errors but found no luck. Can you please help me
> with
> > this?
> > Also, now I am able to understand more and have a feeling that I'll soon
> > have a working application that is made by me. Thank you.
> >
> > Regards,
> > Tanu Hari Dixit.
> >
> >
> > OUTPUT: ./bootstrap
> >
> > ./cpukit
> > ./c
> > ./c/src/ada-tests
> > ./c/src
> > ./c/src/make
> > ./c/src/lib/libbsp/bfin/bf537Stamp
> > ./c/src/lib/libbsp/bfin/eZKit533
> > ./c/src/lib/libbsp/bfin
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/bfin/TLL6527M
> > ./c/src/lib/libbsp/mips/malta
> > ./c/src/lib/libbsp/mips/jmr3904
> > ./c/src/lib/libbsp/mips/csb350
> > ./c/src/lib/libbsp/mips/rbtx4925
> > ./c/src/lib/libbsp/mips
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/mips/rbtx4938
> > ./c/src/lib/libbsp/mips/hurricane
> > ./c/src/lib/libbsp/epiphany
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/epiphany/epiphany_sim
> > ./c/src/lib/libbsp/sparc/leon2
> > ./c/src/lib/libbsp/sparc
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/sparc/erc32
> > ./c/src/lib/libbsp/sparc/leon3
> > ./c/src/lib/libbsp/no_cpu
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/no_cpu/no_bsp
> > ./c/src/lib/libbsp/sh/shsim
> > ./c/src/lib/libbsp/sh/gensh2
> > ./c/src/lib/libbsp/sh/gensh4
> > ./c/src/lib/libbsp/sh
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/sh/gensh1
> > ./c/src/lib/libbsp/moxie
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/moxie/moxiesim
> > ./c/src/lib/libbsp/m32c/m32cbsp
> > ./c/src/lib/libbsp/m32c
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/nios2
> > acinclude.m4 is unchanged
> > ./c/src/lib/libbsp/nios2/nios2_iss
> > ./c/src/lib/libbsp/arm/altera-cyclone-v
> > ./c/src/lib/libbsp/arm/raspberrypi
> > ./c/src/lib/libbsp/arm/beagle
> > ./c/src/lib/libbsp/arm/edb7312
> > ./c/src/lib/libbsp/arm/gumstix
>

Re: Using helper functions

2017-02-07 Thread Tanu Hari Dixit

Hello Joel,

> An alternative is to look at the examples-v2 repo. It shows how to
> builds RTEMS applications external to the RTEMS tree using waf.
>
I had tried example-v2 a few days back. I'll try to make an application
with the help of it. Thank you.

Regards,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using helper functions

2017-02-06 Thread Tanu Hari Dixit

Hello Gedare,

> see rtems.git/testsuites/fstests for examples of some filesystem usage.

I'll look into this testsuite in more depth. Thanks.

Regards,
Tanu Hari Dixit.

On Mon, Feb 6, 2017 at 8:31 PM, Tanu Hari Dixit 
wrote:

> Hello Punit, Gedare,
>
> Thanks for the answer.
>
> Which file system API you are talking about ? Can you please send me
>> the file location ?
>
>
> The file system I am talking about is In-Memory FileSystem (imfs). The
> file location is:
> /home/thd/development/rtems/src/rtems/cpukit/libfs/src/imfs
>
> I cloned the repo you linked to in your previous mail. However, I am
> unable to figure out how to run the application. I have kept it outside the
> rtems tree. I know how executables for tests are made i.e. by the configure
> script at the top. But I don't know how I will be able to run an
> application outside of testsuites. For example, my question is
> rtems_gsoc16/gpio has no configure.ac file. I don't understand how to
> generate make file in this case. Please help me with this.
>
> What example did you take to learn how to make an application (and run
> it)?
>
> Thank you so much.
> Tanu Hari Dixit.
>
> On Thu, Feb 2, 2017 at 11:16 PM, Gedare Bloom  wrote:
>
>> see rtems.git/testsuites/fstests for examples of some filesystem usage.
>>
>> On Thu, Feb 2, 2017 at 12:03 PM, punit vara  wrote:
>> > Hi
>> >
>> > Which file system API you are talking about ? Can you please send me
>> > the file location ?
>> >
>> > I have used some of GPIO APIs for BBB board. Have a look at this example
>> >
>> > https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c
>> >
>> > Similarly you can create application for any APIs.
>> >
>> > P.S. Always add devel mailing list as CC so that other person also can
>> > help you :)
>> >
>> > Thanks
>> > PV
>> >
>> > On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit 
>> wrote:
>> >> Hello Punit,
>> >> I have been reading the docs as you suggested. But I want to execute
>> >> the various directives and helper functions and test for myself in an
>> >> isolated example. For example I want to test the various API functions
>> >> available for the filesystem (In memory Filesystem) in RTEMS. How do I
>> >> go about doing that?
>> >> Thanks,
>> >> Tanu Hari Dixit.
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using helper functions

2017-02-06 Thread Tanu Hari Dixit

Hello Punit, Gedare,

Thanks for the answer.

Which file system API you are talking about ? Can you please send me
> the file location ?

The file system I am talking about is In-Memory FileSystem (imfs). The file
location is:
/home/thd/development/rtems/src/rtems/cpukit/libfs/src/imfs

I cloned the repo you linked to in your previous mail. However, I am unable
to figure out how to run the application. I have kept it outside the rtems
tree. I know how executables for tests are made i.e. by the configure
script at the top. But I don't know how I will be able to run an
application outside of testsuites. For example, my question is
rtems_gsoc16/gpio has no configure.ac file. I don't understand how to
generate make file in this case. Please help me with this.

What example did you take to learn how to make an application (and run it)?

Thank you so much.
Tanu Hari Dixit.

On Thu, Feb 2, 2017 at 11:16 PM, Gedare Bloom  wrote:

> see rtems.git/testsuites/fstests for examples of some filesystem usage.
>
> On Thu, Feb 2, 2017 at 12:03 PM, punit vara  wrote:
> > Hi
> >
> > Which file system API you are talking about ? Can you please send me
> > the file location ?
> >
> > I have used some of GPIO APIs for BBB board. Have a look at this example
> >
> > https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c
> >
> > Similarly you can create application for any APIs.
> >
> > P.S. Always add devel mailing list as CC so that other person also can
> > help you :)
> >
> > Thanks
> > PV
> >
> > On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit 
> wrote:
> >> Hello Punit,
> >> I have been reading the docs as you suggested. But I want to execute
> >> the various directives and helper functions and test for myself in an
> >> isolated example. For example I want to test the various API functions
> >> available for the filesystem (In memory Filesystem) in RTEMS. How do I
> >> go about doing that?
> >> Thanks,
> >> Tanu Hari Dixit.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding running one test

2017-02-06 Thread Tanu Hari Dixit

Hello Joel,

>
> You either configure for no tests, samples or all tests.
>
I finally understand this. Thanks.

> If you are trying to speed up a build for debug purposes, you can be
> careful and build just cpukit again and then switch.to the test
> directory.
>
By this do you mean, that if I make some changes in the cpukit, I rebuild
it---(i.e run the configure script in  rtems/cpukit and consequently make)
and it will be all that I am required to do? Won't I need to make the
executables again?

Regards,
Tanu Hari Dixit.

On Mon, Feb 6, 2017 at 7:08 PM, Tanu Hari Dixit 
wrote:

> Hello Gedare, Joel,
>
> I was able to re-build and execute the samples following your advice.
> Thank you.
>
> Regards,
> Tanu Hari Dixit.
>
>
> On Sun, Feb 5, 2017 at 3:03 AM, Gedare Bloom  wrote:
> > After you do a git-pull you should usually re-run bootstrap, delete
> > your build, and re-run configure and make. This is especially true if
> > you re-build a toolchain, at least to get started.
> >
> > On Sat, Feb 4, 2017 at 10:26 AM, Tanu Hari Dixit 
> wrote:
> >> Hi Kevin, Kuan-Hsun,
> >>
> >> Thank you for the answer.
> >> I have run into a problem before trying the above solutions for myself,
> >> while updating my local copy of the rtems repository with upstream with
> "git
> >> pull".
> >> After I updated the local copy, I built the sparc toolset with
> >> ../source-builder/sb-set-builder --log=l-sparc-test.txt
> >> --prefix=$HOME/development/rtems/4.12 4.12/rtems-sparc
> >> Then I ran  ./bootstrap -c && ./bootstrap -p && ./bootstrap so as to
> >> bootstrap.
> >> Then from  builds/erc32_test(subdirectory) I ran
> >> thd@thd-Inspiron-5537:~/development/rtems/src/rtems$
> ../../rtems/configure
> >> --target=sparc-rtems4.12 --enable-rtemsbsp=erc32 --enable-tests
> >> --prefix=${HOME}/development/rtems/install_path_test
> >>
> >> And when I ran make, It showed the following error;
> >>
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/build'
> >> make[1]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/build'
> >> Making all in tools/cpu
> >> make[1]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
> >> Making all in generic
> >> make[2]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
> >> make[2]: Nothing to be done for `all'.
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
> >> make[2]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
> >> make[2]: Nothing to be done for `all-am'.
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
> >> make[1]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
> >> Making all in testsuites/tools
> >> make[1]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
> >> Making all in generic
> >> make[2]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/
> testsuites/tools/generic'
> >> make[2]: Nothing to be done for `all'.
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/
> testsuites/tools/generic'
> >> make[2]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
> >> make[2]: Nothing to be done for `all-am'.
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
> >> make[1]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
> >> Making all in sparc-rtems4.12/c
> >> make[1]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
> >> Making all in .
> >> make[2]: Entering directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
> >> make[2]: Nothing to be done for `all-am'.
> >> make[2]: Leaving directory
> >> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
> >> Making all in erc32
> >> make[2]: Entering directory
> >>

Re: Regarding running one test

2017-02-06 Thread Tanu Hari Dixit

Hello Gedare, Joel,

I was able to re-build and execute the samples following your advice. Thank you.

Regards,
Tanu Hari Dixit.


On Sun, Feb 5, 2017 at 3:03 AM, Gedare Bloom  wrote:
> After you do a git-pull you should usually re-run bootstrap, delete
> your build, and re-run configure and make. This is especially true if
> you re-build a toolchain, at least to get started.
>
> On Sat, Feb 4, 2017 at 10:26 AM, Tanu Hari Dixit  
> wrote:
>> Hi Kevin, Kuan-Hsun,
>>
>> Thank you for the answer.
>> I have run into a problem before trying the above solutions for myself,
>> while updating my local copy of the rtems repository with upstream with "git
>> pull".
>> After I updated the local copy, I built the sparc toolset with
>> ../source-builder/sb-set-builder --log=l-sparc-test.txt
>> --prefix=$HOME/development/rtems/4.12 4.12/rtems-sparc
>> Then I ran  ./bootstrap -c && ./bootstrap -p && ./bootstrap so as to
>> bootstrap.
>> Then from  builds/erc32_test(subdirectory) I ran
>> thd@thd-Inspiron-5537:~/development/rtems/src/rtems$ ../../rtems/configure
>> --target=sparc-rtems4.12 --enable-rtemsbsp=erc32 --enable-tests
>> --prefix=${HOME}/development/rtems/install_path_test
>>
>> And when I ran make, It showed the following error;
>>
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/build'
>> make[1]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/build'
>> Making all in tools/cpu
>> make[1]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
>> Making all in generic
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
>> make[2]: Nothing to be done for `all'.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
>> make[2]: Nothing to be done for `all-am'.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
>> make[1]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
>> Making all in testsuites/tools
>> make[1]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
>> Making all in generic
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools/generic'
>> make[2]: Nothing to be done for `all'.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools/generic'
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
>> make[2]: Nothing to be done for `all-am'.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
>> make[1]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
>> Making all in sparc-rtems4.12/c
>> make[1]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
>> Making all in .
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
>> make[2]: Nothing to be done for `all-am'.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
>> Making all in erc32
>> make[2]: Entering directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c/erc32'
>> make[2]: *** No rule to make target `all'.  Stop.
>> make[2]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c/erc32'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory
>> `/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
>> make: *** [all-recursive] Error 1
>>
>> I have ran into this problem more than once. When last time this happened, I
>> thought I must have messed up somewhere in the git (or rtems) workflow and
>> hence decided to make a clean clone of the rtems repo and continue with it.
>> I also tried git reset --hard  last time and had no luck.
>> Right now, I did not do a hard reset and currently git reflog shows the
>> following output:
>> 239dd35 HEAD@{0}: pull: Fast-forward
>> ffa885a HEAD@{1}: clone: from git://git.rtems.org/rtems.git

Re: GSoC Mentors / Projects of Interest

2017-02-05 Thread Tanu Hari Dixit

Hello all,

I have edited the open projects page to include my workflow for adding
tickets(https://devel.rtems.org/wiki/Developer/OpenProjects#HelpConverttoTickets).
Kindly review it and help me edit the required changes.

Thank you,
Tanu Hari Dixit.

On Mon, Feb 6, 2017 at 9:38 AM, Chris Johns  wrote:
> Hi,
>
> This is a great idea.
>
> On 01/02/2017 05:54, Gedare Bloom wrote:
>>
>> * Use only one keyword. I prefer "SoC" so it is generic to other
>> 'summer of code' style projects.
>
>
> I have added a new report under "Available Reports" called "SoC Projects".
> You can find the "Available Reports" link just under the menu bar after
> clicking on "View Tickets".
>
>> * Use the components field to further categorize. We have some obvious
>> ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'.
>> Others should be identified or else we can create new components if
>> necessary. I'd like to stick with the current subheadings for this
>> year's GSoC, but we can revise later.
>
>
> I have added a new ticket type "project" to separate the informational
> nature of these tickets from the other ticket types and I have updated all
> existing SoC tickets to be now be projects.
>
> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Mentors / Projects of Interest

2017-02-05 Thread Tanu Hari Dixit

Hello all,

I added the following tickets for the BSP projects:
https://devel.rtems.org/ticket/2898#ticket
https://devel.rtems.org/ticket/2899#ticket
https://devel.rtems.org/ticket/2900#ticket
https://devel.rtems.org/ticket/2901#ticket
https://devel.rtems.org/ticket/2903#ticket
https://devel.rtems.org/ticket/2904#ticket
https://devel.rtems.org/ticket/2905#ticket

Also, I have edited the open projects page to include my workflow for
adding tickets(
https://devel.rtems.org/wiki/Developer/OpenProjects#HelpConverttoTickets).
Kindly review it and help me edit the required changes.

Thank you,
Tanu Hari Dixit.


On Wed, Feb 1, 2017 at 11:44 PM, Tanu Hari Dixit 
wrote:

> > If you're logged in then you should see a small link "Modify ↓" just
> > above the ticket box.
> I clicked on the Modify link but it doesn't give me an option to edit
> the description.
>
> Thanks,
> Tanu Hari Dixit.
>
> On Wed, Feb 1, 2017 at 10:47 PM, Kuan Hsun Chen
>  wrote:
> > Hi Gedare,
> >
> > I think we are not able to modify the content of tickets. I have tried
> the
> > ticket I initialized before.
> > I can only change properties summary and action.
> >
> > Best,
> > Kuan-Hsun
> >
> > 2017-02-01 17:55 GMT+01:00 Gedare Bloom :
> >>
> >> On Wed, Feb 1, 2017 at 12:49 AM, Tanu Hari Dixit  >
> >> wrote:
> >> > Hello,
> >> >
> >> > I'm unable to change the content of "Description" field on Trac. I
> >> > read https://devel.rtems.org/wiki/TracTickets and couldn't find any
> >> > luck. I read a thread on Trac's mailing list
> >> > (https://lists.gt.net/trac/users/46376). Perhaps, it has to do
> >> > something with TICKET_EDIT_DESCRIPTION permissions. How do I go about
> >> > doing this? What is it that I'm missing?
> >> >
> >> If you're logged in then you should see a small link "Modify ↓" just
> >> above the ticket box.
> >>
> >> > Regards,
> >> > Tanu Hari Dixit.
> >> >
> >> > On Wed, Feb 1, 2017 at 9:25 AM, Tanu Hari Dixit <
> tokencol...@gmail.com>
> >> > wrote:
> >> >>> * You removed the "Introduction" section. Any reason or just an
> >> >>> oversight?
> >> >>> * The 'status' field is gone too. But, I think the status is not
> >> >>> needed in the ticket format.
> >> >>
> >> >> I removed the "Introduction" section by mistake. I'll include it.
> >> >>
> >> >>>
> >> >>> Did you face any difficulties in making the transition? It would be
> >> >>> good to document your workflow on the Open Projects page.
> >> >>
> >> >> I wikiformatted the text myself. But it would have been better if I
> >> >> had just copied the already formatted text that pops up when we try
> to
> >> >> edit the project page
> >> >>
> >> >> (https://devel.rtems.org/wiki/Developer/Projects/Open/
> ImproveBeagleBSP?action=edit).
> >> >> No difficulties as such. I'll document the workflow on the open
> >> >> projects page.
> >> >>
> >> >>> We should convert all of the open projects to tickets eventually.
> And
> >> >>> then generate a report in the Open Projects page based on the
> tickets.
> >> >>> I have done this for the BSP ones and found the following changes
> >> >>> should be made in the workflow:
> >> >>
> >> >> Could you please direct me to the tickets you created? I couldn't
> find
> >> >> them on Trac.
> >> >>
> >> >>
> >> >>> I knew I had bought at least one so went to Amazon to see what we
> >> >>> have here at OAR.
> >> >>>
> >> >>>
> >> >>> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-
> Support/dp/B004LBXO2A
> >> >>>
> >> >>> Other folks in the community may have alternatives. It is a pretty
> >> >>> generic
> >> >>> piece of hardware. But there was that issue with the FTDI driver
> >> >>> refusing
> >> >>> to work with cloned FTDI chips. So I would bet there are some out
> >> >>> there
> >> >>> you don't want.
> >> >>
> >> >> I'll include the above hyperlink.
> >

Re: Regarding running one test

2017-02-04 Thread Tanu Hari Dixit

Hello Joel,

Thanks for the answer. I want to compile and build the exe file for just
one test. When I use the option --enable-tests with configure, does it
assume to build for all tests in the testsuites? I want to build for a
single test only. I haven't tried rtems-tester as of now because I updated
the rtems repository from upstream and have run into trouble. Can you
please help me with this?

Thanks,
Tanu Hari Dixit.

On Sat, Feb 4, 2017 at 10:24 PM, Joel Sherrill  wrote:

> If you are building the erc32 BSP, there are a handful of options. It is
> probably the easiest BSP to run tests on a simulator.
>
> sparc-rtems4.12-run xxx.exe
>
> sparc-rtems4.12-gdb xxx.exe
> ... target sim
> ... load
> ... run
>
> The rtems-tester supports this BSP to ease running tests for this BSP.
>
> Also the older rtems-testing repo has a sim-scripts directory with scripts
> to ease using a number of simulators. It has gdb and direct run modes.
>
> --joel
>
>
> On Feb 4, 2017 10:23 AM, "Tanu Hari Dixit"  wrote:
>
>> The following is the output of the configure statement (I ran configure
>> again because I did not save the output of the previous one)
>>
>> thd@thd-Inspiron-5537:~/development/rtems/src/builds/erc32_test1$
>> ../../rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=erc32
>> --enable-tests --prefix=${HOME}/development/rtems/install_path_test1
>> checking for gmake... no
>> checking for make... make
>> checking for RTEMS Version... 4.11.99.0
>> checking build system type... x86_64-pc-linux-gnu
>> checking host system type... x86_64-pc-linux-gnu
>> checking target system type... sparc-unknown-rtems4.12
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking that generated files are newer than configure... done
>> configure: creating ./config.status
>> configure: configuring in ./tools/build
>> configure: running /bin/sh '../../../../rtems/tools/build/configure'
>> '--prefix=/home/thd/development/rtems/install_path_test1'
>> '--host=x86_64-pc-linux-gnu' '--build=x86_64-pc-linux-gnu'
>> '--enable-rtemsbsp=erc32' '--enable-tests' '--target=sparc-rtems4.12'
>> '--cache-file=/dev/null' '--srcdir=../../../../rtems/tools/build'
>> checking for gmake... no
>> checking for make... make
>> checking for RTEMS Version... 4.11.99.0
>> checking build system type... x86_64-pc-linux-gnu
>> checking host system type... x86_64-pc-linux-gnu
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking for x86_64-pc-linux-gnu-gcc... no
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking for style of include used by make... GNU
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking getopt.h usability... yes
>> checking getopt.h presence... yes
>> checking for getopt.h... yes
>> checking libgen.h usability... yes
>> checking libgen.h presence... yes
>> checking for libgen.h... yes
>> checking for strerror... yes
>> checking for strtol... yes
>> checking for basename... yes
>> checking for strnlen... yes
>> c

Re: Regarding running one test

2017-02-04 Thread Tanu Hari Dixit

7;--host=x86_64-pc-linux-gnu' '--build=x86_64-pc-linux-gnu'
'--enable-rtemsbsp=erc32' '--enable-tests' '--target=sparc-rtems4.12'
'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu'
'target_alias=sparc-rtems4.12' --cache-file=/dev/null
--srcdir=../../../../../rtems/tools/cpu/generic
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for bash... /bin/bash
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating size_rtems
configure: configuring in ./testsuites/tools
configure: running /bin/sh '../../../../rtems/testsuites/tools/configure'
'--prefix=/home/thd/development/rtems/install_path_test1'
'--host=x86_64-pc-linux-gnu' '--build=x86_64-pc-linux-gnu'
'--enable-rtemsbsp=erc32' '--enable-tests' '--target=sparc-rtems4.12'
'--cache-file=/dev/null' '--srcdir=../../../../rtems/testsuites/tools'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
=== configuring in generic
(/home/thd/development/rtems/src/builds/erc32_test1/testsuites/tools/generic)
configure: running /bin/sh
../../../../../rtems/testsuites/tools/generic/configure
--disable-option-checking
'--prefix=/home/thd/development/rtems/install_path_test1'
'--host=x86_64-pc-linux-gnu' '--build=x86_64-pc-linux-gnu'
'--enable-rtemsbsp=erc32' '--enable-tests' '--target=sparc-rtems4.12'
'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu'
'target_alias=sparc-rtems4.12' --cache-file=/dev/null
--srcdir=../../../../../rtems/testsuites/tools/generic
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for bash... /bin/bash
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating difftest
config.status: creating sorttimes
configure: configuring in sparc-rtems4.12/c
configure: running /bin/sh '../../../../rtems/c/configure'
'--prefix=/home/thd/development/rtems/install_path_test1'
'--host=sparc-rtems4.12' '--build=x86_64-pc-linux-gnu'
'--target=sparc-rtems4.12'  '--enable-rtemsbsp=erc32' '--enable-tests'
'--with-target-subdir=sparc-rtems4.12'
'--exec-prefix=/home/thd/development/rtems/install_path_test1/sparc-rtems4.12'
'--includedir=/home/thd/development/rtems/install_path_test1/sparc-rtems4.12/include'
'--cache-file=/dev/null' '--srcdir=../../../../rtems/c'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... sparc-unknown-rtems4.12
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for sparc-rtems4.12-strip... sparc-rtems4.12-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
che

Re: Regarding running one test

2017-02-04 Thread Tanu Hari Dixit

Hi Kevin, Kuan-Hsun,

Thank you for the answer.
I have run into a problem before trying the above solutions for myself,
while updating my local copy of the rtems repository with upstream with
"git pull".
After I updated the local copy, I built the sparc toolset with
../source-builder/sb-set-builder --log=l-sparc-test.txt
--prefix=$HOME/development/rtems/4.12 4.12/rtems-sparc
Then I ran  ./bootstrap -c && ./bootstrap -p && ./bootstrap so as to
bootstrap.
Then from  builds/erc32_test(subdirectory) I ran
thd@thd-Inspiron-5537:~/development/rtems/src/rtems$ ../../rtems/configure
--target=sparc-rtems4.12 --enable-rtemsbsp=erc32 --enable-tests
--prefix=${HOME}/development/rtems/install_path_test

And when I ran make, It showed the following error;

make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/build'
make[1]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/build'
Making all in tools/cpu
make[1]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
Making all in generic
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu/generic'
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
make[1]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/tools/cpu'
Making all in testsuites/tools
make[1]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
Making all in generic
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools/generic'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools/generic'
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
make[1]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/testsuites/tools'
Making all in sparc-rtems4.12/c
make[1]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
Making all in .
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
Making all in erc32
make[2]: Entering directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c/erc32'
make[2]: *** No rule to make target `all'.  Stop.
make[2]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c/erc32'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/thd/development/rtems/src/builds/erc32_test/sparc-rtems4.12/c'
make: *** [all-recursive] Error 1

I have ran into this problem more than once. When last time this happened,
I thought I must have messed up somewhere in the git (or rtems) workflow
and hence decided to make a clean clone of the rtems repo and continue with
it. I also tried git reset --hard  last time and had no luck.
Right now, I did not do a hard reset and currently git reflog shows the
following output:
239dd35 HEAD@{0}: pull: Fast-forward
ffa885a HEAD@{1}: clone: from git://git.rtems.org/rtems.git

git status shows

thd@thd-Inspiron-5537:~/development/rtems/src/rtems$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   c/src/lib/libbsp/powerpc/acinclude.m4

no changes added to commit (use "git add" and/or "git commit -a")

I don't know what I am missing. Do I need to do something before pulling
from upstream? How do I rectify this? Please help me with this.

Thank you,
Tanu Hari Dixit.

On Sat, Feb 4, 2017 at 6:47 PM, Kuan Hsun Chen <
kuan-hsun.c...@tu-dortmund.de> wrote:

> Or alternatively you can prepare simulator like qemu to executed each of
> it after compiling the source tree.
> Like this in testsuites/hello/:
>
>1. qemu-system-arm -no-reboot -nographic -M realview-pbx-a9 -m 256M -kernel
>\
>2. hello.exe -smp 4
>
>
> Best,
> Kuan-Hsun
>
> 2017-02-04 14:12 GMT+01:00 Kirspel, Kevin :
>
>> I use the rtems tester.  ftp://ftp.rtems.org/pub/rtems/
>

Re: Regarding running one test

2017-02-03 Thread Tanu Hari Dixit

Also is there an alternative to this
(https://ftp.rtems.org/pub/rtems/people/chrisj/docs/user/test/index.html)
page in the docs?

Regards,
Tanu Hari Dixit.

On Sat, Feb 4, 2017 at 10:52 AM, Tanu Hari Dixit  wrote:
> Hello all,
>
> How do I run a single test from the testsuites? I want to run one test
> from the rtems/testsuites/fstests. How do I go about doing that?
>
> Regards,
> Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Regarding running one test

2017-02-03 Thread Tanu Hari Dixit

Hello all,

How do I run a single test from the testsuites? I want to run one test
from the rtems/testsuites/fstests. How do I go about doing that?

Regards,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding a beginner friendly bug

2017-02-01 Thread Tanu Hari Dixit

Thank you for pointing these out to me. I had a question, though. Why
isn't the proposed patch applied in
https://devel.rtems.org/ticket/2353 ?

Regards,
Tanu Hari Dixit.

On Wed, Feb 1, 2017 at 11:41 AM, Sebastian Huber
 wrote:
> Hello Tanu Hari Dixit,
>
> On 31/01/17 19:15, Tanu Hari Dixit wrote:
>>
>> Hello all,
>> Is there a beginner friendly bug that I can be assigned? I would like
>> to get involved and learn more about RTEMS.
>
>
> these three bugs are close to being beginner friendly:
>
> https://devel.rtems.org/ticket/2375
>
> https://devel.rtems.org/ticket/2353
>
> https://devel.rtems.org/ticket/2550
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Mentors / Projects of Interest

2017-02-01 Thread Tanu Hari Dixit

> If you're logged in then you should see a small link "Modify ↓" just
> above the ticket box.
I clicked on the Modify link but it doesn't give me an option to edit
the description.

Thanks,
Tanu Hari Dixit.

On Wed, Feb 1, 2017 at 10:47 PM, Kuan Hsun Chen
 wrote:
> Hi Gedare,
>
> I think we are not able to modify the content of tickets. I have tried the
> ticket I initialized before.
> I can only change properties summary and action.
>
> Best,
> Kuan-Hsun
>
> 2017-02-01 17:55 GMT+01:00 Gedare Bloom :
>>
>> On Wed, Feb 1, 2017 at 12:49 AM, Tanu Hari Dixit 
>> wrote:
>> > Hello,
>> >
>> > I'm unable to change the content of "Description" field on Trac. I
>> > read https://devel.rtems.org/wiki/TracTickets and couldn't find any
>> > luck. I read a thread on Trac's mailing list
>> > (https://lists.gt.net/trac/users/46376). Perhaps, it has to do
>> > something with TICKET_EDIT_DESCRIPTION permissions. How do I go about
>> > doing this? What is it that I'm missing?
>> >
>> If you're logged in then you should see a small link "Modify ↓" just
>> above the ticket box.
>>
>> > Regards,
>> > Tanu Hari Dixit.
>> >
>> > On Wed, Feb 1, 2017 at 9:25 AM, Tanu Hari Dixit 
>> > wrote:
>> >>> * You removed the "Introduction" section. Any reason or just an
>> >>> oversight?
>> >>> * The 'status' field is gone too. But, I think the status is not
>> >>> needed in the ticket format.
>> >>
>> >> I removed the "Introduction" section by mistake. I'll include it.
>> >>
>> >>>
>> >>> Did you face any difficulties in making the transition? It would be
>> >>> good to document your workflow on the Open Projects page.
>> >>
>> >> I wikiformatted the text myself. But it would have been better if I
>> >> had just copied the already formatted text that pops up when we try to
>> >> edit the project page
>> >>
>> >> (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP?action=edit).
>> >> No difficulties as such. I'll document the workflow on the open
>> >> projects page.
>> >>
>> >>> We should convert all of the open projects to tickets eventually. And
>> >>> then generate a report in the Open Projects page based on the tickets.
>> >>> I have done this for the BSP ones and found the following changes
>> >>> should be made in the workflow:
>> >>
>> >> Could you please direct me to the tickets you created? I couldn't find
>> >> them on Trac.
>> >>
>> >>
>> >>> I knew I had bought at least one so went to Amazon to see what we
>> >>> have here at OAR.
>> >>>
>> >>>
>> >>> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A
>> >>>
>> >>> Other folks in the community may have alternatives. It is a pretty
>> >>> generic
>> >>> piece of hardware. But there was that issue with the FTDI driver
>> >>> refusing
>> >>> to work with cloned FTDI chips. So I would bet there are some out
>> >>> there
>> >>> you don't want.
>> >>
>> >> I'll include the above hyperlink.
>> >>
>> >> Thanks,
>> >> Tanu Hari Dixit.
>> >>
>> >> On Wed, Feb 1, 2017 at 4:33 AM, Joel Sherrill  wrote:
>> >>>
>> >>>
>> >>> On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom 
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit
>> >>>> 
>> >>>> wrote:
>> >>>> > Hello,
>> >>>> > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines
>> >>>> > of
>> >>>> > Gedare's advice for this open project
>> >>>> >
>> >>>> > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP).
>> >>>> Looks nice, a few minor things:
>> >>>> * You removed the "Introduction" section. Any reason or just an
>> >>>> oversight?
>> >>>> * The 'status' field is gone too. But, I think the status is not
>> >>>&

Re: GSoC Mentors / Projects of Interest

2017-01-31 Thread Tanu Hari Dixit

Hello,

I'm unable to change the content of "Description" field on Trac. I
read https://devel.rtems.org/wiki/TracTickets and couldn't find any
luck. I read a thread on Trac's mailing list
(https://lists.gt.net/trac/users/46376). Perhaps, it has to do
something with TICKET_EDIT_DESCRIPTION permissions. How do I go about
doing this? What is it that I'm missing?

Regards,
Tanu Hari Dixit.

On Wed, Feb 1, 2017 at 9:25 AM, Tanu Hari Dixit  wrote:
>> * You removed the "Introduction" section. Any reason or just an oversight?
>> * The 'status' field is gone too. But, I think the status is not
>> needed in the ticket format.
>
> I removed the "Introduction" section by mistake. I'll include it.
>
>>
>> Did you face any difficulties in making the transition? It would be
>> good to document your workflow on the Open Projects page.
>
> I wikiformatted the text myself. But it would have been better if I
> had just copied the already formatted text that pops up when we try to
> edit the project page
> (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP?action=edit).
> No difficulties as such. I'll document the workflow on the open
> projects page.
>
>> We should convert all of the open projects to tickets eventually. And
>> then generate a report in the Open Projects page based on the tickets.
>> I have done this for the BSP ones and found the following changes
>> should be made in the workflow:
>
> Could you please direct me to the tickets you created? I couldn't find
> them on Trac.
>
>
>> I knew I had bought at least one so went to Amazon to see what we
>> have here at OAR.
>>
>> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A
>>
>> Other folks in the community may have alternatives. It is a pretty generic
>> piece of hardware. But there was that issue with the FTDI driver refusing
>> to work with cloned FTDI chips. So I would bet there are some out there
>> you don't want.
>
> I'll include the above hyperlink.
>
> Thanks,
> Tanu Hari Dixit.
>
> On Wed, Feb 1, 2017 at 4:33 AM, Joel Sherrill  wrote:
>>
>>
>> On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom  wrote:
>>>
>>> On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit 
>>> wrote:
>>> > Hello,
>>> > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of
>>> > Gedare's advice for this open project
>>> > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP).
>>> Looks nice, a few minor things:
>>> * You removed the "Introduction" section. Any reason or just an oversight?
>>> * The 'status' field is gone too. But, I think the status is not
>>> needed in the ticket format.
>>>
>>> Did you face any difficulties in making the transition? It would be
>>> good to document your workflow on the Open Projects page.
>>>
>>> > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is
>>> > probably broken. What should I replace it with? Please tell if some
>>> See if you can find something appropriate on Google?
>>>
>>
>> I knew I had bought at least one so went to Amazon to see what we
>> have here at OAR.
>>
>> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A
>>
>> Other folks in the community may have alternatives. It is a pretty generic
>> piece of hardware. But there was that issue with the FTDI driver refusing
>> to work with cloned FTDI chips. So I would bet there are some out there
>> you don't want.
>>
>>>
>>> > edit is needed and whether I should follow this pattern. Furthermore,
>>> > please indicate whether this project is of interest. Also which other
>>> > open projects should be converted to tickets?
>>> >
>>> We should convert all of the open projects to tickets eventually. And
>>> then generate a report in the Open Projects page based on the tickets.
>>> I have done this for the BSP ones and found the following changes
>>> should be made in the workflow:
>>> * Use only one keyword. I prefer "SoC" so it is generic to other
>>> 'summer of code' style projects.
>>> * Use the components field to further categorize. We have some obvious
>>> ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'.
>>> Others should be identified or else we can create new components if
>>> necessary.

Re: GSoC Mentors / Projects of Interest

2017-01-31 Thread Tanu Hari Dixit

> * You removed the "Introduction" section. Any reason or just an oversight?
> * The 'status' field is gone too. But, I think the status is not
> needed in the ticket format.

I removed the "Introduction" section by mistake. I'll include it.

>
> Did you face any difficulties in making the transition? It would be
> good to document your workflow on the Open Projects page.

I wikiformatted the text myself. But it would have been better if I
had just copied the already formatted text that pops up when we try to
edit the project page
(https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP?action=edit).
No difficulties as such. I'll document the workflow on the open
projects page.

> We should convert all of the open projects to tickets eventually. And
> then generate a report in the Open Projects page based on the tickets.
> I have done this for the BSP ones and found the following changes
> should be made in the workflow:

Could you please direct me to the tickets you created? I couldn't find
them on Trac.


> I knew I had bought at least one so went to Amazon to see what we
> have here at OAR.
>
> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A
>
> Other folks in the community may have alternatives. It is a pretty generic
> piece of hardware. But there was that issue with the FTDI driver refusing
> to work with cloned FTDI chips. So I would bet there are some out there
> you don't want.

I'll include the above hyperlink.

Thanks,
Tanu Hari Dixit.

On Wed, Feb 1, 2017 at 4:33 AM, Joel Sherrill  wrote:
>
>
> On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom  wrote:
>>
>> On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit 
>> wrote:
>> > Hello,
>> > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of
>> > Gedare's advice for this open project
>> > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP).
>> Looks nice, a few minor things:
>> * You removed the "Introduction" section. Any reason or just an oversight?
>> * The 'status' field is gone too. But, I think the status is not
>> needed in the ticket format.
>>
>> Did you face any difficulties in making the transition? It would be
>> good to document your workflow on the Open Projects page.
>>
>> > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is
>> > probably broken. What should I replace it with? Please tell if some
>> See if you can find something appropriate on Google?
>>
>
> I knew I had bought at least one so went to Amazon to see what we
> have here at OAR.
>
> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A
>
> Other folks in the community may have alternatives. It is a pretty generic
> piece of hardware. But there was that issue with the FTDI driver refusing
> to work with cloned FTDI chips. So I would bet there are some out there
> you don't want.
>
>>
>> > edit is needed and whether I should follow this pattern. Furthermore,
>> > please indicate whether this project is of interest. Also which other
>> > open projects should be converted to tickets?
>> >
>> We should convert all of the open projects to tickets eventually. And
>> then generate a report in the Open Projects page based on the tickets.
>> I have done this for the BSP ones and found the following changes
>> should be made in the workflow:
>> * Use only one keyword. I prefer "SoC" so it is generic to other
>> 'summer of code' style projects.
>> * Use the components field to further categorize. We have some obvious
>> ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'.
>> Others should be identified or else we can create new components if
>> necessary. I'd like to stick with the current subheadings for this
>> year's GSoC, but we can revise later.
>>
>> > Probably the community is interested in the idea to create simple
>> > examples or sanity tests for all RTEMS directives so that they can be
>> > included in the documentation (something that is user friendly). Also,
>> > there was a thread titled 'Desirable Application Stacks (Add-On
>> > Library Collections)' . Which ideas can be derived from there?
>> >
>> > Regards,
>> > Tanu Hari Dixit.
>> >
>> > On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill  wrote:
>> >>
>> >>
>> >> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom  wrote:
>> >>>
>> >>> On Mon, Ja

Re: Regarding a beginner friendly bug

2017-01-31 Thread Tanu Hari Dixit

Thank you. I'll look into it.

Regards,
Tanu Hari Dixit.

On Tue, Jan 31, 2017 at 11:50 PM, Kuan Hsun Chen
 wrote:
> Hi,
>
> You can search by yourself on this website: https://devel.rtems.org/query
> After you fix a bug and test your revision comprehensively, you can send-out
> the patch to this mailing list.
>
> Best,
> Kuan-Hsun
>
> 2017-01-31 19:15 GMT+01:00 Tanu Hari Dixit :
>>
>> Hello all,
>> Is there a beginner friendly bug that I can be assigned? I would like
>> to get involved and learn more about RTEMS.
>> Thank you.
>> Regards,
>> Tanu Hari Dixit
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
>
> --
> M.Sc. Kuan-Hsun Chen
>
> TU Dortmund
> Department of Computer Science 12
> Design Automation of Embedded Systems
> Otto-Hahn-Strasse 16, Room 102
>
> 44227 Dortmund
> Germany
>
> Phone:  +49 231 755 6124
> Mail:   kuan-hsun.c...@tu-dortmund.de
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Regarding a beginner friendly bug

2017-01-31 Thread Tanu Hari Dixit

Hello all,
Is there a beginner friendly bug that I can be assigned? I would like
to get involved and learn more about RTEMS.
Thank you.
Regards,
Tanu Hari Dixit
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Mentors / Projects of Interest

2017-01-31 Thread Tanu Hari Dixit

Hello,
I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of
Gedare's advice for this open project
(https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP).
The link to buy USB-TTL FTDI Cable 3.3V on the open project page is
probably broken. What should I replace it with? Please tell if some
edit is needed and whether I should follow this pattern. Furthermore,
please indicate whether this project is of interest. Also which other
open projects should be converted to tickets?

Probably the community is interested in the idea to create simple
examples or sanity tests for all RTEMS directives so that they can be
included in the documentation (something that is user friendly). Also,
there was a thread titled 'Desirable Application Stacks (Add-On
Library Collections)' . Which ideas can be derived from there?

Regards,
Tanu Hari Dixit.

On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill  wrote:
>
>
> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom  wrote:
>>
>> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit 
>> wrote:
>> > I'll be glad to do it. Please guide me as to how to proceed.
>> >
>> We will need to import each existing Open Project description into a
>> new ticket. It would be best to start with one to "try it out". The
>> project title should be the Summary of the ticket, the text of the
>> project page should be converted into the Description of the ticket,
>> type should be Enhancement, Milestone "Indefinite", and put GSoC into
>> the keywords, and we might want to use some other keywords e.g. to
>> define the project type (e.g. one of: testing, ecosystem, kernel,
>> statistics, BSP, API, libbsd, languages, libraries). The owner should
>> be assigned to one of the mentors if indicated, with others in CC if
>> any, or else set blank.
>>
>
> I agree it would be nice to get all the Open Project ideas as tickets and
> off the Wiki. Some of the ideas are likely no longer interesting/valid at
> this point and could just be deleted.
>
> FWIW I also want to move some of the Wiki content into Sphinx documents.
> I think being able to release them with RTEMS branches and use git
> for revision control.
>
> --joel
>
>>
>> > On Mon, Jan 30, 2017 at 9:38 PM, Gedare Bloom  wrote:
>> >>
>> >> Yes that would be much nicer. Maybe we can get potential GSoC Students
>> >> to do the work ;)
>> >>
>> >> On Mon, Jan 30, 2017 at 1:40 AM, Sebastian Huber
>> >>  wrote:
>> >> > Maybe we should move all this open projects wiki stuff into tickets
>> >> > with
>> >> > some sort of "GSoC" tag.
>> >> >
>> >> > --
>> >> > Sebastian Huber, embedded brains GmbH
>> >> >
>> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> > Phone   : +49 89 189 47 41-16
>> >> > Fax : +49 89 189 47 41-09
>> >> > E-Mail  : sebastian.hu...@embedded-brains.de
>> >> > PGP : Public key available on request.
>> >> >
>> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >> >
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Mentors / Projects of Interest

2017-01-30 Thread Tanu Hari Dixit

I'll be glad to do it. Please guide me as to how to proceed.

On Mon, Jan 30, 2017 at 9:38 PM, Gedare Bloom  wrote:

> Yes that would be much nicer. Maybe we can get potential GSoC Students
> to do the work ;)
>
> On Mon, Jan 30, 2017 at 1:40 AM, Sebastian Huber
>  wrote:
> > Maybe we should move all this open projects wiki stuff into tickets with
> > some sort of "GSoC" tag.
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help with RTEMS C User’s Guide

2017-01-24 Thread Tanu Hari Dixit

Hey,
Thank you for replying. Yes, the sample applications run (hello world and
ticker as given on https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start).

Regards,
Tanu Hari Dixit.

On Tue, Jan 24, 2017 at 4:06 PM, Laurent Navet 
wrote:

> Hi
> > I have made a file with the first example of printing object names (
> > https://docs.rtems.org/doc-current/share/rtems/html/c_
> > user/Key-Concepts-Object-Names.html#Key-Concepts-Object-Names) and i use
> > the following command to use sparc-rtems4.12-gcc to compile this program
> >
> > sparc-rtems4.12-gcc --pipe -B/home/thd/development/rtems/
> > src/builds/erc32_1/sparc-rtems4.12/erc32/lib -specs bsp_specs -qrtems
> -Wall
> > -g -O2 -o rtems_object_try rtems_object_try.c
> >
> > but when i do ./rtems_object_try I get:
> > ./rtems_object_try: Invalid argument
>
> Do you try to run an executable compiled for sparc architecture on
> your developement machine ?
>
> --
> « On ne résout pas un problème avec les modes de pensée qui l’ont
> engendré. »
> « We cannot solve our problems with the same thinking we used when we
> created them. »
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Help with RTEMS C User’s Guide

2017-01-23 Thread Tanu Hari Dixit

Hello Devs,

I have been trying to setup a makefile so as to execute the various code
snippets given in the C User's guide for RTEMS (https://docs.rtems.org/doc-
current/share/rtems/html/c_user/index.html#SEC_Contents) and have failed
miserably. Can you please help me with this?

I have made a file with the first example of printing object names (
https://docs.rtems.org/doc-current/share/rtems/html/c_
user/Key-Concepts-Object-Names.html#Key-Concepts-Object-Names) and i use
the following command to use sparc-rtems4.12-gcc to compile this program

sparc-rtems4.12-gcc --pipe -B/home/thd/development/rtems/
src/builds/erc32_1/sparc-rtems4.12/erc32/lib -specs bsp_specs -qrtems -Wall
-g -O2 -o rtems_object_try rtems_object_try.c

but when i do ./rtems_object_try I get:

./rtems_object_try: Invalid argument

I narrowed in on the above compiler command by reading the makefile as
given here(https://github.com/alanc98/rki/blob/master/Makefile).

What is it that I am missing?

Also is it necessary to use sparc-rtems4.12-gcc and not the gcc available
to me normally on my machine. When I use gcc,
I get the following error:


thd@thd-Inspiron-5537:~/development/rtems/src/programs/rtems_object$ gcc
--pipe 
-B/home/thd/development/rtems/src/builds/erc32_1/sparc-rtems4.12/erc32/lib
-specs bsp_specs -qrtems -Wall -g -O2 -o rtems_object_try
rtems_object_try.c
In file included from /home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems/score/object.h:26:0,
 from /home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems/score/thread.h:30,
 from /home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems/score/heap.h:22,
 from /home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems/rtems/types.h:26,
 from /home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems.h:31,
 from rtems_object_try.c:1:
/home/thd/development/rtems/src/builds/erc32_1/sparc-
rtems4.12/erc32/lib/include/rtems/score/rbtree.h:21:22: fatal error:
sys/tree.h: No such file or directory
 #include 
  ^
compilation terminated.



I am not able to understand what is wrong. It would be great if you could
point that out.
Thank you,
Tanu Hari Dixit.
#include 
#include 

void print_main(rtems_id id)
{
char buffer[10];
char *result;
result = rtems_object_get_name( id, sizeof(buffer), buffer);
printk( "ID=0x%08lx name=%s\n", id, ((result)? result: "no name"));
}

int main()
{
print_main(1);
}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Changed hello world example to include my name

2016-12-20 Thread Tanu Hari Dixit

Hello Gedare,

I am looking forward to contributing to RTEMS!

Regards,
Tanu Hari Dixit


On Wed, Dec 21, 2016 at 2:35 AM, Gedare Bloom  wrote:
> Thank you, we look forward to your contributions!
>
> On Sat, Dec 17, 2016 at 7:38 PM, Tanu Hari Dixit  
> wrote:
>> Hello all,
>>
>> Please find the screenshot attached.
>>
>> Tanu Hari Dixit.
>>
>> On Sun, Dec 18, 2016 at 6:03 AM, tokencolour  wrote:
>>> This is something I tried after reading
>>> https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS
>>> ---
>>>  testsuites/samples/hello/init.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/testsuites/samples/hello/init.c 
>>> b/testsuites/samples/hello/init.c
>>> index a2d6c30..8fe9a6f 100644
>>> --- a/testsuites/samples/hello/init.c
>>> +++ b/testsuites/samples/hello/init.c
>>> @@ -31,7 +31,11 @@ rtems_task Init(
>>>  {
>>>rtems_print_printer_printf(&rtems_test_printer);
>>>rtems_test_begin();
>>> -  printf( "Hello World\n" );
>>> +  //printf( "Hello World\n" );
>>> +  printf( "\n\n*** GSOC HELLO WORLD TEST ***\n" );
>>> +  printf( "This is Tanu's Hello World\n" );
>>> +  printf( "Welcome to RTEMS and Google Summer of Code 2017\n" );
>>> +  printf( "*** END OF GSOC HELLO WORLD TEST ***\n" );
>>>rtems_test_end();
>>>exit( 0 );
>>>  }
>>> --
>>> 1.9.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

Re: Regarding modified hello world example

2016-12-17 Thread Tanu Hari Dixit

I forgot to ask another important question-
Which of the above projects would require me to have actual hardware?

Thank you,
Tanu Hari Dixit.

On Sun, Dec 18, 2016 at 5:52 AM, Tanu Hari Dixit  wrote:
> Hello Joel,
>
> Thank you for your reply.
>
>> Congratulations on getting it working. Please post your diff to hello world
>> and a screenshot.
>
> I'll post the diff and the screenshot ASAP.
>
>>
>> What host OS are you using?
>>
>
> I'm working on Linux Ubuntu 14.04 LTS.
>
>> What type of project are you interested in doing? Depending on the project,
>> you may have to move to another BSP which has a simulator with same
>> networking or graphics support. Or you may need to be on actual hardware.
>> We can guide you through BSP selection after we know what you want to do.
>>
>
> I went through https://devel.rtems.org/wiki/Developer/OpenProjects and
> I am interested in contributing to the following projects in
> decreasing order of preference :
>
> # Implementing MMU low-level support code for more BSPs.
> *Work Package flow as given at
> https://devel.rtems.org/wiki/Projects/MMU_Support#TheWorkpackageFlow
> *Mid Level APIs as given at
> https://devel.rtems.org/wiki/Projects/MMU_Support#MidLevelAPIs
> *Are these already implemented? Can you please provide me pointers
> on the current status?
>
> # Testing by Fault injection
> * I found http://rtems-fi.blogspot.in/ and I browsed through
> https://github.com/salpha2004/slingshot
> * I guess these
> (https://devel.rtems.org/wiki/SOCIS/2016#FutureWorks) are the things
> left to be done.
>
> # RISC-V related work
> *I did not find it listed on the Open Projects page. Is there some
> work already done on this front?
>
> # RTEMS Scikit
> *The project page says it is uninitiated. Is this still true?
> *Is this exactly about scientific applications that will run on
> RTEMS? What exactly has to be done?
>
> # Python GDB Support
> *The page (https://devel.rtems.org/wiki/Projects/GDB_Python) says
> that this project is under heavy development.  Is this still true?
>
> Which of these projects will be best suitable for me? Could you please
> provide me with some beginner friendly tasks in relation to these
> projects? My plan is to get comfortable with RTEMS and perhaps its
> software architecture (whenever required) and contribute something to
> it. This will help me make a decent GSoC effort, when the time comes.
>
>> Disclaimer: No organizations have applied to GSOC and there is no guarantee
>> we will be accepted. :)
>
> I understand.
>
>>
>> --joel
>
> Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Changed hello world example to include my name

2016-12-17 Thread Tanu Hari Dixit

Hello all,

Please find the screenshot attached.

Tanu Hari Dixit.

On Sun, Dec 18, 2016 at 6:03 AM, tokencolour  wrote:
> This is something I tried after reading
> https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS
> ---
>  testsuites/samples/hello/init.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
> index a2d6c30..8fe9a6f 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -31,7 +31,11 @@ rtems_task Init(
>  {
>rtems_print_printer_printf(&rtems_test_printer);
>rtems_test_begin();
> -  printf( "Hello World\n" );
> +  //printf( "Hello World\n" );
> +  printf( "\n\n*** GSOC HELLO WORLD TEST ***\n" );
> +  printf( "This is Tanu's Hello World\n" );
> +  printf( "Welcome to RTEMS and Google Summer of Code 2017\n" );
> +  printf( "*** END OF GSOC HELLO WORLD TEST ***\n" );
>rtems_test_end();
>exit( 0 );
>  }
> --
> 1.9.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding modified hello world example

2016-12-17 Thread Tanu Hari Dixit

Hello Joel,

Thank you for your reply.

> Congratulations on getting it working. Please post your diff to hello world
> and a screenshot.

I'll post the diff and the screenshot ASAP.

>
> What host OS are you using?
>

I'm working on Linux Ubuntu 14.04 LTS.

> What type of project are you interested in doing? Depending on the project,
> you may have to move to another BSP which has a simulator with same
> networking or graphics support. Or you may need to be on actual hardware.
> We can guide you through BSP selection after we know what you want to do.
>

I went through https://devel.rtems.org/wiki/Developer/OpenProjects and
I am interested in contributing to the following projects in
decreasing order of preference :

# Implementing MMU low-level support code for more BSPs.
*Work Package flow as given at
https://devel.rtems.org/wiki/Projects/MMU_Support#TheWorkpackageFlow
*Mid Level APIs as given at
https://devel.rtems.org/wiki/Projects/MMU_Support#MidLevelAPIs
*Are these already implemented? Can you please provide me pointers
on the current status?

# Testing by Fault injection
* I found http://rtems-fi.blogspot.in/ and I browsed through
https://github.com/salpha2004/slingshot
* I guess these
(https://devel.rtems.org/wiki/SOCIS/2016#FutureWorks) are the things
left to be done.

# RISC-V related work
*I did not find it listed on the Open Projects page. Is there some
work already done on this front?

# RTEMS Scikit
*The project page says it is uninitiated. Is this still true?
*Is this exactly about scientific applications that will run on
RTEMS? What exactly has to be done?

# Python GDB Support
*The page (https://devel.rtems.org/wiki/Projects/GDB_Python) says
that this project is under heavy development.  Is this still true?

Which of these projects will be best suitable for me? Could you please
provide me with some beginner friendly tasks in relation to these
projects? My plan is to get comfortable with RTEMS and perhaps its
software architecture (whenever required) and contribute something to
it. This will help me make a decent GSoC effort, when the time comes.

> Disclaimer: No organizations have applied to GSOC and there is no guarantee
> we will be accepted. :)

I understand.

>
> --joel

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

Regarding modified hello world example

2016-12-15 Thread Tanu Hari Dixit

Hello Devs,

Kindly advise me whether I need to send a patch with a modified hello
world example as given in
https://devel.rtems.org/wiki/GSoC/GettingStarted#ProveYouCanWorkOnRTEMS.
Furthermore, I wanted to ask, is there a new set of documentation that
I should be aware of, other than that hosted at
https://devel.rtems.org/ ?
I aim to participate in GSoC '17 under RTEMS. How should I proceed
now, that I have set up RTEMS ?
Also, when I modified testsuites/samples/hello/init.c, the following
m4 files also got modified:

  c/src/lib/libbsp/bfin/acinclude.m4
  c/src/lib/libbsp/powerpc/acinclude.m4

in the following way,

diff --git a/c/src/lib/libbsp/bfin/acinclude.m4 b/c/src/lib/libbsp/bfin/acinclud
index ab6082e..828fd89 100644
--- a/c/src/lib/libbsp/bfin/acinclude.m4
+++ b/c/src/lib/libbsp/bfin/acinclude.m4
@@ -2,12 +2,12 @@
 AC_DEFUN([RTEMS_CHECK_BSPDIR],
 [
   case "$1" in
-  TLL6527M )
-AC_CONFIG_SUBDIRS([TLL6527M]);;
   bf537Stamp )
 AC_CONFIG_SUBDIRS([bf537Stamp]);;
   eZKit533 )
 AC_CONFIG_SUBDIRS([eZKit533]);;
+  TLL6527M )
+AC_CONFIG_SUBDIRS([TLL6527M]);;
   *)
 AC_MSG_ERROR([Invalid BSP]);;
   esac
diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 b/c/src/lib/libbsp/powerpc/ac
index 4c83475..edc67b5 100644
--- a/c/src/lib/libbsp/powerpc/acinclude.m4
+++ b/c/src/lib/libbsp/powerpc/acinclude.m4
@@ -32,12 +32,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR],
 AC_CONFIG_SUBDIRS([t32mppc]);;
   tqm8xx )
 AC_CONFIG_SUBDIRS([tqm8xx]);;
-  virtex )
-AC_CONFIG_SUBDIRS([virtex]);;
   virtex4 )
 AC_CONFIG_SUBDIRS([virtex4]);;
   virtex5 )
 AC_CONFIG_SUBDIRS([virtex5]);;
+  virtex )
+AC_CONFIG_SUBDIRS([virtex]);;
   *)
 AC_MSG_ERROR([Invalid BSP]);;
   esac

Should I be worried about these? Why did the order of the subdir change here?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help with RTEMS

2016-12-13 Thread Tanu Hari Dixit

Chris, Martin and Jennifer,

Thanks for helping me out with this.
I tried with erc32 BSP and I can finally see the executables in
/development/rtems/src/builds/erc32/sparc-rtems4.12/c/erc32/testsuites/samples.
I also ran all tests with
/development/rtems/4.12/bin$ rtems-test --rtems-bsp=erc32
--report-mode=all `find ../../ -name *.exe`
and all the tests passed.

Tanu Hari Dixit

On Wed, Dec 14, 2016 at 5:21 AM, Chris Johns  wrote:
> [ Please do not cross post ]
>
> On 14/12/2016 09:32, Martin Werner wrote:
>>
>> This seems to be because the sparc/sis BSP is removed in the latest
>> master (as of a month ago: de7b174).
>
>
> Yes the sis BSP has been removed from master (4.12).
>
>> For sparc you need to pick one of the other available BSPs, currently
>> erc32 leon2 leon3 or ngmp.
>
>
> I am testing with erc32 and after a build with --enable-tests I use the
> following:
>
> $ /opt/work/rtems/4.12/bin/rtems-test --rtems-bsp=erc32 \
> --report-mode=all `find . -name dl05.exe`
>
> If I wish to run a number of tests I can:
>
> $ /opt/work/rtems/4.12/bin/rtems-test --rtems-bsp=erc32 \
>`find sparc-rtems4.12/c/erc32/testsuites/libtests -name \dl*.exe`
> RTEMS Testing - Tester, 4.12.not_released
>  Command Line: /opt/work/rtems/4.12/bin/rtems-test --rtems-bsp=erc32
> sparc-rtems4.12/c/erc32/testsuites/libtests/dl02/dl02.exe
> sparc-rtems4.12/c/erc32/testsuites/libtests/dl05/dl05.exe
> sparc-rtems4.12/c/erc32/testsuites/libtests/dl01/dl01.exe
> sparc-rtems4.12/c/erc32/testsuites/libtests/dl04/dl04.exe
> sparc-rtems4.12/c/erc32/testsuites/libtests/dl03/dl03.exe
>  Python: 2.7.12 (default, Sep 27 2016, 01:49:05) [GCC 4.2.1 Compatible
> FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)]
> [1/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl01.exe
> [2/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl02.exe
> [4/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl04.exe
> [3/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl03.exe
> [5/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl05.exe
> [1/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl01.exe
> [2/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl02.exe
> [3/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl03.exe
> [4/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl04.exe
> [5/5] p:0 f:0 t:0 i:0 | sparc/erc32: dl05.exe
>
> Passed:   5
> Failed:   0
> Timeouts: 0
> Invalid:  0
> ---
> Total:5
>
> Average test time: 0:00:00.521724
> Testing time : 0:00:02.608620
>
> Note, all tests have passed.
>
> This approach lets you use the same mechanism for all bsps, for example if
> you are using the PowerPC Simulator (psim) you can run:
>
> $ /opt/work/rtems/4.12/bin/rtems-test --rtems-bsp=psim \
>--report-mode=all `find . -name dl05.exe`
>
>>
>> The examples in the getting started guide should probably be updated.
>>
>
> The doco is being slowly moved to the User Manual.
>
> Chris
> ___
> users mailing list
> us...@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help with RTEMS

2016-12-13 Thread Tanu Hari Dixit

velopment/rtems/src/b-sis/tools/cpu'
Making install in generic
make[2]: Entering directory
`/home/thd/development/rtems/src/b-sis/tools/cpu/generic'
make[3]: Entering directory
`/home/thd/development/rtems/src/b-sis/tools/cpu/generic'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/thd/development/rtems/src/b-sis/tools/cpu/generic'
make[2]: Leaving directory
`/home/thd/development/rtems/src/b-sis/tools/cpu/generic'
make[2]: Entering directory `/home/thd/development/rtems/src/b-sis/tools/cpu'
make[3]: Entering directory `/home/thd/development/rtems/src/b-sis/tools/cpu'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/thd/development/rtems/src/b-sis/tools/cpu'
make[2]: Leaving directory `/home/thd/development/rtems/src/b-sis/tools/cpu'
make[1]: Leaving directory `/home/thd/development/rtems/src/b-sis/tools/cpu'
Making install in testsuites/tools
make[1]: Entering directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
Making install in generic
make[2]: Entering directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools/generic'
make[3]: Entering directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools/generic'
 /bin/mkdir -p '/home/thd/install_path/bin'
 /usr/bin/install -c difftest
'/home/thd/install_path/bin/./sparc-rtems4.12-difftest'
 /usr/bin/install -c sorttimes
'/home/thd/install_path/bin/./sparc-rtems4.12-sorttimes'
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools/generic'
make[2]: Leaving directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools/generic'
make[2]: Entering directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
make[3]: Entering directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
make[2]: Leaving directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
make[1]: Leaving directory
`/home/thd/development/rtems/src/b-sis/testsuites/tools'
Making install in sparc-rtems4.12/c
make[1]: Entering directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
Making install in .
make[2]: Entering directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
make[3]: Entering directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
make[2]: Leaving directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
make[1]: Leaving directory
`/home/thd/development/rtems/src/b-sis/sparc-rtems4.12/c'
make[1]: Entering directory `/home/thd/development/rtems/src/b-sis'
make[2]: Entering directory `/home/thd/development/rtems/src/b-sis'
make[2]: Nothing to be done for `install-exec-am'.
 /bin/mkdir -p '/home/thd/install_path/make'
 /usr/bin/install -c -m 644 ../rtems/make/main.cfg
../rtems/make/leaf.cfg '/home/thd/install_path/make'
 /bin/mkdir -p '/home/thd/install_path/share/rtems4.12/make/Templates'
 /usr/bin/install -c -m 644 ../rtems/make/Templates/Makefile.dir
../rtems/make/Templates/Makefile.leaf
../rtems/make/Templates/Makefile.lib
'/home/thd/install_path/share/rtems4.12/make/Templates'
 /bin/mkdir -p '/home/thd/install_path/make/custom'
 /usr/bin/install -c -m 644 ../rtems/make/custom/default.cfg
'/home/thd/install_path/make/custom'
make[2]: Leaving directory `/home/thd/development/rtems/src/b-sis'
make[1]: Leaving directory `/home/thd/development/rtems/src/b-sis'

On Wed, Dec 14, 2016 at 12:29 AM, Jennifer Averett
 wrote:
> This isn't showing it building samples.  Either it thinks its already done
> in which case if you do "find . -name ticker.exe" from the generic directory
> you will see the executable.  If it isn't there do a "make clean" and then a 
> make
> and let me see those results.  The make file should show it building
> the exe's in samples.  Its been a while since I did a rtems build so
> I'm probably missing something obvious.
>
> Jennifer Averett
> On-Line Applications Research
> 
> From: Tanu Hari Dixit [tokencol...@gmail.com]
> Sent: Tuesday, December 13, 2016 12:47 PM
> To: Jennifer Averett
> Subject: Re: Help with RTEMS
>
> Hey Jennifer,
> Thanks f

Re: Help with RTEMS

2016-12-13 Thread Tanu Hari Dixit

-rtemsbsp=sis' '--enable-tests=samples'
'--target=sparc-rtems4.12' 'build_alias=x86_64-pc-linux-gnu'
'host_alias=x86_64-pc-linux-gnu' 'target_alias=sparc-rtems4.12'
--cache-file=/dev/null --srcdir=../../../../rtems/tools/cpu/generic
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for bash... /bin/bash
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating size_rtems
configure: configuring in ./testsuites/tools
configure: running /bin/bash
'../../../rtems/testsuites/tools/configure'
'--prefix=/home/thd/install_path' '--host=x86_64-pc-linux-gnu'
'--build=x86_64-pc-linux-gnu'  '--enable-rtemsbsp=sis'
'--enable-tests=samples' '--target=sparc-rtems4.12'
'--cache-file=/dev/null' '--srcdir=../../../rtems/testsuites/tools'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
=== configuring in generic
(/home/thd/development/rtems/src/b-sis/testsuites/tools/generic)
configure: running /bin/bash
../../../../rtems/testsuites/tools/generic/configure
--disable-option-checking '--prefix=/home/thd/install_path'
'--host=x86_64-pc-linux-gnu' '--build=x86_64-pc-linux-gnu'
'--enable-rtemsbsp=sis' '--enable-tests=samples'
'--target=sparc-rtems4.12' 'build_alias=x86_64-pc-linux-gnu'
'host_alias=x86_64-pc-linux-gnu' 'target_alias=sparc-rtems4.12'
--cache-file=/dev/null
--srcdir=../../../../rtems/testsuites/tools/generic
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for bash... /bin/bash
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating difftest
config.status: creating sorttimes
configure: configuring in sparc-rtems4.12/c
configure: running /bin/bash '../../../rtems/c/configure'
'--prefix=/home/thd/install_path' '--host=sparc-rtems4.12'
'--build=x86_64-pc-linux-gnu' '--target=sparc-rtems4.12'
'--enable-rtemsbsp=sis' '--enable-tests=samples'
'--with-target-subdir=sparc-rtems4.12'
'--exec-prefix=/home/thd/install_path/sparc-rtems4.12'
'--includedir=/home/thd/install_path/sparc-rtems4.12/include'
'--cache-file=/dev/null' '--srcdir=../../../rtems/c'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 4.11.99.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... sparc-unknown-rtems4.12
checking target system type... sparc-unknown-rtems4.12
checking rtems target cpu... sparc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for sparc-rtems4.12-strip... sparc-rtems4.12-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking that generated files are newer than configure... done
co

Re: Help with RTEMS

2016-12-13 Thread Tanu Hari Dixit

Hey Punit,

Thank you for your reply and pointing to the open projects.
The problem is I don't have "testsuites" folder in
/development/rtems/src/b-sis/sparc-rtems4.12/c. I'm still unable to
find the executables. I can't seem to figure out where the "samples"
folder is located. As I had mentioned in my previous mail, there are
samples in the rtems source directory
(/development/rtems/src/rtems/testsuites/samples/ticker) but I don't
know as to how to specify to test those samples with the configure
command.

Thank you,
Tanu Hari Dixit.

On Tue, Dec 13, 2016 at 7:32 PM, punit vara  wrote:
>
> Hi Tanu,
>
>
> https://github.com/RTEMS/rtems
>
> You can follow any of following open ideas to get contribute :
>
> https://devel.rtems.org/wiki/Developer/OpenProjects
>
>
>
>
>
> On Tue, Dec 13, 2016 at 11:40 AM, Tanu Hari Dixit  
> wrote:
> > Hey Punit,
> >
> > I am Tanu, here. I am an undergraduate student from IIT BHU studying
> > electronics engineering. I wanted to contribute to RTEMS, and in a useful
> > way so that the devs consider me for GSoC '17. I wanted to know how did you
> > fill the gaps when you started with RTOS. I've not even done my bachelor
> > yet, am I too early to start with any real time implementation of an OS? I'm
>
> There is always something we can contribute to open source project.
>
> > facing trouble while finding exe files in the prefix and have mailed on the
> > users list. (I did that yesterday). Can you please help me with it?
> > I have included the mail I sent on the users list:
>
> Its better you ask question on dev list rather than user list.
>
> >
> > Hello Devs!
> >
> > I followed the instructions given in the Getting started guide
> > (https://devel.rtems.org/wiki/GSoC/GettingStarted) and
> > (https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start). The latter
> > says that when I bootstrap and then make and make install, I should
> > find sample executables in a path similar to:
> >
> > "/home2/work/joel/rtems-4.11-work/build/build-sparc-sis-rtems/
> > sparc-rtems4.11/c/sis/testsuites/samples/ticker/ticker.exe"
> >
> That's Joel's directory structure. But I would say you must have
> created directory named b-sis right ?
>
> You can see .exe file in path something like
>
> b-sis/sparc-rtems4.12/c/../testsuites/samples/hello
>
> > I am unable to find exe files in my working directory (not even in the
> > prefix).
> > My tree is the following:
> > /development/rtems/src/b-sis
> > ./
> > |-- sparc-rtems4.12
> > |   `-- c
> > |-- testsuites
> > |   `-- tools
> > |   `-- generic
> > `-- tools
> > |-- build
> > `-- cpu
> > `-- generic
> > and sparc-rtems4.12/c/ has 3 files config.log,  config.status,  Makefile
> > and the directory testsuites(shown in the above tree) has no samples.
> > There are samples in the rtems source directory, though
> > (/development/rtems/src/rtems/testsuites/samples/ticker) but I'm
> > clueless as to how to specify to test those samples. The configure
> > command :
> >
> > /rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=sis \
> >   --enable-tests=samples --prefix=${HOME}/install_path
> >
> > specifies to enable tests on "samples" which I'm unable to find. How
> > do I successfully run a test? Is there a mistake I did while building
> > RTEMS or the RSB? Kindly help me figure this out.
> >
> > Thank you so much!
> > Tanu Hari Dixit,
> > Senior Undergraduate,
> > Department of Electronics Engineering,
> > IIT BHU.
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

69 matches

Mail list logo