Re: [tools] tester: Normalize JSON and YAML reports
On 30/06/2022 07:58, Sebastian Huber wrote:
On 29/06/2022 17:54, Kinsey Moore wrote:
On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports. Do not report
redundant
information.
Update 4671.
This patch changes the JSON reports. Are there already consumers
for the JSON reports so that we have to be backward compatible?
Could compatibility be added back in if this proves to be an issue?
I am wondering if that could be considered if comparability becomes
an issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators
already exist.
The existing attribute names are quite inconsistent, for example
"Command Line", "passed_count", "wrong-version_count". I would use
lower case only with "-" as a separator. The JSON report should
contain all information of a test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47
UTC 2022 (2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no
peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no
peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1
for 0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2
for 0x214480.",
"GLOBAL: Hey I'm in derived class constructor number
3 for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4
for 0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
There are no publicly available report generators for the existing
format, but I do have one I use to generate STR documents for delivery
using mustache templates and further processing. The existing format
was designed to be easily consumable by that and other simple
templating mechanisms by providing structure (test subsets) and
precalculating values that would otherwise be implicit in the data.
Changes to the names of various fields should be easy to accommodate,
but a more significant restructure is going to present problems
continuing with any simple templating mechanism and would instead
require a more comprehensive document generator for all cases.
I'm not necessarily opposed to this change as it significantly
simplifies the report generation code, but it will definitely require
some rework in my processes. I can't speak for any users of the YAML
report format, but it was committed over a year an
Re: [PATCH] sppps01: Add test case for early returns of pps_event()
On 15/06/2022 15:08, Gabriel Moyano wrote:
---
testsuites/sptests/sppps01/init.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/testsuites/sptests/sppps01/init.c
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..ee3fe1645b 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsuites/sptests/sppps01/init.c
@@ -76,6 +76,48 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
T_eq_int( status, ETIMEDOUT );
}
+static int wokenup = 0;
+
+static void fake_wakeup(struct pps_state *pps)
+{
+wokenup++;
+}
I would move the wokenup into struct test_pps_device.
In the existing code, use rtems_task_exit() instead of
rtems_task_delete(rtems_task_self()).
--
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
One test more for PPS API
Hi Sebastian, I added this test https://lists.rtems.org/pipermail/devel/2022-June/071926.html some time ago. Could you give me your feedback? Thanks in advance, Gabriel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [tools] tester: Normalize JSON and YAML reports
On 29/06/2022 17:54, Kinsey Moore wrote:
On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports. Do not report
redundant
information.
Update 4671.
This patch changes the JSON reports. Are there already consumers for
the JSON reports so that we have to be backward compatible?
Could compatibility be added back in if this proves to be an issue?
I am wondering if that could be considered if comparability becomes
an issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators
already exist.
The existing attribute names are quite inconsistent, for example
"Command Line", "passed_count", "wrong-version_count". I would use
lower case only with "-" as a separator. The JSON report should
contain all information of a test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47
UTC 2022 (2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no
peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no
peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1
for 0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2
for 0x214480.",
"GLOBAL: Hey I'm in derived class constructor number 3
for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4 for
0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
There are no publicly available report generators for the existing
format, but I do have one I use to generate STR documents for delivery
using mustache templates and further processing. The existing format was
designed to be easily consumable by that and other simple templating
mechanisms by providing structure (test subsets) and precalculating
values that would otherwise be implicit in the data. Changes to the
names of various fields should be easy to accommodate, but a more
significant restructure is going to present problems continuing with any
simple templating mechanism and would instead require a more
comprehensive document generator for all cases.
I'm not necessarily opposed to this change as it significantly
simplifies the report generation code, but it will definitely require
some rework in my processes. I can't speak for any users of the YAML
report format, but it was committed over a year and a half ago.
Ok, I will bring back the redun
Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP
Hello Duc, Am 29.06.22 um 13:46 schrieb Duc Doan: Hello Christian, I have been writing the complete API and also implementation for STM32F4. A patch is coming soon. On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote: Regarding pin groups: I think it's worth to think a bit about how the structure could be extended. You don't have to implement it right now but you should have a plan what could be possible. From my point of view, there are two directions how that could be implemented: Masks or lists. If you have a mask (like 0x00108 for pin 3 and pin 8) it has the advantage that it works fast for most controllers. Difficult is that it adds a limit to the maximum pin number depending on the size of the mask. With that it works only for a few hardware models. The other option is to add a list of pins instead of a mask. That makes it inefficient because most controllers will have to collect pins into masks and work with that. Hm. Difficult. Maybe someone else has a good idea for that in the next few days. I am thinking of later adding separate functions that handle pin groups. I think it's quite hard to integrate into current functions because of using virtual pin. I have an assumption that needs confirmation: all microcontrollers (or most of them) have register size equal to word size, and pin masks should be at word size. Is that assumption correct? If so, maybe we can just use unsigned int (or uintptr_t) for pin masks? Not sure whether some 64bit controllers don't use 32bit registers. So it's not generally true that registers have the word size. It should work for most controllers (at least the ones I worked with) but I wouldn't guarantee it. Beneath that: You most likely know my argument already: What about I2C or SPI chips. They can use register sizes that are not the same as the controllers register size (even if they are most likely only 8 bit most of the time at least for I2C). Best regards Christian Best, Duc Doan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [tools] tester: Normalize JSON and YAML reports
On 6/29/2022 04:34, Sebastian Huber wrote:
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports. Do not report
redundant
information.
Update 4671.
This patch changes the JSON reports. Are there already consumers for
the JSON reports so that we have to be backward compatible?
Could compatibility be added back in if this proves to be an issue?
I am wondering if that could be considered if comparability becomes
an issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators
already exist.
The existing attribute names are quite inconsistent, for example
"Command Line", "passed_count", "wrong-version_count". I would use
lower case only with "-" as a separator. The JSON report should
contain all information of a test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47
UTC 2022 (2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no
peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no
peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1
for 0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2
for 0x214480.",
"GLOBAL: Hey I'm in derived class constructor number 3
for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4 for
0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
There are no publicly available report generators for the existing
format, but I do have one I use to generate STR documents for delivery
using mustache templates and further processing. The existing format was
designed to be easily consumable by that and other simple templating
mechanisms by providing structure (test subsets) and precalculating
values that would otherwise be implicit in the data. Changes to the
names of various fields should be easy to accommodate, but a more
significant restructure is going to present problems continuing with any
simple templating mechanism and would instead require a more
comprehensive document generator for all cases.
I'm not necessarily opposed to this change as it significantly
simplifies the report generation code, but it will definitely require
some rework in my processes. I can't speak for any users of the YAML
report format, but it was committed over a year and a half ago.
Kinsey
___
devel mailing list
Re: [PATCH] arm/gicv3: Fix building arm/r52
On 27/06/2022 08:27, Sebastian Huber wrote: On 27/06/2022 05:02, Chris Johns wrote: On 24/6/2022 7:44 pm, Sebastian Huber wrote: On 20.06.22 04:03, chr...@rtems.org wrote: From: Chris Johns --- bsps/include/dev/irq/arm-gicv3.h | 5 + 1 file changed, 5 insertions(+) diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h index a79368ebdf..aac02fa191 100644 --- a/bsps/include/dev/irq/arm-gicv3.h +++ b/bsps/include/dev/irq/arm-gicv3.h @@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index) } /* Enable interrupt groups 0 and 1 */ +#ifdef ARM_MULTILIB_ARCH_V4 + WRITE_SR(ICC_IGRPEN0, 0x1); + WRITE_SR(ICC_IGRPEN1, 0x1); +#else gic_icc_write(IGRPEN1, 1); +#endif WRITE_SR(ICC_CTLR, 0x0); } I have a different patch to fix this: https://lists.rtems.org/pipermail/devel/2022-June/072056.html Does this change work on a real aarch64 with a suitably configured TF-A? The security profile of the TF-A needs to disable EL1 access to these registers to see the issue. I don't have a hardware to test this change. I can do tests on a Cortex-R52 hardware. For the Cortex-R52, group 0 interrupts are signaled through FIQ exceptions and group 1 interrupts are signaled through IRQ exceptions. This processor has no secore/non-secure states. I checked the GICv3 manual. The group 0 interrupts are always Secure if the system has at least two Security states. So, if RTEMS runs in Non-Secure mode, it cannot modify group 0 interrupts. We have some things to consider: 1. Count of system security states 2. In which state RTEMS runs 3. What RTEMS needs to initialize We cannot simply use the target architecture to determine what to do during GIC initialization. I think we need some BSP options to control the initialization behaviour. -- 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] score: Add _CPU_Use_thread_local_storage()
At some point during system initialization, the idle threads are created.
Afterwards, the boot processor basically executes within the context of an idle
thread with thread dispatching disabled. On some architectures, the
thread-local storage area of the associated thread must be set in dedicated
processor registers. Add the new CPU port function to do this:
void _CPU_Use_thread_local_storage( const Context_Control *context )
Close #4672.
---
.../cpu/aarch64/include/rtems/score/cpuimpl.h | 9 +++
.../cpu/arm/include/rtems/score/cpuimpl.h | 13 ++
.../cpu/bfin/include/rtems/score/cpuimpl.h| 7 +
.../cpu/i386/include/rtems/score/cpuimpl.h| 26 +++
.../cpu/lm32/include/rtems/score/cpuimpl.h| 7 +
.../cpu/m68k/include/rtems/score/cpuimpl.h| 11
.../microblaze/include/rtems/score/cpuimpl.h | 11
.../cpu/mips/include/rtems/score/cpuimpl.h| 7 +
.../cpu/moxie/include/rtems/score/cpuimpl.h | 7 +
.../cpu/nios2/include/rtems/score/cpuimpl.h | 12 +
.../cpu/no_cpu/include/rtems/score/cpuimpl.h | 17
.../cpu/or1k/include/rtems/score/cpuimpl.h| 7 +
.../cpu/powerpc/include/rtems/score/cpuimpl.h | 16
.../cpu/riscv/include/rtems/score/cpuimpl.h | 12 +
.../cpu/sh/include/rtems/score/cpuimpl.h | 7 +
.../cpu/sparc/include/rtems/score/cpuimpl.h | 12 +
.../cpu/sparc64/include/rtems/score/cpuimpl.h | 7 +
.../cpu/v850/include/rtems/score/cpuimpl.h| 7 +
.../cpu/x86_64/include/rtems/score/cpuimpl.h | 7 +
cpukit/score/src/threadcreateidle.c | 5
testsuites/sptests/sptls01/init.c | 20 +++---
21 files changed, 223 insertions(+), 4 deletions(-)
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
index ffdef2f30a..14836965ef 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
@@ -162,6 +162,15 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation(
void )
__asm__ volatile ( "nop" );
}
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+ const Context_Control *context
+)
+{
+ __asm__ volatile (
+"msr TPIDR_EL0, %0" : : "r" ( context->thread_id ) : "memory"
+ );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
index 0ce347c86f..4f20113b71 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
@@ -160,6 +160,19 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation(
void )
__asm__ volatile ( "nop" );
}
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+ const Context_Control *context
+)
+{
+#ifdef ARM_MULTILIB_HAS_THREAD_ID_REGISTER
+ __asm__ volatile (
+"mcr p15, 0, %0, c13, c0, 3" : : "r" ( context->thread_id ) : "memory"
+ );
+#else
+ (void) context;
+#endif
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
index 1485abd365..91e57da4a0 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
@@ -59,6 +59,13 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation(
void )
__asm__ volatile ( "nop" );
}
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+ const Context_Control *context
+)
+{
+ (void) context;
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
index 31ec0ac8bb..71f2679dde 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
@@ -80,6 +80,32 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation(
void )
__asm__ volatile ( "nop" );
}
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+ const Context_Control *context
+)
+{
+ uint32_t tmp;
+ uint32_t cpu_index;
+
+#ifdef RTEMS_SMP
+ cpu_index = _CPU_SMP_Get_current_processor();
+#else
+ cpu_index = 0;
+#endif
+
+ __asm__ volatile (
+"movl " RTEMS_XSTRING( I386_CONTEXT_CONTROL_GS_0_OFFSET ) "(%2), %0\n"
+"movl %0, _Global_descriptor_table+24(,%1,8)\n"
+"movl " RTEMS_XSTRING( I386_CONTEXT_CONTROL_GS_1_OFFSET ) "(%2), %0\n"
+"movl %0, _Global_descriptor_table+28(,%1,8)\n"
+"leal 24(,%1,8), %0\n"
+"movl %0, %%gs\n"
+: "=&r" ( tmp )
+: "r" ( cpu_index ), "r" ( context )
+: "memory"
+ );
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
index eb0c058723..24e8e5cb41 100644
--- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/lm32/i
Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP
Hello Christian, I have been writing the complete API and also implementation for STM32F4. A patch is coming soon. On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote: > Regarding pin groups: I think it's worth to think a bit about how the > structure could be extended. You don't have to implement it right now > but you should have a plan what could be possible. > > From my point of view, there are two directions how that could be > implemented: Masks or lists. > > If you have a mask (like 0x00108 for pin 3 and pin 8) it has the > advantage that it works fast for most controllers. Difficult is that > it > adds a limit to the maximum pin number depending on the size of the > mask. With that it works only for a few hardware models. > > The other option is to add a list of pins instead of a mask. That > makes > it inefficient because most controllers will have to collect pins > into > masks and work with that. > > Hm. Difficult. Maybe someone else has a good idea for that in the > next > few days. I am thinking of later adding separate functions that handle pin groups. I think it's quite hard to integrate into current functions because of using virtual pin. I have an assumption that needs confirmation: all microcontrollers (or most of them) have register size equal to word size, and pin masks should be at word size. Is that assumption correct? If so, maybe we can just use unsigned int (or uintptr_t) for pin masks? Best, Duc Doan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [tools] tester: Normalize JSON and YAML reports
On 29/06/2022 11:20, Chris Johns wrote:
On 29 Jun 2022, at 4:42 pm, Sebastian Huber
wrote:
On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports. Do not report redundant
information.
Update 4671.
This patch changes the JSON reports. Are there already consumers for the JSON
reports so that we have to be backward compatible?
Could compatibility be added back in if this proves to be an issue?
I am wondering if that could be considered if comparability becomes an issue.
The JSON report was added by:
commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore
Date: Wed Aug 21 16:34:12 2019 +
Add JSON log generation
Add log formatter hooks and JSON log formatter to the test
infrastructure
for consumption by automated processes or report generators.
I am not sure if these automated processes or report generators already
exist.
The existing attribute names are quite inconsistent, for example
"Command Line", "passed_count", "wrong-version_count". I would use lower
case only with "-" as a separator. The JSON report should contain all
information of a test run.
The new report looks like this:
{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC
2022 (2cc2ade) x86_64 x86_64)",
"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic -net
none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M -kernel
build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable":
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512":
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",
"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION:
6.0.0.3302b72754df5f37214e86dd68522189857772c7",
"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1 for
0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2 for
0x214480.",
"GLOBAL: Hey I'm in derived class constructor number 3
for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4 for
0x228864.",
...
"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",
"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",
"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",
"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}
--
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: [tools] tester: Normalize JSON and YAML reports
> On 29 Jun 2022, at 4:42 pm, Sebastian Huber > wrote: > > On 29/06/2022 08:40, Sebastian Huber wrote: >> Report the same data in JSON and YAML reports. Do not report redundant >> information. >> Update 4671. > > This patch changes the JSON reports. Are there already consumers for the JSON > reports so that we have to be backward compatible? Could compatibility be added back in if this proves to be an issue? I am wondering if that could be considered if comparability becomes an issue. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
