[U-Boot] [PATCH 0/2] efi_loader: enable unaligned access on arm11
The UEFI specification mandates that unaligned access must be enabled on systems supporting it.
Function unaligned access is implemented for arm1136 and arm1176. EFI_LOADER is enabled for these architectures.
Heinrich Schuchardt (2): arm: arm11: allow unaligned memory access efi_loader: enable EFI_LOADER on arm1136 and arm1176
arch/arm/cpu/arm11/Makefile | 4 ++++ arch/arm/cpu/arm11/sctlr.S | 25 +++++++++++++++++++++++++ lib/efi_loader/Kconfig | 6 ++++-- 3 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/arm11/sctlr.S
-- 2.24.0
The UEFI spec mandates that unaligned memory access should be enabled if supported by the CPU architecture.
This patch implements the function unaligned_access() to set the enable unaligned data support flag and to clear the aligned flag in the system control register (SCTLR). It is called when UEFI related commands like bootefi are invoked.
Reported-by: Cristian Ciocaltea cristian.ciocaltea@gmail.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- arch/arm/cpu/arm11/Makefile | 4 ++++ arch/arm/cpu/arm11/sctlr.S | 25 +++++++++++++++++++++++++ 2 files changed, 29 insertions(+) create mode 100644 arch/arm/cpu/arm11/sctlr.S
diff --git a/arch/arm/cpu/arm11/Makefile b/arch/arm/cpu/arm11/Makefile index 5d721fce12..5dfa01ae8d 100644 --- a/arch/arm/cpu/arm11/Makefile +++ b/arch/arm/cpu/arm11/Makefile @@ -4,3 +4,7 @@ # Wolfgang Denk, DENX Software Engineering, wd@denx.de.
obj-y = cpu.o + +ifneq ($(CONFIG_SPL_BUILD),y) +obj-$(CONFIG_EFI_LOADER) += sctlr.o +endif diff --git a/arch/arm/cpu/arm11/sctlr.S b/arch/arm/cpu/arm11/sctlr.S new file mode 100644 index 0000000000..74a7fc4a25 --- /dev/null +++ b/arch/arm/cpu/arm11/sctlr.S @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Routines to access the system control register + * + * Copyright (c) 2019 Heinrich Schuchardt + */ + +#include <linux/linkage.h> + +/* + * void allow_unaligned(void) - allow unaligned access + * + * This routine sets the enable unaligned data support flag and clears the + * aligned flag in the system control register. + * After calling this routine unaligned access does no longer leads to a + * data abort or undefined behavior but is handled by the CPU. + * For details see the "ARM Architecture Reference Manual" for ARMv6. + */ +ENTRY(allow_unaligned) + mrc p15, 0, r0, c1, c0, 0 @ load system control register + orr r0, r0, #1 << 22 @ set unaligned data support flag + bic r0, r0, #2 @ clear aligned flag + mcr p15, 0, r0, c1, c0, 0 @ write system control register + bx lr @ return +ENDPROC(allow_unaligned) -- 2.24.0
With an implementation for allow_unaligned() available for arm1136 and arm1176 UEFI can be supported on these architectures.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- lib/efi_loader/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 2f40e485ef..7984d6f42d 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,8 +1,10 @@ config EFI_LOADER bool "Support running UEFI applications" depends on OF_LIBFDT && ( \ - ARM && (SYS_CPU = armv7 || \ - SYS_CPU = armv8) || \ + ARM && (SYS_CPU = arm1136 || \ + SYS_CPU = arm1176 || \ + SYS_CPU = armv7 || \ + SYS_CPU = armv8) || \ X86 || RISCV || SANDBOX) # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT -- 2.24.0
On Tue, Nov 19, 2019 at 04:35:57AM +0100, Heinrich Schuchardt wrote:
With an implementation for allow_unaligned() available for arm1136 and arm1176 UEFI can be supported on these architectures.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
lib/efi_loader/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 2f40e485ef..7984d6f42d 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,8 +1,10 @@ config EFI_LOADER bool "Support running UEFI applications" depends on OF_LIBFDT && ( \
ARM && (SYS_CPU = armv7 || \SYS_CPU = armv8) || \
ARM && (SYS_CPU = arm1136 || \SYS_CPU = arm1176 || \SYS_CPU = armv7 || \SYS_CPU = armv8) || \
My concern is that while it's good and important we're correcting the dependencies for ARM, non-ARMv7 hardware is much more legacy than new design and we maybe don't want to have it enabled by default there. One of the biggest pieces of feedback I have gotten over the overall EFI support is that it being on by default on legacy systems causes a lot of unwanted size growth. Does Kconfig work sanely with something like: default y if !ARM default y if ARM && (SYS_CPU = armv7 || SYS_CPU == arv8) ? Then we could allow other older ARM systems to enable it still and now function (again, good work) without the size growth by default. Thanks!
On 11/19/19 4:22 PM, Tom Rini wrote:
On Tue, Nov 19, 2019 at 04:35:57AM +0100, Heinrich Schuchardt wrote:
With an implementation for allow_unaligned() available for arm1136 and arm1176 UEFI can be supported on these architectures.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
lib/efi_loader/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 2f40e485ef..7984d6f42d 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,8 +1,10 @@ config EFI_LOADER bool "Support running UEFI applications" depends on OF_LIBFDT && ( \
ARM && (SYS_CPU = armv7 || \SYS_CPU = armv8) || \
ARM && (SYS_CPU = arm1136 || \SYS_CPU = arm1176 || \SYS_CPU = armv7 || \SYS_CPU = armv8) || \My concern is that while it's goodk and important we're correcting the dependencies for ARM, non-ARMv7 hardware is much more legacy than new design and we maybe don't want to have it enabled by default there. One of the biggest pieces of feedback I have gotten over the overall EFI support is that it being on by default on legacy systems causes a lot of unwanted size growth. Does Kconfig work sanely with something like: default y if !ARM default y if ARM && (SYS_CPU = armv7 || SYS_CPU == arv8) ? Then we could allow other older ARM systems to enable it still and now function (again, good work) without the size growth by default. Thanks!
These are the only ARM11 boards:
evb-ast2500_defconfig flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
Which one poses a problem?
Best regards
Heinrich
On Tue, Nov 19, 2019 at 07:11:46PM +0100, Heinrich Schuchardt wrote:
On 11/19/19 4:22 PM, Tom Rini wrote:
On Tue, Nov 19, 2019 at 04:35:57AM +0100, Heinrich Schuchardt wrote:
With an implementation for allow_unaligned() available for arm1136 and arm1176 UEFI can be supported on these architectures.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
lib/efi_loader/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 2f40e485ef..7984d6f42d 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,8 +1,10 @@ config EFI_LOADER bool "Support running UEFI applications" depends on OF_LIBFDT && ( \
ARM && (SYS_CPU = armv7 || \SYS_CPU = armv8) || \
ARM && (SYS_CPU = arm1136 || \SYS_CPU = arm1176 || \SYS_CPU = armv7 || \SYS_CPU = armv8) || \My concern is that while it's goodk and important we're correcting the dependencies for ARM, non-ARMv7 hardware is much more legacy than new design and we maybe don't want to have it enabled by default there. One of the biggest pieces of feedback I have gotten over the overall EFI support is that it being on by default on legacy systems causes a lot of unwanted size growth. Does Kconfig work sanely with something like: default y if !ARM default y if ARM && (SYS_CPU = armv7 || SYS_CPU == arv8) ? Then we could allow other older ARM systems to enable it still and now function (again, good work) without the size growth by default. Thanks!
These are the only ARM11 boards:
evb-ast2500_defconfig flea3_defconfig integratorcp_cm1136_defconfig mx31pdk_defconfig mx35pdk_defconfig rpi_0_w_defconfig rpi_defconfig woodburn_defconfig woodburn_sd_defconfig
Which one poses a problem?
Of those, I would assume the two Pi boards might opt-in, maybe the aspeed board and not the rest.
participants (2)
-
Heinrich Schuchardt -
Tom Rini