Re: Ticket 4503

2021-10-18 Thread zack leung 
bump


On Sat, 25 Sept 2021 at 00:26, zack leung  wrote:

> bump
>
> On Thu, 9 Sept 2021 at 02:17, zack leung  wrote:
>
>> >Thanks! I guess i'm really unsure about how the pointer relates to the
>> amount of memory that you can use. I assume the Malloc keeps track of the
>> sections being used in the heap. Does this function Allocate 2 blocks since
>> the pointer is set to
>>
>> (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
>>
>> >(I know it's a bit naive to assume this given my first question)
>>
>> think the method is _Heap_Size_of_alloc_area. It may need a wrapper added
>> to the protected heap wrapper for safety. I don't know if it has one. It
>> should be the equivalent functionality.
>> > How would i implement a wrapper and what safety measures need to be
>> implemented. So far it's checking if :  the block is not in the heap and if
>> it's been previously used. Is the usable memory in the heap calculated by:
>> the size of the block * # of blocks?
>>
>> Thanks, Zack
>>
>> -- Forwarded message -
>> From: Joel Sherrill 
>> Date: Wed, 8 Sept 2021 at 20:30
>> Subject: Re: Ticket 4503
>> To: Gedare Bloom 
>> Cc: zack leung , rtems-de...@rtems.org <
>> devel@rtems.org>
>>
>>
>>
>>
>> On Wed, Sep 8, 2021 at 11:02 AM Gedare Bloom  wrote:
>>
>>> Hi Zack,
>>>
>>> https://devel.rtems.org/ticket/4503
>>>
>>> The malloc implementation exists in the score as the Heap Manager.
>>> search for "Heap_" within cpukit to get some ideas where to look.
>>>
>>
>> I think the method is _Heap_Size_of_alloc_area. It may need a wrapper
>> added to the protected heap wrapper for safety. I don't know if it has one.
>> It should be the equivalent functionality.
>>
>> newlib's malloc.h will need looking at to make sure we provide the right
>> methods.
>>
>>
>>
>>>
>>> @Joel are these two tickets duplicates?
>>> https://devel.rtems.org/ticket/4503
>>> https://devel.rtems.org/ticket/4271
>>>
>>
>> Yes. Closed #4271 and merged comments.
>>
>> --joel
>>
>>
>>>
>>>
>>> -Gedare
>>>
>>> On Tue, Sep 7, 2021 at 7:14 PM zack leung 
>>> wrote:
>>>
 I was wondering about ticket 4503. I was wondering where The required
 functionality should be in the underlying score/ capability used can be
 found to write this function. Also how does this relate  to

 Add common malloc family extension method malloc_usable_size()
 ?
 Thanks
 Zack
 ___
 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: Ticket 4429

2021-10-18 Thread zack leung 
bump


On Wed, 6 Oct 2021 at 00:30, zack leung  wrote:

> For relative times, the clock identifier is not used to select the clock
> and instead always the CLOCK_MONOTONIC is used. A side-effect is that
> sleep() and nanosleep() use the wrong clock (CLOCK_MONOTONIC instead of
> CLOCK_REALTIME).
>
> I don't understand how the monotonic clock is not being used. I know that
> if it's not a realtime clock then
> Thread_queue_Context_set_enqueue_timeout_monotonic_timespec is called and i
> believe that all the appropriate branches are there to make the monotonic
> clock work.
>
> Zack
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] fix memory leak within calloc.c libtests

2021-10-18 Thread zack leung 
fix came from github code inspector, flagged by one of the analysis that
was done
---
 testsuites/libtests/POSIX/calloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/POSIX/calloc.c
b/testsuites/libtests/POSIX/calloc.c
index bd04faa800..a7537c8cc4 100644
--- a/testsuites/libtests/POSIX/calloc.c
+++ b/testsuites/libtests/POSIX/calloc.c
@@ -16,6 +16,8 @@ int
 main (void)
 {
   void *foo = calloc (42, 43);
+  int rc = (foo != NULL);
+  free(foo);

-  return (foo != NULL);
+  return rc;
 }
-- 
2.33.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems/6: Update binutils to 2.37

2021-10-18 Thread Chris Johns 
On 19/10/21 9:23 am, Joel Sherrill wrote:
> Was there something wrong with Ryan's patch to do this? He also bumped RTEMS 7
> tools. 

No not at all.

> You reviewed it. :)

I thought I had reviewed it and I checked the repo today and could not see
anything. Is it pushed?

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

Re: [PATCH] rtems/6: Update binutils to 2.37

2021-10-18 Thread Joel Sherrill 
Was there something wrong with Ryan's patch to do this? He also bumped
RTEMS 7 tools.

You reviewed it. :)

On Mon, Oct 18, 2021, 5:20 PM  wrote:

> From: Chris Johns 
>
> ---
>  rtems/config/6/rtems-default.bset  |  2 +-
>  rtems/config/tools/rtems-binutils-2.37.cfg | 15 +++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 rtems/config/tools/rtems-binutils-2.37.cfg
>
> diff --git a/rtems/config/6/rtems-default.bset
> b/rtems/config/6/rtems-default.bset
> index 0c07b08..8bf6922 100644
> --- a/rtems/config/6/rtems-default.bset
> +++ b/rtems/config/6/rtems-default.bset
> @@ -12,6 +12,6 @@ devel/expat-2.1.0-1
>  devel/gmp-6.1.0
>  tools/rtems-gdb-10
>
> -tools/rtems-binutils-2.36
> +tools/rtems-binutils-2.37
>  tools/rtems-gcc-10-newlib-head
>  tools/rtems-tools-6
> diff --git a/rtems/config/tools/rtems-binutils-2.37.cfg
> b/rtems/config/tools/rtems-binutils-2.37.cfg
> new file mode 100644
> index 000..3aa7a41
> --- /dev/null
> +++ b/rtems/config/tools/rtems-binutils-2.37.cfg
> @@ -0,0 +1,15 @@
> +%include %{_configdir}/checks.cfg
> +%include %{_configdir}/base.cfg
> +
> +%define binutils_version binutils-2_37
> +%define binutils_external 1
> +%define binutils_expand_name
> sourceware-mirror-binutils-gdb-%{binutils_version}
> +%source set binutils --rsb-file=%{binutils_expand_name}.tar.gz \
> +
> https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
> +%hash sha512 %{binutils_expand_name}.tar.gz \
> +
> NOEmH3J6oPTTA85U8iL5Spb944pgKWv/EHInJOAtA8jY4xigCP2UzYFisfhPawYaQIfjCVICLdpAJU1ybi6UpQ==
> +
> +%define with_deterministic_archives 1
> +%define with_64_bit_bfd 1
> +
> +%include %{_configdir}/binutils-2-1.cfg
> --
> 2.24.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems/6: Update binutils to 2.37

2021-10-18 Thread chrisj 
From: Chris Johns 

---
 rtems/config/6/rtems-default.bset  |  2 +-
 rtems/config/tools/rtems-binutils-2.37.cfg | 15 +++
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 rtems/config/tools/rtems-binutils-2.37.cfg

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 0c07b08..8bf6922 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,6 +12,6 @@ devel/expat-2.1.0-1
 devel/gmp-6.1.0
 tools/rtems-gdb-10
 
-tools/rtems-binutils-2.36
+tools/rtems-binutils-2.37
 tools/rtems-gcc-10-newlib-head
 tools/rtems-tools-6
diff --git a/rtems/config/tools/rtems-binutils-2.37.cfg 
b/rtems/config/tools/rtems-binutils-2.37.cfg
new file mode 100644
index 000..3aa7a41
--- /dev/null
+++ b/rtems/config/tools/rtems-binutils-2.37.cfg
@@ -0,0 +1,15 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define binutils_version binutils-2_37
+%define binutils_external 1
+%define binutils_expand_name sourceware-mirror-binutils-gdb-%{binutils_version}
+%source set binutils --rsb-file=%{binutils_expand_name}.tar.gz \
+
https://codeload.github.com/RTEMS/sourceware-mirror-binutils-gdb/tar.gz/%{binutils_version}
+%hash sha512 %{binutils_expand_name}.tar.gz \
+
NOEmH3J6oPTTA85U8iL5Spb944pgKWv/EHInJOAtA8jY4xigCP2UzYFisfhPawYaQIfjCVICLdpAJU1ybi6UpQ==
+
+%define with_deterministic_archives 1
+%define with_64_bit_bfd 1
+
+%include %{_configdir}/binutils-2-1.cfg
-- 
2.24.1

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

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

2021-10-18 Thread Chris Johns 
On 19/10/21 8:59 am, Joel Sherrill wrote:
> On Mon, Oct 18, 2021 at 4:28 PM Chris Johns  wrote:
>>
>> On 19/10/21 3:53 am, Kinsey Moore wrote:
>>> On 10/18/2021 00:44, Chris Johns wrote:
 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.
>>>
>>> I'm running with a toolchain that was built with
>>> --targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of the
>>> memset function, so my memset is just loops of writes and seems to work 
>>> fine.
>>
>> Oh. Maybe the eng manual needs a piece on this. Using flags on tool chains 
>> like
>> this is fine for a user because it is use at your own peril however I believe
>> patches need to be tested with the defaults for all tools. It is way to hard 
>> to
>> baseline a BSP if tweaks are needed here and there.
> 
> We did try to merge this to the RSB as a temporary workaround for ilp32 
> issues.
> Kinsey may have realized it had this impact also but I don't recall
> being aware of it.

Sure and we need to accommodate this but I think as a policy we need to make
sure patches are tested with default tool sets. I cannot see how we can make
things work without having this happen?

> We didn't want it to be a local hack. :)

It may have to be just that. It seem to me we have an IPL32 BSP that needs a
special set of tools and that constrains any other aarch64 BSPs if it became the
default. Do we want that? If the cached memory gets a performance boost from a
better memset, memcpy etc then I hope that is available to me by default.

>>> Just out of curiousity, what instruction was at that PC address? If it was 
>>> "dc
>>> zva", then I had seen this a while back during initial AArch64 bringup and 
>>> had
>>> assumed it was fixed since the addition of the MMU code since that 
>>> instruction
>>> doesn't work on device memory.
>>
>> It this that instruction ...
>>
>> 100125c0:   d50b7423dc  zva, x3
>>
>> Looks like it is not fixed.
> 
> I think your suggestion that FreeBSD should not use memset for device memory
> is the right path though. But that could be in a lot of places. :(

I do not know. The allocation is under the bus space DMA allocator and that
interface is complicated. Maybe memset is not suitable?

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

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

2021-10-18 Thread Joel Sherrill 
On Mon, Oct 18, 2021 at 4:28 PM Chris Johns  wrote:
>
> On 19/10/21 3:53 am, Kinsey Moore wrote:
> > On 10/18/2021 00:44, Chris Johns wrote:
> >> 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.
> >
> > I'm running with a toolchain that was built with
> > --targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of the
> > memset function, so my memset is just loops of writes and seems to work 
> > fine.
>
> Oh. Maybe the eng manual needs a piece on this. Using flags on tool chains 
> like
> this is fine for a user because it is use at your own peril however I believe
> patches need to be tested with the defaults for all tools. It is way to hard 
> to
> baseline a BSP if tweaks are needed here and there.

We did try to merge this to the RSB as a temporary workaround for ilp32 issues.
Kinsey may have realized it had this impact also but I don't recall
being aware of
it.

We didn't want it to be a local hack. :)

> > Just out of curiousity, what instruction was at that PC address? If it was 
> > "dc
> > zva", then I had seen this a while back during initial AArch64 bringup and 
> > had
> > assumed it was fixed since the addition of the MMU code since that 
> > instruction
> > doesn't work on device memory.
>
> It this that instruction ...
>
> 100125c0:   d50b7423dc  zva, x3
>
> Looks like it is not fixed.

I think your suggestion that FreeBSD should not use memset for device memory
is the right path though. But that could be in a lot of places. :(

>
> > It looks like bsp_section_nocacheheap sits inside bsp_section_nocachenoload
> > which is mapped as device memory which wouldn't play nicely with the "dc 
> > zva"
> > instruction.
> Cache coherent memory is mapped as device memory. The descriptors are mapped
> into it so checks of bits and updates are effected by caches.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB] rtems-tools-6.cfg: Bump hash to include MicroBlaze

2021-10-18 Thread Chris Johns 
OK and thanks

Chris

On 19/10/21 2:09 am, Alex White wrote:
> Hash: 323007a6b520140a20b2e268c90b78ff67afaf45
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index cfb..4158753 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 40a7058bd4d7681ca6be7a14f09a1275ea4fbde4
> + %define rtems_tools_version 323007a6b520140a20b2e268c90b78ff67afaf45
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> nlwNKLP2UXRMRfK0SU0Bpd+9sOvRoRaXRRTj0lzx9jkqGMwwU4lB19uLhTnH88u1jGOrhVSkNunIHvbi9SayAg==
> + 
> yo5i1HEaYyOOX8JJGr+kok0vIEZGpXjeZmA44gqTow101PhtlwhebvgTS0SeMe8L68wTDqdjZe5QVnsjKgYOhw==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

2021-10-18 Thread Chris Johns 
On 19/10/21 3:53 am, Kinsey Moore wrote:
> On 10/18/2021 00:44, Chris Johns wrote:
>> 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.
> 
> I'm running with a toolchain that was built with
> --targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of the
> memset function, so my memset is just loops of writes and seems to work fine.

Oh. Maybe the eng manual needs a piece on this. Using flags on tool chains like
this is fine for a user because it is use at your own peril however I believe
patches need to be tested with the defaults for all tools. It is way to hard to
baseline a BSP if tweaks are needed here and there.

> Just out of curiousity, what instruction was at that PC address? If it was "dc
> zva", then I had seen this a while back during initial AArch64 bringup and had
> assumed it was fixed since the addition of the MMU code since that instruction
> doesn't work on device memory.

It this that instruction ...

100125c0:   d50b7423dc  zva, x3

Looks like it is not fixed.

> It looks like bsp_section_nocacheheap sits inside bsp_section_nocachenoload
> which is mapped as device memory which wouldn't play nicely with the "dc zva"
> instruction.
Cache coherent memory is mapped as device memory. The descriptors are mapped
into it so checks of bits and updates are effected by caches.

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

Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

2021-10-18 Thread Chris Johns 
On 18/10/21 8:37 pm, Sebastian Huber wrote:
> On 18/10/2021 09:53, Chris Johns wrote:
>> On 18/10/21 4:50 pm, Sebastian Huber wrote:
>>> 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.
>> That seems reasonable however this change about testing the implicit
>> requirements we have that memset works. LibBSD requires memset works ...
>>
>> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260
>>
> 
> Using memset() here could be a bug in libbsd.

Yes, I also think so.

But what is a suitable mechanism to make sure the arch or BSP handle it
correctly? Maybe a clear routine in libbsd using the bus space API? That
interface has to work or the drivers will not work.

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

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

2021-10-18 Thread Kinsey Moore 

On 10/18/2021 00:44, Chris Johns wrote:

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.


I'm running with a toolchain that was built with 
--targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of 
the memset function, so my memset is just loops of writes and seems to 
work fine. Just out of curiousity, what instruction was at that PC 
address? If it was "dc zva", then I had seen this a while back during 
initial AArch64 bringup and had assumed it was fixed since the addition 
of the MMU code since that instruction doesn't work on device memory.



It looks like bsp_section_nocacheheap sits inside 
bsp_section_nocachenoload which is mapped as device memory which 
wouldn't play nicely with the "dc zva" instruction.



Kinsey

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

[PATCH RSB] rtems-tools-6.cfg: Bump hash to include MicroBlaze

2021-10-18 Thread Alex White 
Hash: 323007a6b520140a20b2e268c90b78ff67afaf45
---
 rtems/config/tools/rtems-tools-6.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-6.cfg 
b/rtems/config/tools/rtems-tools-6.cfg
index cfb..4158753 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
  %define rtems_tools_ext xz
 %else
- %define rtems_tools_version 40a7058bd4d7681ca6be7a14f09a1275ea4fbde4
+ %define rtems_tools_version 323007a6b520140a20b2e268c90b78ff67afaf45
  %define rtems_tools_ext bz2
 %endif
 
 %define rtems_tools_source rtems-tools-%{rtems_tools_version}
 %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
 %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
- 
nlwNKLP2UXRMRfK0SU0Bpd+9sOvRoRaXRRTj0lzx9jkqGMwwU4lB19uLhTnH88u1jGOrhVSkNunIHvbi9SayAg==
+ 
yo5i1HEaYyOOX8JJGr+kok0vIEZGpXjeZmA44gqTow101PhtlwhebvgTS0SeMe8L68wTDqdjZe5QVnsjKgYOhw==
 
 #
 # Optionally enable/disable building the RTEMS Tools via the command line.
-- 
2.32.0

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

Re:

2021-10-18 Thread Alex White 
Hi,

Ignore this. It looks like my ".patch" file was malformed somehow. I will see 
if I can fix it and resend.

Alex

From: devel  on behalf of Alex White 

Sent: Monday, October 18, 2021 10:01 AM
To: devel@rtems.org 
Subject:

>From c47d01739f2abf79a1423ea3cdcc7e98c621b222 Mon Sep 17 00:00:00 2001
From: Alex White 
Date: Thu, 14 Oct 2021 01:44:08 -0500
Subject: [PATCH RSB] rtems-tools-6.cfg: Bump hash to include MicroBlaze

Hash: 323007a6b520140a20b2e268c90b78ff67afaf45
---
 rtems/config/tools/rtems-tools-6.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-6.cfg 
b/rtems/config/tools/rtems-tools-6.cfg
index cfb..4158753 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
  %define rtems_tools_ext xz
 %else
- %define rtems_tools_version 40a7058bd4d7681ca6be7a14f09a1275ea4fbde4
+ %define rtems_tools_version 323007a6b520140a20b2e268c90b78ff67afaf45
  %define rtems_tools_ext bz2
 %endif

 %define rtems_tools_source rtems-tools-%{rtems_tools_version}
 %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
 %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
- 
nlwNKLP2UXRMRfK0SU0Bpd+9sOvRoRaXRRTj0lzx9jkqGMwwU4lB19uLhTnH88u1jGOrhVSkNunIHvbi9SayAg==
+ 
yo5i1HEaYyOOX8JJGr+kok0vIEZGpXjeZmA44gqTow101PhtlwhebvgTS0SeMe8L68wTDqdjZe5QVnsjKgYOhw==

 #
 # Optionally enable/disable building the RTEMS Tools via the command line.
--
2.32.0

___
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

[no subject]

2021-10-18 Thread Alex White 
>From c47d01739f2abf79a1423ea3cdcc7e98c621b222 Mon Sep 17 00:00:00 2001
From: Alex White 
Date: Thu, 14 Oct 2021 01:44:08 -0500
Subject: [PATCH RSB] rtems-tools-6.cfg: Bump hash to include MicroBlaze

Hash: 323007a6b520140a20b2e268c90b78ff67afaf45
---
 rtems/config/tools/rtems-tools-6.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-tools-6.cfg 
b/rtems/config/tools/rtems-tools-6.cfg
index cfb..4158753 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
  %define rtems_tools_ext xz
 %else
- %define rtems_tools_version 40a7058bd4d7681ca6be7a14f09a1275ea4fbde4
+ %define rtems_tools_version 323007a6b520140a20b2e268c90b78ff67afaf45
  %define rtems_tools_ext bz2
 %endif
 
 %define rtems_tools_source rtems-tools-%{rtems_tools_version}
 %source set rtems-tools 
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
 %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
- 
nlwNKLP2UXRMRfK0SU0Bpd+9sOvRoRaXRRTj0lzx9jkqGMwwU4lB19uLhTnH88u1jGOrhVSkNunIHvbi9SayAg==
+ 
yo5i1HEaYyOOX8JJGr+kok0vIEZGpXjeZmA44gqTow101PhtlwhebvgTS0SeMe8L68wTDqdjZe5QVnsjKgYOhw==
 
 #
 # Optionally enable/disable building the RTEMS Tools via the command line.
-- 
2.32.0

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

Re: [PATCH 3/3] bsps/aarch64: use SMC API in bspreset-arm-psci

2021-10-18 Thread Kinsey Moore 

Comments below.

On 10/16/2021 15:12, Gedare Bloom wrote:

---
  bsps/shared/start/bspreset-arm-psci.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/bsps/shared/start/bspreset-arm-psci.c 
b/bsps/shared/start/bspreset-arm-psci.c
index 215be5c9b5..bafdfe6299 100644
--- a/bsps/shared/start/bspreset-arm-psci.c
+++ b/bsps/shared/start/bspreset-arm-psci.c
@@ -37,9 +37,28 @@
  #include 
  #include 
  
+#if defined( AARCH64_MULTILIB_ARCH_V8 ) || \

+  defined( AARCH64_MULTILIB_ARCH_V8_ILP32 )
+#include 
+#endif
+
  void bsp_reset(void)
  {
uint32_t PSCI_FN_SYSTEM_RESET = 0x8409;
+#ifdef BSP_RESET_SMC
+  (void) _AArch64_SMC_Invoke(
+  PSCI_FN_SYSTEM_RESET,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  NULL
+  );
+#else
__asm__ volatile(
  #if defined(AARCH64_MULTILIB_ARCH_V8) || 
defined(AARCH64_MULTILIB_ARCH_V8_ILP32)
"mov x0, %0\n"
@@ -53,4 +72,5 @@ void bsp_reset(void)
  #endif

This leaves dead code just above the break in this patch.

: : "r" (PSCI_FN_SYSTEM_RESET)
);
+#endif
  }



The existing PSCI functionality was coded such that both ARM and AArch64 
could use it in either mode. The way this has been added breaks SMC 
conduit functionality on 32-bit ARM for both secondary CPU startup and 
system reset.



Kinsey

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

Re: [PATCH 1/3] aarch64: add internal API for secure monitor call (smc)

2021-10-18 Thread Kinsey Moore 

Comments inline below.

On 10/16/2021 15:12, Gedare Bloom wrote:

---
  cpukit/score/cpu/aarch64/aarch64-smc.c| 72 
  .../aarch64/include/rtems/score/aarch64-smc.h | 84 +++
  spec/build/cpukit/cpuaarch64.yml  |  2 +
  3 files changed, 158 insertions(+)
  create mode 100644 cpukit/score/cpu/aarch64/aarch64-smc.c
  create mode 100644 cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h

diff --git a/cpukit/score/cpu/aarch64/aarch64-smc.c 
b/cpukit/score/cpu/aarch64/aarch64-smc.c
new file mode 100644
index 00..4cfee91a0b
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/aarch64-smc.c
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ *  @file
+ *
+ *  @brief Secure Monitor Call
+ */
+
+/*
+ * Copyright (C) 2021 Gedare Bloom 
+ *
+ * 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 OWNER 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+int _AArch64_SMC_Invoke(
+  int function_id,

Nit: The function ID should be uint32_t.

+  uintptr_t arg0,
+  uintptr_t arg1,
+  uintptr_t arg2,
+  uintptr_t arg3,
+  uintptr_t arg4,
+  uintptr_t arg5,
+  uintptr_t arg6,
+  uintptr_t arg7,
Only arguments 0-7 are passed in registers according to the AAPCS64. 
arg7 here would be the 9th argument and thus passed on the stack which 
is incompatible with the SMC calling convention which exclusively uses 
registers for passing arguments. It should be fine to drop this argument 
since we're not yet using any PSCI functionality that requires that many 
arguments.

+  AArch64_SMC_Return *result
+) {
+  int rv;
+
+  /* This only works for SMC that return 4 or fewer results. It may be extended
+   * up to the full 18 return results specified for SMC64, but then we would
+   * need to allocate a callee-saved register for *result */
+  __asm__ volatile(
+"smc  #0\n"
+"mov  %0, x0\n"
+"ldr  x15, [sp]\n"
+"cbz  x15, 0f\n"
+"stp  x0, x1, [x15]\n"
+"stp  x2, x3, [x15, #16]\n"
+"0:\n"
+: "=r" ( rv )
+:
+: "x0", "x1", "x2", "x3", "x15"
+  );
+
+  return rv;
+}
+
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h
new file mode 100644
index 00..04f99f8bf3
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPUAArch64
+ *
+ * @brief This header file provides API to wrap secure monitor calls (smc).
+ */
+
+/*
+ * Copyright (C) 2021 Gedare Bloom 
+ *
+ * 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 OWNER 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,

[PATCH] score: Move code block to separate function

2021-10-18 Thread Sebastian Huber 
Move a code block to the new function _Thread_Scheduler_withdraw_nodes()
to make ease code review.
---
 cpukit/score/src/threadscheduler.c | 58 --
 1 file changed, 32 insertions(+), 26 deletions(-)

diff --git a/cpukit/score/src/threadscheduler.c 
b/cpukit/score/src/threadscheduler.c
index 19459e8dec..89d863d080 100644
--- a/cpukit/score/src/threadscheduler.c
+++ b/cpukit/score/src/threadscheduler.c
@@ -29,6 +29,36 @@
 #include 
 
 #if defined(RTEMS_SMP)
+static void _Thread_Scheduler_withdraw_nodes(
+  Thread_Control *the_thread,
+  Scheduler_Node *scheduler_node
+)
+{
+  while ( scheduler_node != NULL ) {
+Scheduler_Node  *next;
+const Scheduler_Control *scheduler;
+ISR_lock_Context lock_context;
+
+next = scheduler_node->Thread.Scheduler_node.next;
+#if defined(RTEMS_DEBUG)
+scheduler_node->Thread.Scheduler_node.next = NULL;
+#endif
+
+scheduler = _Scheduler_Node_get_scheduler( scheduler_node );
+
+_Scheduler_Acquire_critical( scheduler, &lock_context );
+( *scheduler->Operations.withdraw_node )(
+  scheduler,
+  the_thread,
+  scheduler_node,
+  THREAD_SCHEDULER_READY
+);
+_Scheduler_Release_critical( scheduler, &lock_context );
+
+scheduler_node = next;
+  }
+}
+
 void _Thread_Scheduler_process_requests( Thread_Control *the_thread )
 {
   ISR_lock_Context  lock_context;
@@ -39,7 +69,6 @@ void _Thread_Scheduler_process_requests( Thread_Control 
*the_thread )
   scheduler_node = the_thread->Scheduler.requests;
 
   if ( scheduler_node != NULL ) {
-Scheduler_Node *next;
 Scheduler_Node *remove;
 
 the_thread->Scheduler.requests = NULL;
@@ -47,6 +76,7 @@ void _Thread_Scheduler_process_requests( Thread_Control 
*the_thread )
 
 do {
   Scheduler_Node_request request;
+  Scheduler_Node*next;
 
   request = scheduler_node->Thread.request;
   scheduler_node->Thread.request = SCHEDULER_NODE_REQUEST_NOT_PENDING;
@@ -77,31 +107,7 @@ void _Thread_Scheduler_process_requests( Thread_Control 
*the_thread )
 } while ( scheduler_node != NULL );
 
 _Thread_Scheduler_release_critical( the_thread, &lock_context );
-
-scheduler_node = remove;
-
-while ( scheduler_node != NULL ) {
-  const Scheduler_Control *scheduler;
-  ISR_lock_Context lock_context;
-
-  next = scheduler_node->Thread.Scheduler_node.next;
-#if defined(RTEMS_DEBUG)
-  scheduler_node->Thread.Scheduler_node.next = NULL;
-#endif
-
-  scheduler = _Scheduler_Node_get_scheduler( scheduler_node );
-
-  _Scheduler_Acquire_critical( scheduler, &lock_context );
-  ( *scheduler->Operations.withdraw_node )(
-scheduler,
-the_thread,
-scheduler_node,
-THREAD_SCHEDULER_READY
-  );
-  _Scheduler_Release_critical( scheduler, &lock_context );
-
-  scheduler_node = next;
-}
+_Thread_Scheduler_withdraw_nodes( the_thread, remove );
   } else {
 _Thread_Scheduler_release_critical( the_thread, &lock_context );
   }
-- 
2.31.1

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

Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

2021-10-18 Thread Sebastian Huber 

On 18/10/2021 09:53, Chris Johns wrote:

On 18/10/21 4:50 pm, Sebastian Huber wrote:

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.

That seems reasonable however this change about testing the implicit
requirements we have that memset works. LibBSD requires memset works ...

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260


Using memset() here could be a bug in libbsd.

--
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: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

2021-10-18 Thread Chris Johns 
On 18/10/21 4:50 pm, Sebastian Huber wrote:
> 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.

That seems reasonable however this change about testing the implicit
requirements we have that memset works. LibBSD requires memset works ...

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260

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