On 10/08/2021 09.13, Stefan Roese wrote:
The optimized memset uses the dc opcode, which causes problems when the cache is disabled. This patch adds a check if the cache is disabled and uses a very simple memset implementation in this case. Otherwise the optimized version is used.
Signed-off-by: Stefan Roese sr@denx.de
Changes in v2:
- New patch
arch/arm/lib/memset-arm64.S | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S index 710f6f582cad..a474dcb53c83 100644 --- a/arch/arm/lib/memset-arm64.S +++ b/arch/arm/lib/memset-arm64.S @@ -11,6 +11,7 @@
*/
+#include <asm/macro.h> #include "asmdefs.h"
#define dstin x0 @@ -25,6 +26,35 @@ ENTRY (memset) PTR_ARG (0) SIZE_ARG (2)
- /*
* The optimized memset uses the dc opcode, which causes problems* when the cache is disabled. Let's check if the cache is disabled* and use a very simple memset implementation in this case. Otherwise* jump to the optimized version.*/- switch_el x6, 3f, 2f, 1f
+3: mrs x6, sctlr_el3
- b 0f
+2: mrs x6, sctlr_el2
- b 0f
+1: mrs x6, sctlr_el1 +0:
- tst x6, #CR_C
- bne 9f
How costly is this switch_el and access to a control register? For a "big" memset of several 100s of bytes I'm sure it's a net win regardless. But smaller memsets are much more common, and no individual memset would show up in any boot time "profiling", but it is possible that the extra cost added to those smaller memsets adds up to some significant penalty.
- /*
* A very "simple" memset implementation without the use of the* dc opcode. Can be run with caches disabled.*/- mov x3, #0x0
+4: strb w1, [x0, x3]
- add x3, x3, #0x1
- cmp x2, x3
- bne 4b
- ret
+9:
So I can hardly claim to be fluent in aarch64, but AFAICT this does return the destination pointer as it must (because it leaves x0 untouched throughout). However, it fails (by writing over all of memory) when the size is 0, since it is essentially a do{}while and not a while{}.
Rasmus