Re: Ticket 4503

2021-12-11 Thread Gedare Bloom 
On Thu, Nov 18, 2021 at 7:22 PM zack leung  wrote:
>
> bump
>
> On Mon, 18 Oct 2021 at 23:58, zack leung  wrote:
>
> > 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;
> >>>

No, this is calculating the size of 'this block' considering that it's
allocated memory starts at "alloc_begin" and it ends at the
"next_block" heap block metadata or header. You should read about how
malloc implementations generally work. The allocated memory has some
metadata before it to implement the linked data structures necessary
to support dynamic allocation. So a block is the header + allocated
range. Only the allocated range plus any excess before the next
block's header is considered usable.

> >>> >(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?
> >>>

You would have to see if the Protected Heap implementation has some
additional metadata between the end of an allocated range in one block
and the block header in the next. I don't think it matters too much
because most of the 'protected' aspects have to do with free block
management. But that should be confirmed.

The check is not "if it's been previously used" I suggest that you
look at what the invoked function does and how it is documented. Avoid
making assumptions based on names.

The usable memory is NOT the size of the block * # of blocks, because
the size of the block includes the header.

> >>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 0/3] Add Secure Monitor Call API

2021-12-11 Thread Gedare Bloom 
These patches add and use an internal API to make
secure monitor call (SMC) invocations. SMC is used
currently in aarch64 for secondary processor boot
and bsp_reset. Although SMC is available on arm, it
does not appear to be currently used by any of arm
BSPs. So the current approach is only implemented
in the aarch64. Replicating the implementation for
arm (with SMC32) should be simple if needed, but
the placement of the API may need some more thought.
Currently, the only place that aarch64 and arm can
easily share code is underneath bsps/shared.
Also, it should be straightforward to add a similar
API for hypervisor call (HVC) invocations.

v2: address comments from reviewers (Sebastian, Kinsey)

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

 bsps/shared/start/bspreset-arm-psci.c | 41 +++--
 bsps/shared/start/bspsmp-arm-psci.c   | 19 -
 cpukit/score/cpu/aarch64/aarch64-smc.c| 72 
 .../aarch64/include/rtems/score/aarch64-smc.h | 83 +++
 spec/build/cpukit/cpuaarch64.yml  |  2 +
 5 files changed, 205 insertions(+), 12 deletions(-)
 create mode 100644 cpukit/score/cpu/aarch64/aarch64-smc.c
 create mode 100644 cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h

-- 
2.25.1

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

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

2021-12-11 Thread Gedare Bloom 
---
 cpukit/score/cpu/aarch64/aarch64-smc.c| 72 
 .../aarch64/include/rtems/score/aarch64-smc.h | 83 +++
 spec/build/cpukit/cpuaarch64.yml  |  2 +
 3 files changed, 157 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..c531d074d8
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/aarch64-smc.c
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ *  @file
+ *
+ *  @brief This source file contains the implementation of
+ *_AArch64_SMC_Invoke().
+ */
+
+/*
+ * 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(
+  uint32_t function_id,
+  uintptr_t arg0,
+  uintptr_t arg1,
+  uintptr_t arg2,
+  uintptr_t arg3,
+  uintptr_t arg4,
+  uintptr_t arg5,
+  uintptr_t arg6,
+  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..e80cc1e99b
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h
@@ -0,0 +1,83 @@
+/* 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, 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.
+ */
+
+#ifndef _RTEMS_SCORE_AARCH64_SMC_H
+#define _RTEMS_SCORE_AARCH64_SMC_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @defgroup RTEMSScoreCPUAArch64SMC Secure Monitor Call Support
+ *
+ * @ingroup RTEMSScoreCPUAArch64

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

2021-12-11 Thread Gedare Bloom 
---
 bsps/shared/start/bspreset-arm-psci.c | 41 +--
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/bsps/shared/start/bspreset-arm-psci.c 
b/bsps/shared/start/bspreset-arm-psci.c
index 215be5c9b5..aa039b7816 100644
--- a/bsps/shared/start/bspreset-arm-psci.c
+++ b/bsps/shared/start/bspreset-arm-psci.c
@@ -37,20 +37,45 @@
 #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;
-   __asm__ volatile(
+  uint32_t PSCI_FN_SYSTEM_RESET = 0x8409;
 #if defined(AARCH64_MULTILIB_ARCH_V8) || 
defined(AARCH64_MULTILIB_ARCH_V8_ILP32)
-   "mov x0, %0\n"
+#ifdef BSP_RESET_SMC
+  (void) _AArch64_SMC_Invoke(
+  PSCI_FN_SYSTEM_RESET,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  NULL
+  );
 #else
-   "mov r0, %0\n"
+  /* _AArch64_HVC_Invoke */
+  __asm__ volatile(
+"mov x0, %0\n"
+"hvc #0\n"
+: : "r" (PSCI_FN_SYSTEM_RESET)
+  );
 #endif
+#else
+  /* _AArch32 */
+  __asm__ volatile(
+"mov r0, %0\n"
 #ifdef BSP_RESET_SMC
-   "smc #0\n"
+"smc #0\n"
 #else
-   "hvc #0\n"
+"hvc #0\n"
+#endif
+: : "r" (PSCI_FN_SYSTEM_RESET)
+  );
 #endif
-   : : "r" (PSCI_FN_SYSTEM_RESET)
-   );
 }
-- 
2.25.1

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

[PATCH v2 2/3] bsps/aarch64: use SMC API in bspsmp-arm-psci

2021-12-11 Thread Gedare Bloom 
---
 bsps/shared/start/bspsmp-arm-psci.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/start/bspsmp-arm-psci.c 
b/bsps/shared/start/bspsmp-arm-psci.c
index 1ff5b7bb89..77fa3cc816 100644
--- a/bsps/shared/start/bspsmp-arm-psci.c
+++ b/bsps/shared/start/bspsmp-arm-psci.c
@@ -41,6 +41,7 @@
 #if defined( AARCH64_MULTILIB_ARCH_V8 ) || \
   defined( AARCH64_MULTILIB_ARCH_V8_ILP32 )
 #include 
+#include 
 #else
 #include 
 #endif
@@ -67,22 +68,32 @@ bool _CPU_SMP_Start_processor( uint32_t cpu_index )
   target_cpu &= ~( 0xffffUL );
   target_cpu |= cpu_index;
 
+#ifdef BSP_CPU_ON_USES_SMC
+  ret = _AArch64_SMC_Invoke(
+  PSCI_FN_SYSTEM_CPU_ON,
+  target_cpu,
+  _start,
+  0,
+  0,
+  0,
+  0,
+  0,
+  NULL
+  );
+#else
   __asm__ volatile (
 "mov " REGISTER_PREFIX "0, %1\n"
 "mov " REGISTER_PREFIX "1, %2\n"
 "mov " REGISTER_PREFIX "2, %3\n"
 "mov " REGISTER_PREFIX "3, #0\n"
-#ifdef BSP_CPU_ON_USES_SMC
-"smc #0\n"
-#else
 "hvc #0\n"
-#endif
 "mov %0, " REGISTER_PREFIX "0\n"
 : "=r" ( ret ) : "r" ( PSCI_FN_SYSTEM_CPU_ON ), "r" ( target_cpu ),
 "r" ( _start )
 : REGISTER_PREFIX "0", REGISTER_PREFIX "1", REGISTER_PREFIX "2",
 REGISTER_PREFIX "3"
   );
+#endif
 
   if ( ret != 0 ) {
 return false;
-- 
2.25.1

___
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-12-11 Thread Gedare Bloom 
On Mon, Oct 18, 2021 at 8:18 AM Kinsey Moore  wrote:
>
> 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.

Nice catch, thanks for this one. It would have messed up the return values.
___
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-12-11 Thread Gedare Bloom 
On Mon, Oct 18, 2021 at 8:40 AM Kinsey Moore  wrote:
>
> 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.
>
I decided to separate the two cases (aarch64/32) a little bit more
cleanly to resolve this issue. Thanks for the review!

>
> Kinsey
>
> ___
> 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] bsps/aarch64: Remove erroneous cache feature

2021-12-11 Thread Gedare Bloom 
On Fri, Dec 10, 2021 at 10:19 AM Sebastian Huber
 wrote:
>
> On 10/12/2021 16:49, Kinsey Moore wrote:
> > The AArch64 cache implementation does not define
> > rtems_cache_disable_data(), but declares that it does via
> > CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA. The existing implementation of
> > _CPU_cache_disable_data() is sufficient to enable this functionality
> > without the erroneous cache feature flag.
> >
> > Closes #4569
>
> Thanks, please check it in.
>
> At least for ARMv7 we have an assembler implementation for this function:
>
> bsps/arm/shared/cache/cache-v7ar-disable-data.S
>
Basically the same code should work for aarch64, replacing the access
with SCTLR_EL3
mrs x0, SCTLR_EL1
bic x0, x0, #0x4
msr SCTLR_EL1, x0
isb


> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/aarch64: Remove erroneous cache feature

2021-12-11 Thread Gedare Bloom 
On Sat, Dec 11, 2021 at 11:18 AM Gedare Bloom  wrote:
>
> On Fri, Dec 10, 2021 at 10:19 AM Sebastian Huber
>  wrote:
> >
> > On 10/12/2021 16:49, Kinsey Moore wrote:
> > > The AArch64 cache implementation does not define
> > > rtems_cache_disable_data(), but declares that it does via
> > > CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA. The existing implementation of
> > > _CPU_cache_disable_data() is sufficient to enable this functionality
> > > without the erroneous cache feature flag.
> > >
> > > Closes #4569
> >
> > Thanks, please check it in.
> >
> > At least for ARMv7 we have an assembler implementation for this function:
> >
> > bsps/arm/shared/cache/cache-v7ar-disable-data.S
> >
> Basically the same code should work for aarch64, replacing the access
> with SCTLR_EL3
I meant EL1 :) the following code snippet should work anyway.

> mrs x0, SCTLR_EL1
> bic x0, x0, #0x4
> msr SCTLR_EL1, x0
> isb
>
>
> > --
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel