Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory
On 18/10/2021 07:19, chr...@rtems.org wrote: From: Chris Johns - Coherent cache memory is used in libbsd for things like descriptors and it optionally clears the memory on allocation. Test is works. There is no guarantee that memset() and memcpy() work with cache coherent memory. Such memory areas may disallow misaligned access for example. -- 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
ZynqMP and Versal crash clearing coherent cache memory with memset
Hi, I cannot run libbsd on real hardware because the cadence rx descriptor cache coherent allocation crashes in `memset`. It is used to clear the memory. The rtemsbsd allocator call optionally clears the memory and it seems the newlib aarch64 memset code crashes when doing this. A basic loop with 8bit or 32bit writes does not crash. The memset call happily clears an array in cached memory with different offsets. I have posted a patch to spcache01 that generates the crash on Versal and ZynqMP hardware. The crash dump is: test cache coherent allocation clear cache coherent with memset: 0x1fe00050 *** FATAL *** fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) X0 = 0x1fe00050 X17 = 0x000c X1 = 0x X18 = 0x17b0 X2 = 0x0110 X19 = 0x1fe00050 X3 = 0x1fe000c0 X20 = 0x1fdfff80 X4 = 0x1fe00250 X21 = 0x10013ab0 X5 = 0x0004 X22 = 0x X6 = 0x0001 X23 = 0x X7 = 0x X24 = 0x10103140 X8 = 0x X25 = 0x X9 = 0xff80ffc8 X26 = 0x X10 = 0x X27 = 0x X11 = 0x1010ca78 X28 = 0x X12 = 0x0001 FP = 0x1010cc30 X13 = 0x1fe00050 LR = 0x10001f94 X14 = 0x SP = 0x1010cc30 X15 = 0x0004 PC = 0x100125c0 X16 = 0x1000f700 DAIF = 0x03c0 VEC = 0x0004 CPSR = 0x6005 ESR = EC: 0b100101 IL: 0b1 ISS: 0b00111 Data Abort taken without a change in Exception level FAR = 0x1fe000c0 FPCR = 0x FPSR = 0x0010 The Versal (A72) fails in exactly the same way. The allocated address is 0x1fe00050 and the FAR is 0x1fe000c0 so I am not sure if the "0xc0 - 0x50" section is aligning the pointer to a larger word size for better performance and that first part is OK but the different word size breaks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuite/spcache01: Clear allocated coherent cache memory
From: Chris Johns
- Coherent cache memory is used in libbsd for things like descriptors
and it optionally clears the memory on allocation. Test is works.
---
testsuites/sptests/spcache01/init.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/testsuites/sptests/spcache01/init.c
b/testsuites/sptests/spcache01/init.c
index b6ad797dd3..fa87204b4b 100644
--- a/testsuites/sptests/spcache01/init.c
+++ b/testsuites/sptests/spcache01/init.c
@@ -451,9 +451,12 @@ static void test_cache_coherent_alloc(void)
printf("test cache coherent allocation\n");
- p0 = rtems_cache_coherent_allocate(1, 0, 0);
+ p0 = rtems_cache_coherent_allocate(512, 0, 0);
rtems_test_assert(p0 != NULL);
+ printf("clear cache coherent with memset: %p\n", p0);
+ memset(p0, 0, 512);
+
rtems_cache_coherent_free(p0);
p0 = rtems_cache_coherent_allocate(1, 0, 0);
--
2.24.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/3] Add Secure Monitor Call API
On 16/10/2021 22:12, Gedare Bloom wrote: Gedare Bloom (3): aarch64: add internal API for secure monitor call (smc) bsps/aarch64: use SMC API in bspsmp-arm-psci bsps/aarch64: use SMC API in bspreset-arm-psci Looks good. Maybe use for the @brief of the source file: This source file contains the implementation of _AArch64_SMC_Invoke(). -- 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-tools commit] tester/exe: Adjust timeouts by the step size
On 16/10/21 1:14 am, Sebastian Huber wrote: > On 15/10/2021 08:26, Chris Johns wrote: >> On 15/10/21 5:15 pm, Sebastian Huber wrote: >>> On 22/09/2021 00:59, Chris Johns wrote: Module: rtems-tools Branch: master Commit: cfd5aa41e847752cd98cde65515df7ce45ff9665 Changeset:http://git.rtems.org/rtems-tools/commit/?id=cfd5aa41e847752cd98cde65515df7ce45ff9665 Author: Chris Johns Date: Mon Sep 20 21:32:24 2021 -1000 tester/exe: Adjust timeouts by the step size >>> With this change I get a timeout >> Looking at the change I made I think it should be `/` and not `*`? >> >> Does that work? >> >> I normal need a `*` because the `step` is a number and not a fraction which >> Python uses. > > Changing '*' to '/' fixed the timeout issue, Thanks. The change is OK to push. If you would like me to push it please let me know. > but I have no idea what this code is supposed to do. It monitors the test and generates a timeout test failure.s There are two layers of timeout, one for output and the other for a test running too long. The test needs to generate some output within the first timeout period and the second timeout detects if the test has run too long. The first timeout detects a target has locked up. The second is for a test looping generating output. With exe type tests the output is buffered in a separate thread. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
