date:20201208

[PATCH] tester: Add configs for AArch64 ZynqMP BSPs

2020-12-08 Thread Kinsey Moore

---
 .../testing/bsps/xilinx_zynqmp_ilp32.ini  | 38 +++
 .../rtems/testing/bsps/xilinx_zynqmp_lp64.ini | 38 +++
 2 files changed, 76 insertions(+)
 create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
 create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini

diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini 
b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
new file mode 100644
index 000..5ff0e86
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# 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.
+#
+
+#
+# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) ILP32 BSP.
+#
+[xilinx_zynqmp_ilp32]
+bsp   = xilinx_zynqmp_ilp32
+arch  = aarch64
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine 
xlnx-zcu102 -m 4096
diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini 
b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
new file mode 100644
index 000..8db82b6
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# 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.
+#
+
+#
+# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) LP64 BSP.
+#
+[xilinx_zynqmp_lp64]
+bsp   = xilinx_zynqmp_lp64
+arch  = aarch64
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = %{qemu_opts_base} -serial null -serial mon:stdio -machine 
xlnx-zcu102 -m 4096
-- 
2.20.1

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

[PATCH 2/3] user: Add A53 Qemu run instructions

2020-12-08 Thread Kinsey Moore

---
 user/bsps/aarch64/a53.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
index 73735b1..e3a89f8 100644
--- a/user/bsps/aarch64/a53.rst
+++ b/user/bsps/aarch64/a53.rst
@@ -25,3 +25,10 @@ Console Driver
 --
 
 The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
+
+Running Executables
+---
+
+Executables generated by these BSPs can be run using the following command::
+
+qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine 
virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe
-- 
2.20.1

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

[PATCH 1/3] aarch64: Update interrupt details

2020-12-08 Thread Kinsey Moore

---
 cpu-supplement/aarch64.rst | 5 -
 user/bsps/aarch64/a53.rst  | 5 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/cpu-supplement/aarch64.rst b/cpu-supplement/aarch64.rst
index 9e74d6b..a102817 100644
--- a/cpu-supplement/aarch64.rst
+++ b/cpu-supplement/aarch64.rst
@@ -104,7 +104,10 @@ Interrupt Stack
 ---
 
 The board support package must initialize the interrupt stack. The memory for
-the stacks is usually reserved in the linker script.
+the stacks is usually reserved in the linker script. The interrupt stack 
pointer
+is stored in the EL0 stack pointer and is accessed by switching to SP0 mode
+at the beginning of interrupt calls and back to SPx mode after completion of
+interrupt calls using the `spsel` instruction.
 
 Default Fatal Error Processing
 ==
diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
index 9f085b8..73735b1 100644
--- a/user/bsps/aarch64/a53.rst
+++ b/user/bsps/aarch64/a53.rst
@@ -8,8 +8,9 @@
 Qemu A53
 
 
-This BSP supports two variants, `qemu_a53_ilp32` and `qemu-a53_lp64`. The basic
-hardware initialization is performed by the BSP.
+This BSP supports two variants, `qemu_a53_ilp32` and `qemu_a53_lp64`. The basic
+hardware initialization is performed by the BSP. These BSPs support the GICv3
+interrupt controller.
 
 Boot via ELF
 
-- 
2.20.1

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

Re: Which threads execute _Thread_Handler ?

2020-12-08 Thread Sebastian Huber


On 05/12/2020 07:13, Richi Dubey wrote:



The stack trace for the thread looks like this:

Tasks (entry function) -> rtems_task_wake_after 
->_Thread_Dispatch_direct -> _Thread_Do_dispatch (where the 
_Context_switch function call lies), how can then the heir thread 
start executing from the _Thread_Handler? I do not see it in the trace 
at all.

The context of new threads is set up by _Thread_Load_environment().

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

[PATCH 3/3] user: Add aarch64/xilinx-zynqmp

2020-12-08 Thread Kinsey Moore

---
 user/bsps/aarch64/xilinx-zynqmp.rst | 34 +
 user/bsps/bsps-aarch64.rst  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 user/bsps/aarch64/xilinx-zynqmp.rst

diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst 
b/user/bsps/aarch64/xilinx-zynqmp.rst
new file mode 100644
index 000..7a3bd24
--- /dev/null
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+
+.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32:
+.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64:
+
+Qemu Xilinx ZynqMP
+==
+
+This BSP supports two variants, `xilinx-zynqmp-ilp32` and `xilinx-zynqmp-lp64`.
+The basic hardware initialization is performed by the BSP. These BSPs support
+the GICv2 interrupt controller present in all ZynqMP systems.
+
+Boot via ELF
+
+The executable image is booted by Qemu in ELF format.
+
+Clock Driver
+
+
+The clock driver uses the `ARM Generic Timer`.
+
+Console Driver
+--
+
+The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
+
+Running Executables
+---
+
+Executables generated by these BSPs can be run using the following command::
+
+qemu-system-aarch64 -no-reboot -nographic -serial null -serial mon:stdio 
-machine xlnx-zcu102 -m 4096 -kernel example.exe
diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst
index 319310e..0d4b23c 100644
--- a/user/bsps/bsps-aarch64.rst
+++ b/user/bsps/bsps-aarch64.rst
@@ -6,3 +6,4 @@ aarch64 (AArch64)
 *
 
 .. include:: aarch64/a53.rst
+.. include:: aarch64/xilinx-zynqmp.rst
-- 
2.20.1

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

Re: Report on failing tests with thread stack protection and their resolution.

2020-12-08 Thread Utkarsh Rai

On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom  wrote:

>
>
> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai 
> wrote:
>
>> Hello,
>> As discussed in this
>>  thread,
>> I have compiled a list of the tests that deal with inter stack
>> communication and fail with the thread stack protection option. Most of
>> these tests pass when, as Sebastian suggested and had provided a
>> wonderful example, I disable memory protection at places where contents of
>> different thread stacks are accessed by the current thread. There are a few
>> tests that still fail due to inter-stack access in the application code
>> itself.
>>
>> The changes I have made are -
>>
>> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> index c176d4b8c5..a45b175395 100644
>> --- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>> @@ -1,15 +1,49 @@
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>> +bool set_memory_flags(Thread_Control* thread, void* arg)
>> +{
>> +  uintptr_t begin;
>> +  uintptr_t end;
>> +  uint32_t flags;
>> +  rtems_interrupt_level irq_level;
>> +  Thread_Control *executing;
>> +
>> +  executing = _Thread_Executing;
>> +
>> +  if(thread !=  executing) {
>>
> This is not concurrency-safe. By time the check happens, or following code
> happens, the thread could become executing.
>
>
>> +
>> +flags = *( uint32_t *)( arg );
>> +begin = thread->Start.Initial_stack.area;
>> +end = begin + thread->Start.Initial_stack.size;
>> +
>> +rtems_interrupt_disable(irq_level);
>> +arm_cp15_set_translation_table_entries(begin, end, flags);
>> +rtems_interrupt_enable(irq_level);
>> +  }
>> +
>> +  return false;
>>
> why -- what does the return value mean?
>

While iterating over threads, if the visitor returns true the iteration
stops.


>
>
>> +}
>> +
>> +rtems_status_code _Memory_protection_Enable( void )
>> +{
>> +  uint32_t access_flags;
>> +
>> +  access_flags = translate_flags(  RTEMS_NO_ACCESS );
>> +
>> +  _Thread_Iterate( set_memory_flags, &access_flags );
>> +
>> +  return RTEMS_SUCCESSFUL; // check the return values for iterating
>> function and current method.
>> +}
>> +
>> +rtems_status_code _Memory_protection_Disable( void )
>> +{
>> +  uint32_t access_flags;
>> +
>> +  access_flags = translate_flags(  RTEMS_READ_WRITE );
>> +
>> +  _Thread_Iterate( set_memory_flags, &access_flags );
>> +
>> +  return RTEMS_SUCCESSFUL;
>>  }
>> \ No newline at end of file
>> diff --git a/cpukit/include/rtems/score/coremsgimpl.h
>> b/cpukit/include/rtems/score/coremsgimpl.h
>> index e598dce96a..3719a3d3c8 100644
>> --- a/cpukit/include/rtems/score/coremsgimpl.h
>> +++ b/cpukit/include/rtems/score/coremsgimpl.h
>> @@ -27,6 +27,10 @@
>>  #include 
>>  #include 
>>
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> + #include 
>> +#endif
>> +
>>  #include 
>>  #include 
>>
>> @@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>> *_CORE_message_queue_Dequeue_receiver(
>>if ( the_thread == NULL ) {
>>  return NULL;
>>}
>> -
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +  _Memory_protection_Disable();
>>
> I wonder if it is necessary to disable all protection, or can you just
> disable the protection applied to 'the_thread' (or maybe to 'executing')?
>

No, it is not necessary. I will make the changes.


>
>
>> +#endif
>> *(size_t *) the_thread->Wait.return_argument = size;
>> the_thread->Wait.count = (uint32_t) submit_type;
>>
>> @@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>> *_CORE_message_queue_Dequeue_receiver(
>>  the_thread->Wait.return_argument_second.mutable_object,
>>  size
>>);
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +  _Memory_protection_Enable();
>> +#endif
>>
>>_Thread_queue_Extract_critical(
>>  &the_message_queue->Wait_queue.Queue,
>>
>> diff --git a/cpukit/posix/src/psignalunblockthread.c
>> b/cpukit/posix/src/psignalunblockthread.c
>> index 80a0f33a09..e0f8468de6 100644
>> --- a/cpukit/posix/src/psignalunblockthread.c
>> +++ b/cpukit/posix/src/psignalunblockthread.c
>> @@ -24,6 +24,9 @@
>>  #include 
>>
>>  #include 
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +#include 
>> +#endif
>>  #include 
>>  #include 
>>  #include 
>> @@ -205,6 +208,10 @@ bool _POSIX_signals_Unblock_thread(
>>
>>the_info = (siginfo_t *) the_thread->Wait.return_argument;
>>
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +_Memory_protection_Disable();
>> +#endif
>> +
>>if ( !info ) {
>>  the_info->si_signo = signo;
>>  the_info->si_code = SI_USER;
>> @@ -212,6 +219,9 @@ bool _POSIX_signals_Unblock_thread(
>>} else {
>>  *the_info = *info;
>>}
>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>> +_Memory_protection_Enable();
>> +#endif
>>
>>_Thread_queue_Extract_with_proxy( the_thread );
>>return _POSIX_

Re: [PATCH v2 1/1] tester: Add yaml format to the supported report formats

2020-12-08 Thread Chris Johns

Hi,

I am sorry about the slow response, I have been side tracked onto other things.

On 4/12/20 3:41 am, cl...@isep.ipp.pt wrote:
> From: Cláudio Maia 
> 
> ---
>  tester/rt/test.py | 115 +-
>  1 file changed, 113 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 9b157e9..e0cfdff 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -339,9 +339,120 @@ def generate_junit_report(args, reports, start_time, 
> end_time,
>  with open(junit_file, 'w') as f:
>  TestSuite.to_file(f, [ts], prettyprint = True)
>  
> +
> +def generate_yaml_report(args, reports, start_time, end_time,
> + total, yaml_file):
> +""" Generates a YAML file containing information about the test run,
> +including all test outputs """
> +
> +try:
> +import yaml
> +except ImportError:
> +print("\nWARNING: To generate the yaml report, the PyYAML module "
> +  "should be installed. HINT: You can use pip to install it!")
> +return

I have considered this change some more and I feel this should be a hard error
and raised when checking the report format. Generating this warning after a long
test run would frustrate users.

This section of code can be just the import if the import is checked before the
test runs. Have a look at here to add the check ...

https://git.rtems.org/rtems-tools/tree/tester/rt/test.py#n348

... and if the import fails please raise a general error.

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

[PATCH v3 0/1] Add yaml format to the supported report formats

2020-12-08 Thread clrrm

From: Cláudio Maia 

Two output formats were supported by RTEMS Tester: json and junit.
This patch adds yaml to the list of supported formats. 

The information being stored in the output file is the same as the one being
stored for the other formats, with the addition of adding a few more execution
details, such as the output of each test and the "debugger" output.

The feature can be used in the same manner as the other report formats, by 
using "--report-format=yaml --report-path=name-of-report".

The patch was tested using leon3 bsp and SIS, either for Python 2.7 and
Python 3.6.9.

v3 adds code to check_report_formats() for handling the ImportError exception
when yaml module is not found by Python runtime environment.

Cláudio Maia (1):
  tester: Add yaml format to the supported report formats

 tester/rt/test.py | 116 +-
 1 file changed, 114 insertions(+), 2 deletions(-)

-- 
2.17.1

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

[PATCH v3 1/1] tester: Add yaml format to the supported report formats

2020-12-08 Thread clrrm

From: Cláudio Maia 

---
 tester/rt/test.py | 116 +-
 1 file changed, 114 insertions(+), 2 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9b157e9..66f1756 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -339,9 +339,115 @@ def generate_junit_report(args, reports, start_time, 
end_time,
 with open(junit_file, 'w') as f:
 TestSuite.to_file(f, [ts], prettyprint = True)
 
+
+def generate_yaml_report(args, reports, start_time, end_time,
+ total, yaml_file):
+""" Generates a YAML file containing information about the test run,
+including all test outputs """
+
+import yaml
+
+def format_output(output_list):
+return "\n".join(output_list).replace("] ", '').replace('=>  ', '')
+
+yaml_log = {}
+yaml_log['command-line'] = args
+yaml_log['host'] = host.label(mode='all')
+yaml_log['python'] = sys.version.replace('\n', '')
+yaml_log['summary'] = {}
+yaml_log['summary']['passed-count'] = reports.passed
+yaml_log['summary']['failed-count'] = reports.failed
+yaml_log['summary']['user-input-count'] = reports.user_input
+yaml_log['summary']['expected-fail-count'] = reports.expected_fail
+yaml_log['summary']['indeterminate-count'] = reports.indeterminate
+yaml_log['summary']['benchmark-count'] = reports.benchmark
+yaml_log['summary']['timeout-count'] = reports.timeouts
+yaml_log['summary']['test-too-long_count'] = reports.test_too_long
+yaml_log['summary']['invalid-count'] = reports.invalids
+yaml_log['summary']['wrong-version-count'] = reports.wrong_version
+yaml_log['summary']['wrong-build-count'] = reports.wrong_build
+yaml_log['summary']['wrong-tools-count'] = reports.wrong_tools
+yaml_log['summary']['total-count'] = reports.total
+time_delta = end_time - start_time
+yaml_log['summary']['average-test-time'] = str(time_delta / total)
+yaml_log['summary']['testing-time'] = str(time_delta)
+
+result_types = [
+'failed', 'user-input', 'expected-fail', 'indeterminate',
+'benchmark', 'timeout', 'test-too-long', 'invalid', 
'wrong-version',
+'wrong-build', 'wrong-tools'
+]
+for result_type in result_types:
+yaml_log['summary'][result_type] = []
+
+result_element = {}
+yaml_log['outputs'] = []
+
+# process output of each test
+for exe_name in reports.results:
+test_parts = exe_name.split("/")
+test_name = test_parts[-1]
+result_element['executable-name'] = test_name
+result_element['executable-sha512'] = get_hash512(exe_name)
+result_element['execution-start'] = 
reports.results[exe_name]['start'].isoformat()
+result_element['execution-end'] = 
reports.results[exe_name]['end'].isoformat()
+date_diff = reports.results[exe_name]['end'] - 
reports.results[exe_name]['start']
+result_element['execution-duration'] = str(date_diff)
+result_element['execution-result'] = 
reports.results[exe_name]['result']
+result_element['bsp'] = reports.results[exe_name]['bsp']
+result_element['bsp-arch'] = reports.results[exe_name]['bsp_arch']
+result_output = reports.results[exe_name]['output']
+
+dbg_output = []
+test_output = []
+idxs_output = []  # store indices of given substrings
+for elem in result_output:
+if '=> ' in elem:
+idxs_output.append(result_output.index(elem))
+if '*** END' in elem:
+idxs_output.append(result_output.index(elem))
+
+if len(idxs_output) == 3:  # test executed and has result
+dbg_output = result_output[idxs_output[0]:idxs_output[1]]
+dbg_output.append("=== Executed Test ===")
+dbg_output = dbg_output + 
result_output[idxs_output[2]+1:len(result_output)]
+test_output = result_output[idxs_output[1]:idxs_output[2]+1]
+else:
+dbg_output = result_output
+
+result_element['debugger-output'] = format_output(dbg_output)
+result_element['console-output'] = format_output(test_output)
+yaml_log['outputs'].append(result_element)
+
+result_type = reports.results[exe_name]['result']
+# map "fatal-error" on to "failed"
+if result_type == "fatal-error":
+result_type = "failed"
+
+if result_type != 'passed':
+yaml_log['summary'][result_type].append(test_name)
+
+result_element = {}
+
+with open(yaml_file, 'w') as outfile:
+yaml.dump(yaml_log, outfile, default_flow_style=False, 
allow_unicode=True)
+
+
+def get_hash512(exe):
+""" returns SHA512 hash string of a given binary file passed as argument 
"""
+import hashlib
+
+hash = hashlib.sha512()
+with open(exe, "rb") as f:
+for byte_block in iter(lambda: f.read(4096), b""):
+hash.update(byte_block)
+return

Fwd: New Defects reported by Coverity Scan for RTEMS

2020-12-08 Thread Gedare Bloom

Hi all,

I get a text report on new defects from Coverity. I don't know how I
managed to sign up for it, and I'm not sure I can get it sent to any list
automatically, but here is the current updated new defects. Just looks like
two new ones related to static assertions.

-- Forwarded message -
From: 
Date: Mon, Dec 7, 2020 at 7:38 AM
Subject: New Defects reported by Coverity Scan for RTEMS
To: 


Hi,

Please find the latest report on new defect(s) introduced to RTEMS found
with Coverity Scan.

1 new defect(s) introduced to RTEMS found with Coverity Scan.
10 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1470570:(PARSE_ERROR)
/cpukit/include/rtems/confdefs/inittask.h: 110 in ()
/cpukit/include/rtems/confdefs/inittask.h: 110 in ()



*** CID 1470570:(PARSE_ERROR)
/cpukit/include/rtems/confdefs/inittask.h: 110 in ()
104  */
105 #pragma GCC diagnostic push
106 #pragma GCC diagnostic ignored "-Waddress"
107 #pragma GCC diagnostic ignored "-Wpragmas"
108 #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
109
>>> CID 1470570:(PARSE_ERROR)
>>> type of cast must be integral
110 RTEMS_STATIC_ASSERT(
111   CONFIGURE_INIT_TASK_ENTRY_POINT != NULL,
112   CONFIGURE_INIT_TASK_ENTRY_POINT_MUST_NOT_BE_NULL
113 );
114
115 #pragma GCC diagnostic pop
/cpukit/include/rtems/confdefs/inittask.h: 110 in ()
104  */
105 #pragma GCC diagnostic push
106 #pragma GCC diagnostic ignored "-Waddress"
107 #pragma GCC diagnostic ignored "-Wpragmas"
108 #pragma GCC diagnostic ignored "-Wtautological-pointer-compare"
109
>>> CID 1470570:(PARSE_ERROR)
>>> expression must be an integral constant expression
110 RTEMS_STATIC_ASSERT(
111   CONFIGURE_INIT_TASK_ENTRY_POINT != NULL,
112   CONFIGURE_INIT_TASK_ENTRY_POINT_MUST_NOT_BE_NULL
113 );
114
115 #pragma GCC diagnostic pop



To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3DQoso_NXfCUf1CLFYLbjXajJIgHlbL5qYn95oel6MvjPauKObduhXPexAzfKX6jsO7er2hdt7mLsPf0-2BXS5HnRA5pW30MNjlaaFQEYCYCMg96r853K06s3gi9LqIWWlUUUfi3rJcv0KJzC5K2ip4-2FvxreJHCA73al8f3y7oipOLr-2BfvAi2Ga39-2F-2FvVNrqQXvFVplDho9gSB1VkeBJYJWCeLSkXVy9toULwXMzhJQ6KVJpOPRk-3D

  To manage Coverity Scan email notifications for "ged...@gwmail.gwu.edu",
click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxkxN7gn3yK5ofbuH1ptBFYw9YgpazuIaA-2BBUVKiHj8oV-2B8VTkzFKFnUmsUyw0Q9nyW7WjK2N4nPgBbDLb1fKVuS61T4CLxLpVJMj16z2MR2k-3DfLlk_NXfCUf1CLFYLbjXajJIgHlbL5qYn95oel6MvjPauKObduhXPexAzfKX6jsO7er2hkl-2Fz3PxTuWKbib5pSdrYhFcMwwTQMmLWHWFFVK1o1yTFlpCa4PAXf8ONXr-2B5hqyFvFLjdqvBd1pguBfVv0jrWl9OKawq7XISLIbWTsyNgXacfi1S5KxyRLzvyLgJz4LIRUtGzoxzHZRfQp8hWV9wsMS20-2FrbDJ8kxOqkS24MAJY-3D
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] cpukit/aarch64: Add explanation of exception flow

2020-12-08 Thread Kinsey Moore

---
 .../cpu/aarch64/aarch64-exception-default.S | 17 -
 .../cpu/aarch64/aarch64-exception-interrupt.S   |  4 ++--
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.S 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.S
index 81aa82558e..970ccf735f 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.S
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.S
@@ -54,7 +54,22 @@
 
 /*
  * This is the exception vector table and the pointers to the default
- * exceptions handlers.
+ * exceptions handlers. Each vector in the table has space for up to 32
+ * instructions. The space of the last two instructions in each vector is used
+ * for the exception handler pointer.
+ *
+ * The operation of all exceptions is as follows:
+ * * An exception occurs
+ * * A vector is chosen based on the exception type and machine state
+ * * Execution begins at the chosen vector
+ * * X0 and LR are pushed onto the current stack
+ * * An unconditional branch and link is taken to the next instruction to get
+ *   the PC
+ * * The exception handler pointer (EHP) is retrieved from the current vector 
using
+ *   the PC
+ * * Branch and link to the EHP
+ * * X0 and LR are popped from the current stack after returning from the EHP
+ * * The exception returns to the previous execution state
  */
 
 /*
diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-interrupt.S 
b/cpukit/score/cpu/aarch64/aarch64-exception-interrupt.S
index f534a526b3..cb0954a29b 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-interrupt.S
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-interrupt.S
@@ -255,7 +255,7 @@ _AArch64_Exception_interrupt_nest:
 Save volatile regs on interrupt stack
 Execute irq handler
 Restore volatile regs from interrupt stack
-Exception return
+Return to embedded exception vector code
 */
 
 /* Push interrupt context */
@@ -281,7 +281,7 @@ Execute interrupt handler
 Switch to thread stack
 Call thread dispatch
 Restore volatile registers from thread stack
-Return to dispatch
+Return to embedded exception vector code
 */
 
 
-- 
2.20.1

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

[PATCH 1/2] cpukit/aarch64: Use hex consistently for offsets

2020-12-08 Thread Kinsey Moore

---
 .../cpu/aarch64/aarch64-context-validate.S|  40 +++---
 .../cpu/aarch64/aarch64-exception-default.S   |  38 +++---
 .../cpu/aarch64/aarch64-exception-interrupt.S | 116 +-
 cpukit/score/cpu/aarch64/cpu_asm.S|  12 +-
 .../cpu/aarch64/include/rtems/score/cpu.h |  26 ++--
 5 files changed, 116 insertions(+), 116 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-context-validate.S 
b/cpukit/score/cpu/aarch64/aarch64-context-validate.S
index 31c8d5571c..57f634934b 100644
--- a/cpukit/score/cpu/aarch64/aarch64-context-validate.S
+++ b/cpukit/score/cpu/aarch64/aarch64-context-validate.S
@@ -43,29 +43,29 @@
 #include 
 #include 
 
-#define FRAME_OFFSET_X4 0
-#define FRAME_OFFSET_X5 8
-#define FRAME_OFFSET_X6 16
-#define FRAME_OFFSET_X7 24
-#define FRAME_OFFSET_X8 32
-#define FRAME_OFFSET_X9 40
-#define FRAME_OFFSET_X10 48
-#define FRAME_OFFSET_X11 56
-#define FRAME_OFFSET_LR 64
+#define FRAME_OFFSET_X4  0x00
+#define FRAME_OFFSET_X5  0x08
+#define FRAME_OFFSET_X6  0x10
+#define FRAME_OFFSET_X7  0x18
+#define FRAME_OFFSET_X8  0x20
+#define FRAME_OFFSET_X9  0x28
+#define FRAME_OFFSET_X10 0x30
+#define FRAME_OFFSET_X11 0x38
+#define FRAME_OFFSET_LR  0x40
 
 #ifdef AARCH64_MULTILIB_VFP
-  #define FRAME_OFFSET_V8 72
-  #define FRAME_OFFSET_V9 88
-  #define FRAME_OFFSET_V10 104
-  #define FRAME_OFFSET_V11 120
-  #define FRAME_OFFSET_V12 136
-  #define FRAME_OFFSET_V13 152
-  #define FRAME_OFFSET_V14 168
-  #define FRAME_OFFSET_V15 184
-
-  #define FRAME_SIZE (FRAME_OFFSET_V15 + 16)
+  #define FRAME_OFFSET_V8  0x48
+  #define FRAME_OFFSET_V9  0x58
+  #define FRAME_OFFSET_V10 0x68
+  #define FRAME_OFFSET_V11 0x78
+  #define FRAME_OFFSET_V12 0x88
+  #define FRAME_OFFSET_V13 0x98
+  #define FRAME_OFFSET_V14 0xA8
+  #define FRAME_OFFSET_V15 0xB8
+
+  #define FRAME_SIZE (FRAME_OFFSET_V15 + 0x10)
 #else
-  #define FRAME_SIZE (FRAME_OFFSET_LR + 8)
+  #define FRAME_SIZE (FRAME_OFFSET_LR + 0x08)
 #endif
 
.section.text
diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.S 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.S
index 3d311df280..81aa82558e 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.S
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.S
@@ -74,7 +74,7 @@
  */
blr x0
 /* Pop x0,lr from stack */
-   ldp x0, lr, [sp],   #16
+   ldp x0, lr, [sp],   #0x10
 /* Return from exception */
eret
nop
@@ -129,7 +129,7 @@ Vector_table_el3:
  * using SP0.
  */
 curr_el_sp0_sync:
-   stp x0, lr, [sp, #-16]! /* Push x0,lr on to the stack */
+   stp x0, lr, [sp, #-0x10]!   /* Push x0,lr on to the stack */
bl curr_el_sp0_sync_get_pc  /* Get current execution address */
 curr_el_sp0_sync_get_pc:   /* The current PC is now in LR */
JUMP_HANDLER
@@ -137,7 +137,7 @@ curr_el_sp0_sync_get_pc:/* The current PC is 
now in LR */
 .balign 0x80
 /* The exception handler for IRQ exceptions from the current EL using SP0. */
 curr_el_sp0_irq:
-   stp x0, lr, [sp, #-16]! /* Push x0,lr on to the stack */
+   stp x0, lr, [sp, #-0x10]!   /* Push x0,lr on to the stack */
bl curr_el_sp0_irq_get_pc   /* Get current execution address */
 curr_el_sp0_irq_get_pc:/* The current PC is now in LR 
*/
JUMP_HANDLER
@@ -145,7 +145,7 @@ curr_el_sp0_irq_get_pc: /* The current 
PC is now in LR */
 .balign 0x80
 /* The exception handler for FIQ exceptions from the current EL using SP0. */
 curr_el_sp0_fiq:
-   stp x0, lr, [sp, #-16]! /* Push x0,lr on to the stack */
+   stp x0, lr, [sp, #-0x10]!   /* Push x0,lr on to the stack */
bl curr_el_sp0_fiq_get_pc   /* Get current execution address */
 curr_el_sp0_fiq_get_pc:/* The current PC is now in LR 
*/
JUMP_HANDLER
@@ -156,7 +156,7 @@ curr_el_sp0_fiq_get_pc: /* The current 
PC is now in LR */
  * SP0.
  */
 curr_el_sp0_serror:
-   stp x0, lr, [sp, #-16]! /* Push x0,lr on to the stack */
+   stp x0, lr, [sp, #-0x10]!   /* Push x0,lr on to the stack */
bl curr_el_sp0_serror_get_pc/* Get current execution address */
 curr_el_sp0_serror_get_pc: /* The current PC is now in LR */
JUMP_HANDLER
@@ -167,7 +167,7 @@ curr_el_sp0_serror_get_pc:  /* The current PC is 
now in LR */
  * the current SP.
  */
 curr_el_spx_sync:
-   stp x0, lr, [sp, #-16]! /* Push x0,lr on to the stack */
+   stp x0, lr, [sp, #-0x10]!   /* Push x0,lr on to the stack */
bl curr_el_spx_sync_get_pc  /* Get current execution address */
 curr_el_spx_sync_get_pc:   /* The current PC is now in LR */
JUMP_HANDLER
@@ -178,7 +178,7 @@ curr_el_spx_sync_get_pc:/* The current PC is 
now in LR */
  * current SP.
  */
 curr_el_spx_irq:
-   stp x0, lr, [sp, #-16]! /*

Re: [PATCH v2 1/1] tester: Add yaml format to the supported report formats

2020-12-08 Thread Cláudio Maia

Hi Cris,

On 07/12/20 23:02, Chris Johns wrote:
> Hi,
>
> I am sorry about the slow response, I have been side tracked onto other 
> things.
No problem with that.
> On 4/12/20 3:41 am, cl...@isep.ipp.pt wrote:
>> From: Cláudio Maia 
>>
>> ---
>>  tester/rt/test.py | 115 +-
>>  1 file changed, 113 insertions(+), 2 deletions(-)
>>
>> diff --git a/tester/rt/test.py b/tester/rt/test.py
>> index 9b157e9..e0cfdff 100644
>> --- a/tester/rt/test.py
>> +++ b/tester/rt/test.py
>> @@ -339,9 +339,120 @@ def generate_junit_report(args, reports, start_time, 
>> end_time,
>>  with open(junit_file, 'w') as f:
>>  TestSuite.to_file(f, [ts], prettyprint = True)
>>  
>> +
>> +def generate_yaml_report(args, reports, start_time, end_time,
>> + total, yaml_file):
>> +""" Generates a YAML file containing information about the test run,
>> +including all test outputs """
>> +
>> +try:
>> +import yaml
>> +except ImportError:
>> +print("\nWARNING: To generate the yaml report, the PyYAML module "
>> +  "should be installed. HINT: You can use pip to install it!")
>> +return
> I have considered this change some more and I feel this should be a hard error
> and raised when checking the report format. Generating this warning after a 
> long
> test run would frustrate users.
I agree with you. It makes sense to test it before the test run starts.
>
> This section of code can be just the import if the import is checked before 
> the
> test runs. Have a look at here to add the check ...
>
> https://git.rtems.org/rtems-tools/tree/tester/rt/test.py#n348
>
> ... and if the import fails please raise a general error.
Your suggestion was integrated in V3.
>
> Thanks
> Chris

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

[PATCH] Add patch to newlib for devctl.h to compile with C++

2020-12-08 Thread Joel Sherrill

Closes #4174.
---
 rtems/config/tools/rtems-gcc-7.5.0-newlib-7947581.cfg | 4 
 1 file changed, 4 insertions(+)

diff --git a/rtems/config/tools/rtems-gcc-7.5.0-newlib-7947581.cfg 
b/rtems/config/tools/rtems-gcc-7.5.0-newlib-7947581.cfg
index cf62d2f..b02ced3 100644
--- a/rtems/config/tools/rtems-gcc-7.5.0-newlib-7947581.cfg
+++ b/rtems/config/tools/rtems-gcc-7.5.0-newlib-7947581.cfg
@@ -23,6 +23,10 @@
 %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
 %hash sha512 newlib-%{newlib_version}.tar.gz 
3122fcced8c3c9f5e6c9103bc882958364f3bc7f1806843ff470ed70cd2b9c5c239b9a905c08341ee4d0988e26022fb5da7e565e8af984cd00724288416158d8
 
+# Patch for devctl.h C++ issue (#4174)
+%patch add newlib --rsb-file=newlib-devctl-fix.patch -p1 
https://devel.rtems.org/raw-attachment/ticket/4174/0001-libc-include-newlib.h-Fix-C-compilation-issue.patch
+%hash sha512 newlib-devctl-fix.patch 
28723fa2a8b263a40cf53a5812201464140e7c4f3a04132cb96f6f64d62c2ab5e70743f4d5ccb057829e9f317097b9fef21f1817e584902e1424f6feb43a64cf
+
 %define isl_version 0.16.1
 %hash sha512 isl-%{isl_version}.tar.bz2 
c188667a84dc5bdddb4ab7c35f89c91bf15a8171f4fcaf41301cf285fb7328846d9a367c096012fec4cc69d244f0bc9e95d84c09ec097394cd4093076f2a041b
 
-- 
1.8.3.1

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

rtems-docs.git cross-linked documents

2020-12-08 Thread Chris Johns

Hello,

I have discovered a growing number of cross-links in the documentation...

$ grep -r 'branches/master' . | wc -l
  42

We cannot cleanly support cross-referencing documents via href links and
referencing master like this is wrong. HTML might be workable if someone is
willing to invest the time however PDF documents have no relative capability
that I know of.

I have raised #4200 to handle a specific instance in the build section of the
user manual however I can re-purpose the ticket to cover all instances and make
it a release blocker. We cannot make a release while referencing master.

We need to clean this up and stop adding links like this. I know it is
frustrating however I am yet to see a suitable technical solution for all
formats we generate. That is the requirement that needs to be met to add
cross-linking back.

A solution could be a configure option that accepts a URL path. If no option was
provided no href link is created. A use case for no cross-liniing is a CDROM of
documentation or documentation deployed by an installer where the user can
select the install path.

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

Re: rtems-docs.git cross-linked documents

2020-12-08 Thread Sebastian Huber


On 09/12/2020 02:19, Chris Johns wrote:


I have discovered a growing number of cross-links in the documentation...

$ grep -r 'branches/master' . | wc -l
   42


Independent of the general issue with the cross-links, the growing 
number is  due to the automatically generated header. For example:


./c-user/partition/directives.rst:.. 
https://docs.rtems.org/branches/master/user/support/bugs.html
./c-user/partition/directives.rst:.. 
https://docs.rtems.org/branches/master/eng/req/howto.html
./c-user/partition/introduction.rst:.. 
https://docs.rtems.org/branches/master/user/support/bugs.html
./c-user/partition/introduction.rst:.. 
https://docs.rtems.org/branches/master/eng/req/howto.html


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: rtems-docs.git cross-linked documents

2020-12-08 Thread Chris Johns

On 9/12/20 4:49 pm, Sebastian Huber wrote:
> On 09/12/2020 02:19, Chris Johns wrote:
> 
>> I have discovered a growing number of cross-links in the documentation...
>>
>> $ grep -r 'branches/master' . | wc -l
>>    42
> 
> Independent of the general issue with the cross-links, the growing number is 
> due to the automatically generated header. For example:
> 
> ./c-user/partition/directives.rst:..
> https://docs.rtems.org/branches/master/user/support/bugs.html
> ./c-user/partition/directives.rst:..
> https://docs.rtems.org/branches/master/eng/req/howto.html
> ./c-user/partition/introduction.rst:..
> https://docs.rtems.org/branches/master/user/support/bugs.html
> ./c-user/partition/introduction.rst:..
> https://docs.rtems.org/branches/master/eng/req/howto.html

Yes I saw. I do not have a solution but these links do not work and cannot be
added to the documentation like this.

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

[PATCH] tester: Add configs for AArch64 ZynqMP BSPs

[PATCH 2/3] user: Add A53 Qemu run instructions

[PATCH 1/3] aarch64: Update interrupt details

Re: Which threads execute _Thread_Handler ?

[PATCH 3/3] user: Add aarch64/xilinx-zynqmp

Re: Report on failing tests with thread stack protection and their resolution.

Re: [PATCH v2 1/1] tester: Add yaml format to the supported report formats

[PATCH v3 0/1] Add yaml format to the supported report formats

[PATCH v3 1/1] tester: Add yaml format to the supported report formats

Fwd: New Defects reported by Coverity Scan for RTEMS

[PATCH 2/2] cpukit/aarch64: Add explanation of exception flow

[PATCH 1/2] cpukit/aarch64: Use hex consistently for offsets

Re: [PATCH v2 1/1] tester: Add yaml format to the supported report formats

[PATCH] Add patch to newlib for devctl.h to compile with C++

rtems-docs.git cross-linked documents

Re: rtems-docs.git cross-linked documents

Re: rtems-docs.git cross-linked documents

17 matches

Site Navigation

Mail list logo

Footer information