[PATCH RSB] Add gdb-8.3 as default debugger

[Jiri Gaisler]

I suggest that we switch to gdb-8.3 for targets that currently use 8.2.1. The 
update is relatively minor but allows building without any patches. Tested for 
SPARC and RISC-V targets.

Jiri.

>From 5b12c03d184d6cea7019636fc134e06d25a94d9f Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Wed, 21 Aug 2019 09:24:51 +0200
Subject: [PATCH] Add gdb-8.3 as default debugger

	* Minor update from 8.2.1
	* Can be built without patches (!)
---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/5/rtems-sparc.bset|  1 +
 rtems/config/tools/rtems-gdb-8.3-1.cfg | 12 
 3 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 rtems/config/tools/rtems-gdb-8.3-1.cfg

diff --git a/rtems/config/5/rtems-default.bset b/rtems/config/5/rtems-default.bset
index e2e4ac0..8640499 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -15,7 +15,7 @@
 #
 
 devel/expat-2.1.0-1
-tools/rtems-gdb-8.2.1-1
+tools/rtems-gdb-8.3-1
 
 tools/rtems-binutils-2.32
 tools/rtems-gcc-fb371a33fa6-newlib-6661a67
diff --git a/rtems/config/5/rtems-sparc.bset b/rtems/config/5/rtems-sparc.bset
index 60bb792..ccb3e10 100644
--- a/rtems/config/5/rtems-sparc.bset
+++ b/rtems/config/5/rtems-sparc.bset
@@ -1,5 +1,6 @@
 %define release 1
 %define rtems_arch sparc
 %define with_libgomp
+%define gdb-disable-sim 1
 %include 5/rtems-default.bset
 devel/sis-2-1
diff --git a/rtems/config/tools/rtems-gdb-8.3-1.cfg b/rtems/config/tools/rtems-gdb-8.3-1.cfg
new file mode 100644
index 000..1577737
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-8.3-1.cfg
@@ -0,0 +1,12 @@
+#
+# GDB 8.3
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 8.3
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz 47ac074d20a09a3fac8f4a41dce0a0cbe6ef702f7dc21ba8b7d650d306128dcae481e9a16bf65e596b3a541dc82ae57c02bcbb786d551b4ef3e2917b9b6f0ae1
+
+%include %{_configdir}/gdb-8-1.cfg
-- 
2.17.1

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

Re: GSoC Project Wrap Up Activities

[Ravindra Kumar Meena]

>
> + GSoC Lightning Slides: I have shared a Google presentation with as some
> of the
>students and mentors. Please add 1-2 slides on your project. The
> presentation
>we are starting from is last year's. The slide deck will be used
> for two purposes:
>  - 3 minute presentation at GSoC Mentor Summit
>  - part of RTEMS State of the World at Flight Software Workshop
> (http://flightsoftware.jhuapl.edu/)
>
Please share the link of Lightning slides. If it need write access then
please grant me the
write access to this file.

>
> + GSoC Project Summary: We usually do a blog/report/news item about GSoC.
>1-3 paragraphs on your project is appreciated for this. I created a
> Google doc
>for this.
>
> I know I missed some mentors and students having permission to the
> files. If you
> don't have access, ping me.
>
Please share the link of this doc. I don't have access to this file.
Please, grant me write access to this file.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project Wrap Up Activities

[Vaibhav Gupta]

On Tue, Aug 20, 2019, 7:45 PM Joel Sherrill  wrote:

> Hi
>
> This has been a fantastic and productive GSoC. As part of wrapping
> things up, we would like to make sure the following get taken care of:
>
> + Make sure all code and documentation is submitted, cleaned up and merged.
>Ping mentors if needed. Focus on reproducibility. Is your work
> documented and
>easily publicly accessible? Can it be rebuilt and tests run without
> issues?
>
> + GSoC Lightning Slides: I have shared a Google presentation with as some
> of the
>students and mentors. Please add 1-2 slides on your project. The
> presentation
>we are starting from is last year's. The slide deck will be used
> for two purposes:
>  - 3 minute presentation at GSoC Mentor Summit
>  - part of RTEMS State of the World at Flight Software Workshop
> (http://flightsoftware.jhuapl.edu/)
>
Hello,
I need the edit access and link to the slides. Thank you

--Vaibhav Gupta

>
> + GSoC Project Summary: We usually do a blog/report/news item about GSoC.
>1-3 paragraphs on your project is appreciated for this. I created a
> Google doc
>for this.
>
> I know I missed some mentors and students having permission to the
> files. If you
> don't have access, ping me.
>
> We do really appreciate the work you all did and the wrap up is to
> ensure the work
> is (1) available and usable and (2) know to the community.
>
> Thanks.
>
> --joel
> ___
> 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 Project Wrap Up Activities

[Joel Sherrill]

https://docs.google.com/document/d/1AhBCmFxOikBG7EBcAaTF7ol_D7SZGn0TJrPcifuVHnE/edit?usp=sharing
is this link and I should have added both of you.

If any mentor or student needs write access, just ask. It is hard to
remember everyone.

--joel

On Wed, Aug 21, 2019 at 3:15 AM Vaibhav Gupta  wrote:
>
>
>
> On Tue, Aug 20, 2019, 7:45 PM Joel Sherrill  wrote:
>>
>> Hi
>>
>> This has been a fantastic and productive GSoC. As part of wrapping
>> things up, we would like to make sure the following get taken care of:
>>
>> + Make sure all code and documentation is submitted, cleaned up and merged.
>>Ping mentors if needed. Focus on reproducibility. Is your work documented 
>> and
>>easily publicly accessible? Can it be rebuilt and tests run without 
>> issues?
>>
>> + GSoC Lightning Slides: I have shared a Google presentation with as some of 
>> the
>>students and mentors. Please add 1-2 slides on your project. The 
>> presentation
>>we are starting from is last year's. The slide deck will be used
>> for two purposes:
>>  - 3 minute presentation at GSoC Mentor Summit
>>  - part of RTEMS State of the World at Flight Software Workshop
>> (http://flightsoftware.jhuapl.edu/)
>
> Hello,
> I need the edit access and link to the slides. Thank you
>
> --Vaibhav Gupta
>>
>>
>> + GSoC Project Summary: We usually do a blog/report/news item about GSoC.
>>1-3 paragraphs on your project is appreciated for this. I created a
>> Google doc
>>for this.
>>
>> I know I missed some mentors and students having permission to the
>> files. If you
>> don't have access, ping me.
>>
>> We do really appreciate the work you all did and the wrap up is to
>> ensure the work
>> is (1) available and usable and (2) know to the community.
>>
>> Thanks.
>>
>> --joel
>> ___
>> 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: Added support for MX Linux

[Himanshu Sekhar Nayak]

I pulled out the latest commit to my repo and didn't see my commit yet. btw
what should I do next ?

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

Re: Added support for MX Linux

[Joel Sherrill]

Neither Chris nor I could apply the patch.

Make sure it is against the master and resend it. I will try again.

--joel

On Wed, Aug 21, 2019 at 8:47 AM Himanshu Sekhar Nayak
 wrote:
>
> I pulled out the latest commit to my repo and didn't see my commit yet. btw 
> what should I do next ?
>
> -Himanshu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

Here is the final report, published in my Blog. Please review it.

https://medium.com/my-gsoc-2019-journey/gsoc-2019-posix-compliance-74571990c32a

Vaibhav Gupta

On Wed, Aug 21, 2019 at 12:21 AM Vaibhav Gupta 
wrote:

>
>
> On Wed, Aug 21, 2019 at 12:15 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Tue, Aug 20, 2019 at 9:31 PM Joel Sherrill  wrote:
>>
>>> I am late to the party.
>>
>> The party is still on :D
>>
>>> I made a couple of small changes directly to
>>> the document.
>>>
>> Thanks.
>>
>>>
>>> I encourage you continue to pick at getting the other fenv ports into
>>> newlib.
>>
>> This is on top of my priority list.
>>
>>> As you
>>> hopefully saw from me adding the stubs for fenv methods and
>>> documentation,
>>> things moving slowly were not a reflection on you personally. I
>>> certainly went through
>>> a number of rounds. :)
>>>
>> Yes, I am on it. It would be more easy if RISCV fenv works well. I can
>> get a testsuite
>> which will be of lot help.
>>
>>>
>>> Could you add a complete list of POSIX methods that you added? I need to
>>> update
>>> the spreadsheet and .csv file in the POSIX Compliance document.
>>>
>> Sure. I added two testsuites, ndbm and inttypes.
>> Only one header - "ndbm.h".
>>
>
>-
>
>int dbm_clearerr(DBM *);
>-
>
>voiddbm_close(DBM *);
>-
>
>int dbm_delete(DBM *, datum);
>-
>
>int dbm_error(DBM *);
>-
>
>datum   dbm_fetch(DBM *, datum);
>-
>
>datum   dbm_firstkey(DBM *);
>-
>
>datum   dbm_nextkey(DBM *);
>-
>
>DBM*dbm_open(const char *, int, mode_t);
>-
>
>int dbm_store(DBM *, datum, datum, int);
>-
>
>int dbm_dirfno(DBM *);
>
> Updated in report too.
>
>
>> I will update this in my report.
>>
>> --Vaibhav Gupta
>>
>>>
>>> --joel
>>>
>>> On Fri, Aug 16, 2019 at 10:48 PM Vaibhav Gupta 
>>> wrote:
>>> >
>>> > Made the changes as suggested :)
>>> > Please have a look at this now. If every thing is fine.
>>> > I will publish it in my blog.
>>> >
>>> > -Vaibhav Gupta
>>> >
>>> > On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:
>>> >>
>>> >> Vaibhav,
>>> >>
>>> >> Please add a subsection near the top that consolidates links to all
>>> >> the code you wrote during the summer. It is great to have them in
>>> >> context, but it should also be easy (~10 seconds) to find what code
>>> >> you wrote.
>>> >>
>>> >> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta <
>>> vaibhavgupt...@gmail.com> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > I have made the draft of my project report on google docs.
>>> >> > I have mentioned about each and every task completed
>>> >> > and which are in progress.
>>> >> > .
>>> >> > It would be very helpful for me If I can get reviews on this,
>>> >> > will also make required changes.
>>> >> > .
>>> >> >
>>> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
>>> >> > .
>>> >> > .
>>> >> > Thank You
>>> >> > Vaibhav Gupta
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] Add JSON log generation

[Kinsey Moore]

Add log formatter hooks and JSON log formatter to the test infrastructure
for consumption by automated processes or report generators.
---
 tester/rt/test.py | 124 --
 1 file changed, 111 insertions(+), 13 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index da0a11e..d5c7c66 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -178,7 +178,7 @@ def find_executables(paths, glob):
 executables = [e for e in executables if not norun.match(e)]
 return sorted(executables)
 
-def report_finished(reports, report_mode, reporting, finished, job_trace):
+def report_finished(reports, log_mode, reporting, finished, job_trace):
 processing = True
 while processing:
 processing = False
@@ -192,7 +192,7 @@ def report_finished(reports, report_mode, reporting, 
finished, job_trace):
 'reporting',
 reporting))
 processing = True
-reports.log(tst.executable, report_mode)
+reports.log(tst.executable, log_mode)
 reported += [tst]
 reporting += 1
 finished[:] = [t for t in finished if t not in reported]
@@ -217,6 +217,88 @@ def killall(tests):
 for test in tests:
 test.kill()
 
+
+def generate_json_report(args, reports, start_time, end_time,
+ total, json_file):
+import json
+import sys
+json_log = {}
+json_log['Command Line'] = " ".join(args)
+json_log['Python'] = sys.version.replace('\n', '')
+json_log['test_groups'] = []
+json_log['Host'] = host.label(mode='all')
+json_log['summary'] = {}
+json_log['summary']['passed_count'] = reports.passed
+json_log['summary']['failed_count'] = reports.failed
+json_log['summary']['user-input_count'] = reports.user_input
+json_log['summary']['expected-fail_count'] = reports.expected_fail
+json_log['summary']['indeterminate_count'] = reports.indeterminate
+json_log['summary']['benchmark_count'] = reports.benchmark
+json_log['summary']['timeout_count'] = reports.timeouts
+json_log['summary']['invalid_count'] = reports.invalids
+json_log['summary']['wrong-version_count'] = reports.wrong_version
+json_log['summary']['wrong-build_count'] = reports.wrong_build
+json_log['summary']['wrong-tools_count'] = reports.wrong_tools
+json_log['summary']['total_count'] = reports.total
+time_delta = end_time - start_time
+json_log['summary']['average_test_time'] = str(time_delta / total)
+json_log['summary']['testing_time'] = str(time_delta)
+
+result_types = [
+'failed', 'user-input', 'expected-fail', 'indeterminate',
+'benchmark', 'timeout', 'invalid', 'wrong-version', 'wrong-build',
+'wrong-tools'
+]
+json_results = {}
+for result_type in result_types:
+json_log['summary'][result_type] = []
+
+# collate results for JSON log
+for name in reports.results:
+result_type = reports.results[name]['result']
+test_parts = name.split("/")
+test_category = test_parts[-2]
+test_name = test_parts[-1]
+if result_type != 'passed':
+json_log['summary'][result_type].append(test_name)
+if test_category not in json_results:
+json_results[test_category] = []
+json_result = {}
+# remove the file extension
+json_result["name"] = test_name.split('.')[0]
+json_result["result"] = result_type
+if result_type == "failed" or result_type == "timeout":
+json_result["output"] = reports.results[name]["output"]
+json_results[test_category].append(json_result)
+
+# convert results to a better format for report generation
+sorted_keys = sorted(json_results.keys())
+for i in range(len(sorted_keys)):
+results_log = {}
+results_log["index"] = i + 1
+results_log["name"] = sorted_keys[i]
+results_log["results"] = json_results[sorted_keys[i]]
+json_log["test_groups"].append(results_log)
+
+# write out JSON log
+with open(json_file, 'w') as outfile:
+json.dump(json_log, outfile, sort_keys=True, indent=4)
+
+
+report_formatters = {
+'json': generate_json_report
+}
+
+
+def check_report_formats(report_formats, report_location):
+if report_location is None:
+raise error.general('report base path missing')
+for report_format in report_formats:
+if report_format not in report_formatters:
+raise error.general('invalid RTEMS report formatter: %s'
+% report_format)
+
+
 def run(args, command_path = None):
 import sys
 tests = []
@@ -227,7 +309,9 @@ def run(args, command_path = None):
 optargs = { '--rtems-tools':'The path to the RTEMS tools',
 '--rtems-bsp':  

[PATCH v3] Basic Support for Trace Compass

[Ravindra Meena]

---
 user/tracing/eventrecording.rst | 86 -
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/user/tracing/eventrecording.rst b/user/tracing/eventrecording.rst
index d1e44df..39c0117 100644
--- a/user/tracing/eventrecording.rst
+++ b/user/tracing/eventrecording.rst
@@ -55,7 +55,7 @@ function.
 Recorded events can be sent to a host computer with a very simple record server
 started by :c:func:`rtems_record_start_server` via a TCP connection.
 
-On the host computer you may use the command line tool :file:`rtems-record` to
+On the host computer you may use the command line tool 
:file:`rtems-record-lttng` to
 get recorded events from the record server running on the target system.
 
 .. _tracecompass:
@@ -63,49 +63,49 @@ get recorded events from the record server running on the 
target system.
 Trace Compass
 =
 
-`Trace Compass `_ is a tool to analyse 
-and display trace data graphically. Trace data can be gathered from  RTEMS 
+`Trace Compass `_ is a tool to analyse
+and display trace data graphically. Trace data can be gathered from  RTEMS
 applications via various means, for example:
 
 - :ref:`RTEMS Trace Linker `
 - :ref:`RTEMS Capture Engine `
 - :ref:`RTEMS Event Recording `
 
-Event Recording Infrastructure is used to analyse and display some basic 
-information. The basic information is defined by the Linux kernel trace 
+Event Recording Infrastructure is used to analyse and display some basic
+information. The basic information is defined by the Linux kernel trace
 support ( `LTTng `_ ) and includes CPU Usage, IRQ Analysis
-( IRQ Statistics, IRQ Table etc.), Linux Kernel( Control Flow, Resources etc. 
+( IRQ Statistics, IRQ Table etc.), Linux Kernel ( Control Flow, Resources etc.
 )
 
 Advanced support for `Trace Compass `_ includes dynamic memory traces, stack usage,
 network packet flow, etc.
 
-Event Recording Infrastructure generates the trace stream and converted into 
-`LTTng `_ format at host which is easily understood by 
+Event Recording Infrastructure generates the trace stream and converted into
+`LTTng `_ format at host which is easily understood by
 `Trace Compass `_.
 
 This scheme of tracing goes through the flow of events described in a 
subsequent
-flowchart. This requires the environment setup of 
-`rtems-libbsd `_  and 
+flowchart. This requires the environment setup of
+`rtems-libbsd `_  and
 `rtems-tools `_:
 
 Step 1: The QEMU simulator is used to run a LibBSD based application and 
connect
 it to a virtual network on host. This requires to create a TAP virtual Ethernet
 interface for this. The QEMU command line is used for board support package, 
e.g
-the arm/xilinx_zynq_a9_qemu BSP etc. The host can be connected to target via 
+the arm/xilinx_zynq_a9_qemu BSP etc. The host can be connected to target via
 telnet.
 
 Step 2: On the host computer the command line tool rtems-record can be used to
-get recorded events from the record server running on the target system. 
+get recorded events from the record server running on the target system.
 Recorded events can be sent to a host computer with a very simple record server
-started by rtems_record_start_server() via a TCP connection.
+started by :c:func:`rtems_record_start_server` via a TCP connection.
 
-Step 3: The trace data received at host from QEMU target is converted into 
-`LTTng `_ trace. The 
-`Babeltrace `_ and 
-`Trace Compass `_ are two compatible 
-software which can read `LTTng `_ trace. The converted 
+Step 3: The trace data received at host from QEMU target is converted into
+`LTTng `_ trace. The
+`Babeltrace `_ and
+`Trace Compass `_ are two compatible
+software which can read `LTTng `_ trace. The converted
 `LTTng `_ trace can be passed to any of these softwares.
 
 .. figure:: ../../images/user/event-recording-trace.png
@@ -116,7 +116,7 @@ RTEMS LTTng Trace Generation Example
 
 
 Step 1: Clone the repositories 
-`rtems-libbsd 
`_  
+`rtems-libbsd `_
 and 
 `rtems-tools `_
 and set up the environment, if haven't done already.
@@ -145,23 +145,23 @@ Step 3: This requires to TAP virtual Ethernet interface 
for this:
 After some seconds it will acquire a IPv4 link-local 

Re: [PATCH v3] Add JSON log generation

[Chris Johns]

On 22/8/19 2:34 am, Kinsey Moore wrote:
> Add log formatter hooks and JSON log formatter to the test infrastructure
> for consumption by automated processes or report generators.

Pushed. Thank you.

A documentation patch would be most welcome

https://docs.rtems.org/branches/master/user/tools/tester.html

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

Re: [PATCH RSB] Add gdb-8.3 as default debugger

[Chris Johns]

On 21/8/19 5:33 pm, Jiri Gaisler wrote:
> I suggest that we switch to gdb-8.3 for targets that currently use 8.2.1. The 
> update is relatively minor but allows building without any patches. Tested 
> for SPARC and RISC-V targets.

I am OK with this happening. Please push.

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

[PATCH] Update docs for log mode change and JSON reporting

[Kinsey Moore]

The option --report-mode has been changed to --log-mode to reduce ambiguity
and --report-format has been added along with --report-path for machine
readable test reporting.
---
 user/tools/tester.rst | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 9fb50c7..609384b 100644
--- a/user/tools/tester.rst
+++ b/user/tools/tester.rst
@@ -251,7 +251,7 @@ timeouts and 1 invalid test.
 * ``sparc/erc32`` is the architecture and BSP names.
 * ``hello.exe`` is the executable name.
 
-The test log records all the tests and results. The reporting mode by default
+The test log records all the tests and results. The logging mode by default
 only provides the output history if a test fails, times out, or is invalid. The
 time taken by each test is also recorded.
 
@@ -317,16 +317,16 @@ If no start marker is seen the test is marked as invalid. 
If you are testing on
 real target hardware things can sometimes go wrong and the target may not
 initialize or respond to the debugger in an expected way.
 
-Reporting
--
+Logging
+---
 
-The report written to the log has the following modes:
+The following modes of logging are available:
 
 * All (``all``)
 * Failures (``failures``)
 * None (``none``)
 
-The mode is controlled using the command line option ``--report-mode`` using
+The mode is controlled using the command line option ``--log-mode`` using
 the values listed above.
 
 All
@@ -410,6 +410,17 @@ running on a Coldfire MCF5235 using GDB and a BDM pod:
 * Line starting with ``]`` are from the target's console.
 * The result with the test time.
 
+Reporting
+-
+
+The RTEMS Tester supports output in a machine parsable format. This can be
+enabled using the options "--report-path" and "--report-format". Currently,
+JSON output is supported using these options like so:
+'--report-path="report" --report-format=json'
+
+This will produce a file "report.json" that contains output equivalent to the
+"failure" logging mode.
+
 Running Tests in Parallel
 -
 
@@ -419,8 +430,8 @@ resource contention. Simulators are an example of back-ends 
that can run in
 parallel. A hardware debug tool like a BDM or JTAG pod can manage only a
 single test at once so the tests need to be run one at a time.
 
-The test framework manages the test jobs and orders the output in the report
-log in test order. Output is held for completed tests until the next test to be
+The test framework manages the test jobs and orders the output in the log
+in test order. Output is held for completed tests until the next test to be
 reported has finished.
 
 Command Line Help
@@ -444,7 +455,9 @@ review the available option by the ``--help`` option:
 --macros file[,file] : Macro format files to load after the 
defaults
 --no-clean   : Do not clean up the build tree
 --quiet  : Quiet output (not used)
---report-mode: Reporting modes, failures (default),all,none
+--report-path: Report output base path (file extension 
will be added)
+--report-format  : Formats in which to report test results: 
json
+--log-mode   : Log modes, failures (default),all,none
 --rtems-bsp  : The RTEMS BSP to run the test on
 --rtems-tools: The path to the RTEMS tools
 --target : Set the target triplet
-- 
2.20.1

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

Re: [PATCH] Update docs for log mode change and JSON reporting

[Chris Johns]

On 22/8/19 11:41 am, Kinsey Moore wrote:
> The option --report-mode has been changed to --log-mode to reduce ambiguity
> and --report-format has been added along with --report-path for machine
> readable test reporting.

Pushed. Thank you.

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