Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 10:48:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/cpu/armv8/Kconfig

148 lines
5.4 KiB
Text
Raw Normal View History

armv8/vexpress64: make multientry conditional While the Freescale ARMv8 board LS2085A will enter U-Boot both on a master and a secondary (slave) CPU, this is not the common behaviour on ARMv8 platforms. The norm is that U-Boot is entered from the master CPU only, while the other CPUs are kept in WFI (wait for interrupt) state. The code determining which CPU we are running on is using the MPIDR register, but the definition of that register varies with platform to some extent, and handling multi-cluster platforms (such as the Juno) will become cumbersome. It is better to only enable the multiple entry code on machines that actually need it and disable it by default. Make the single entry default and add a special ARMV8_MULTIENTRY KConfig option to be used by the platforms that need multientry and set it for the LS2085A. Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 boards as it is just totally unused and misleading, and make it conditional in the generic start.S code. This makes the Juno platform start U-Boot properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-09 09:53:21 +00:00
if ARM64
config ARMV8_MULTIENTRY
kconfig: use bool instead of boolean for type definition attributes Linux stopped the use of keyword 'boolean' in Kconfig. Refer to commit 6341e62b212a2541efb0160c470e90bd226d5496 ("kconfig: use bool instead of boolean for type definition attributes") in Linux Kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-08-12 01:26:50 +00:00
bool "Enable multiple CPUs to enter into U-Boot"
armv8/vexpress64: make multientry conditional While the Freescale ARMv8 board LS2085A will enter U-Boot both on a master and a secondary (slave) CPU, this is not the common behaviour on ARMv8 platforms. The norm is that U-Boot is entered from the master CPU only, while the other CPUs are kept in WFI (wait for interrupt) state. The code determining which CPU we are running on is using the MPIDR register, but the definition of that register varies with platform to some extent, and handling multi-cluster platforms (such as the Juno) will become cumbersome. It is better to only enable the multiple entry code on machines that actually need it and disable it by default. Make the single entry default and add a special ARMV8_MULTIENTRY KConfig option to be used by the platforms that need multientry and set it for the LS2085A. Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 boards as it is just totally unused and misleading, and make it conditional in the generic start.S code. This makes the Juno platform start U-Boot properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-09 09:53:21 +00:00
armv8: Enable CPUECTLR.SMPEN for coherency For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is set. The SMPEN bit should be set before enabling the data cache. If not enabled, the cache is not coherent with other cores and data corruption could occur. For A57/A72, SMPEN bit enables the processor to receive instruction cache and TLB maintenance operations broadcast from other processors in the cluster. This bit should be set before enabling the caches and MMU, or performing any cache and TLB maintenance operations. Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com> Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2017-01-06 09:41:10 +00:00
config ARMV8_SET_SMPEN
bool "Enable data coherency with other cores in cluster"
help
Say Y here if there is not any trust firmware to set
CPUECTLR_EL1.SMPEN bit before U-Boot.
For A53, it enables data coherency with other cores in the
cluster, and for A57/A72, it enables receiving of instruction
cache and TLB maintenance operations.
Cortex A53/57/72 cores require CPUECTLR_EL1.SMPEN set even
for single core systems. Unfortunately write access to this
register may be controlled by EL3/EL2 firmware. To be more
precise, by default (if there is EL2/EL3 firmware running)
this register is RO for NS EL1.
This switch can be used to avoid writing to CPUECTLR_EL1,
it can be safely enabled when EL2/EL3 initialized SMPEN bit
or when CPU implementation doesn't include that register.
arm64: add better and more generic spin-table support There are two enable methods supported by ARM64 Linux; psci and spin-table. The latter is simpler and helpful for quick SoC bring up. My main motivation for this patch is to improve the spin-table support, which allows us to boot an ARMv8 system without the ARM Trusted Firmware. Currently, we have multi-entry code in arch/arm/cpu/armv8/start.S and the spin-table is supported in a really ad-hoc way, and I see some problems: - We must hard-code CPU_RELEASE_ADDR so that it matches the "cpu-release-addr" property in the DT that comes from the kernel tree. - The Documentation/arm64/booting.txt in Linux requires that the release address must be zero-initialized, but it is not cared by the common code in U-Boot. We must do it in a board function. - There is no systematic way to protect the spin-table code from the kernel. We are supposed to do it in a board specific manner, but it is difficult to predict where the spin-table code will be located after the relocation. So, it also makes difficult to hard-code /memreserve/ in the DT of the kernel. So, here is a patch to solve those problems; the DT is run-time modified to reserve the spin-table code (+ cpu-release-addr). Also, the "cpu-release-addr" property is set to an appropriate address after the relocation, which means we no longer need the hard-coded CPU_RELEASE_ADDR. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-27 10:31:05 +00:00
config ARMV8_SPIN_TABLE
bool "Support spin-table enable method"
depends on ARMV8_MULTIENTRY && OF_LIBFDT
help
Say Y here to support "spin-table" enable method for booting Linux.
To use this feature, you must do:
- Specify enable-method = "spin-table" in each CPU node in the
Device Tree you are using to boot the kernel
arm64: spin-table: add more information in Kconfig help This feature seems to be sometimes misunderstood. The intention is: [1] Bring the slaves into the U-Boot proper image, not SPL (unless you have a special reason to do otherwise). [2] The operation must be done in a board (SoC) specific manner since how to wake the slaves from the Boot ROM is SoC specific. [3] The slaves must enter U-Boot proper after U-Boot relocates itself because the "cpu-release-addr" property points to the relocated memory area. [2] is already explained in the help. We can make [1] even clearer by mentioning "U-Boot proper" instead of "U-Boot". [3] is missing, so I am adding it to the list. Instead, "before the master CPU jumps to the kernel" is a matter of course, so removed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-20 09:04:43 +00:00
- Bring secondary CPUs into U-Boot proper in a board specific
manner. This must be done *after* relocation. Otherwise, the
secondary CPUs will spin in unprotected memory area because the
master CPU protects the relocated spin code.
arm64: add better and more generic spin-table support There are two enable methods supported by ARM64 Linux; psci and spin-table. The latter is simpler and helpful for quick SoC bring up. My main motivation for this patch is to improve the spin-table support, which allows us to boot an ARMv8 system without the ARM Trusted Firmware. Currently, we have multi-entry code in arch/arm/cpu/armv8/start.S and the spin-table is supported in a really ad-hoc way, and I see some problems: - We must hard-code CPU_RELEASE_ADDR so that it matches the "cpu-release-addr" property in the DT that comes from the kernel tree. - The Documentation/arm64/booting.txt in Linux requires that the release address must be zero-initialized, but it is not cared by the common code in U-Boot. We must do it in a board function. - There is no systematic way to protect the spin-table code from the kernel. We are supposed to do it in a board specific manner, but it is difficult to predict where the spin-table code will be located after the relocation. So, it also makes difficult to hard-code /memreserve/ in the DT of the kernel. So, here is a patch to solve those problems; the DT is run-time modified to reserve the spin-table code (+ cpu-release-addr). Also, the "cpu-release-addr" property is set to an appropriate address after the relocation, which means we no longer need the hard-coded CPU_RELEASE_ADDR. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-27 10:31:05 +00:00
U-Boot automatically does:
- Set "cpu-release-addr" property of each CPU node
(overwrites it if already exists).
- Reserve the code for the spin-table and the release address
via a /memreserve/ region in the Device Tree.
kconfig: armv8: move armv8 sec_firmware CONFIG_* to Kconfig Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [York S: clean up scripts/config_whitelist.txt] Reviewed-by: York Sun <york.sun@nxp.com>
2017-01-16 09:31:47 +00:00
menu "ARMv8 secure monitor firmware"
config ARMV8_SEC_FIRMWARE_SUPPORT
bool "Enable ARMv8 secure monitor firmware framework support"
select OF_LIBFDT
select FIT
help
This framework is aimed at making secure monitor firmware load
process brief.
Note: Only FIT format image is supported.
You should prepare and provide the below information:
- Address of secure firmware.
- Address to hold the return address from secure firmware.
- Secure firmware FIT image related information.
Such as: SEC_FIRMWARE_FIT_IMAGE and SEC_FIRMEWARE_FIT_CNF_NAME
- The target exception level that secure monitor firmware will
return to.
config SPL_ARMV8_SEC_FIRMWARE_SUPPORT
bool "Enable ARMv8 secure monitor firmware framework support for SPL"
select SPL_OF_LIBFDT
select SPL_FIT
help
Say Y here to support this framework in SPL phase.
ARMv8/sec_firmware: relocated and renamed the config FSL_PPA_ARMV8_PSCI Moved the config FSL_PPA_ARMV8_PSCI from fsl-layerscape's Kconfig to Kconfig under armv8 and renamed it to SEC_FIRMWARE_ARMV8_PSCI. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2017-01-16 09:31:48 +00:00
config SEC_FIRMWARE_ARMV8_PSCI
bool "PSCI implementation in secure monitor firmware"
depends on ARMV8_SEC_FIRMWARE_SUPPORT || SPL_ARMV8_SEC_FIRMWARE_SUPPORT
help
This config enables the ARMv8 PSCI implementation in secure monitor
firmware. This is a private PSCI implementation and different from
those implemented under the common ARMv8 PSCI framework.
kconfig: armv8: move armv8 sec_firmware CONFIG_* to Kconfig Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [York S: clean up scripts/config_whitelist.txt] Reviewed-by: York Sun <york.sun@nxp.com>
2017-01-16 09:31:47 +00:00
config ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT
bool "ARMv8 secure monitor firmware ERET address byteorder swap"
depends on ARMV8_SEC_FIRMWARE_SUPPORT || SPL_ARMV8_SEC_FIRMWARE_SUPPORT
help
Say Y here when the endianness of the register or memory holding the
Secure firmware exception return address is different with core's.
endmenu
arm: Provide common PSCI based reset handler Most armv8 systems have PSCI support enabled in EL3, either through ARM Trusted Firmware or other firmware. On these systems, we do not need to implement system reset manually, but can instead rely on higher level firmware to deal with it. The exclude list seems excessive right now, but NXP is working on providing an in-tree PSCI implementation, so that all NXP systems can eventually use PSCI as well. Signed-off-by: Alexander Graf <agraf@suse.de> [agraf: fix meson] Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-16 19:08:48 +00:00
config PSCI_RESET
bool "Use PSCI for reset and shutdown"
default y
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
!TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
!TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
armv8: ls1088aqds: Add support of LS1088AQDS This patch add support of LS1088AQDS platform. The LS1088A QorIQTM Development System (QDS) is a high-performance computing, evaluation, and development platform that supports the LS1088A QorIQ Architecture processor. Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com> Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2017-08-31 10:42:55 +00:00
!TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
arm: Provide common PSCI based reset handler Most armv8 systems have PSCI support enabled in EL3, either through ARM Trusted Firmware or other firmware. On these systems, we do not need to implement system reset manually, but can instead rely on higher level firmware to deal with it. The exclude list seems excessive right now, but NXP is working on providing an in-tree PSCI implementation, so that all NXP systems can eventually use PSCI as well. Signed-off-by: Alexander Graf <agraf@suse.de> [agraf: fix meson] Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-16 19:08:48 +00:00
!TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
efi_loader: Disable PSCI reset for ls1043 and ls1046 The NXP ls1043 and ls1046 systems do not (yet) have PSCI enablement for reset. Don't enable generic PSCI reset code on them. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-11-17 00:02:55 +00:00
!TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
!TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
armv8: ls2080ardb: Add LS2081ARDB board support LS2081ARDB board is similar to LS2080ARDB board with few differences It hosts LS2081A SoC Default boot source is QSPI-boot It does not have IFC interface RTC and QSPI flash device are different It provides QIXIS access via I2C Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com> Signed-off-by: Santan Kumar <santan.kumar@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2017-04-27 09:38:07 +00:00
!TARGET_LS2081ARDB && \
arm64: use psci reset on snapdragon This actually works on snapdragon.. not sure why we weren't using it. Fixes reboot/poweroff when using UEFI. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de>
2017-06-26 13:22:23 +00:00
!ARCH_UNIPHIER && !TARGET_S32V234EVB
arm: Provide common PSCI based reset handler Most armv8 systems have PSCI support enabled in EL3, either through ARM Trusted Firmware or other firmware. On these systems, we do not need to implement system reset manually, but can instead rely on higher level firmware to deal with it. The exclude list seems excessive right now, but NXP is working on providing an in-tree PSCI implementation, so that all NXP systems can eventually use PSCI as well. Signed-off-by: Alexander Graf <agraf@suse.de> [agraf: fix meson] Reviewed-by: Simon Glass <sjg@chromium.org>
2016-08-16 19:08:48 +00:00
help
Most armv8 systems have PSCI support enabled in EL3, either through
ARM Trusted Firmware or other firmware.
On these systems, we do not need to implement system reset manually,
but can instead rely on higher level firmware to deal with it.
Select Y here to make use of PSCI calls for system reset
ARMv8: Add secure sections for PSCI text and data This patch adds secure_text, secure_data and secure_stack sections for ARMv8 to hold PSCI text and data, and it is based on the legacy implementation of ARMv7. ARMV8_SECURE_BASE defines the address for PSCI secure sections, ARMV8_PSCI and ARMV8_PSCI_NR_CPUS are firstly used in this patch, so they are introduce here in Kconfig too. Signed-off-by: Hongbo Zhang <hongbo.zhang@nxp.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-12-08 03:58:22 +00:00
config ARMV8_PSCI
bool "Enable PSCI support" if EXPERT
default n
help
PSCI is Power State Coordination Interface defined by ARM.
The PSCI in U-boot provides a general framework and each platform
can implement their own specific PSCI functions.
Say Y here to enable PSCI support on ARMv8 platform.
config ARMV8_PSCI_NR_CPUS
int "Maximum supported CPUs for PSCI"
depends on ARMV8_PSCI
default 4
help
The maximum number of CPUs supported in the PSCI firmware.
It is no problem to set a larger value than the number of CPUs in
the actual hardware implementation.
ARMv8: Add basic PSCI framework This patch introduces a generic ARMv8 PSCI framework, with all functions returning a dummy ARM_PSCI_RET_NI (Not Implemented), then it is up to each platform to implement their own functions based on this framework. Signed-off-by: Hongbo Zhang <hongbo.zhang@nxp.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-12-08 03:58:24 +00:00
config ARMV8_PSCI_CPUS_PER_CLUSTER
int "Number of CPUs per cluster"
depends on ARMV8_PSCI
default 0
help
The number of CPUs per cluster, suppose each cluster has same number
of CPU cores, platforms with asymmetric clusters don't apply here.
A value 0 or no definition of it works for single cluster system.
System with multi-cluster should difine their own exact value.
ARMv8: Add secure sections for PSCI text and data This patch adds secure_text, secure_data and secure_stack sections for ARMv8 to hold PSCI text and data, and it is based on the legacy implementation of ARMv7. ARMV8_SECURE_BASE defines the address for PSCI secure sections, ARMV8_PSCI and ARMV8_PSCI_NR_CPUS are firstly used in this patch, so they are introduce here in Kconfig too. Signed-off-by: Hongbo Zhang <hongbo.zhang@nxp.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-12-08 03:58:22 +00:00
if SYS_HAS_ARMV8_SECURE_BASE
config ARMV8_SECURE_BASE
hex "Secure address for PSCI image"
depends on ARMV8_PSCI
help
Address for placing the PSCI text, data and stack sections.
If not defined, the PSCI sections are placed together with the u-boot
but platform can choose to place PSCI code image separately in other
places such as some secure RAM built-in SOC etc.
endif
armv8/vexpress64: make multientry conditional While the Freescale ARMv8 board LS2085A will enter U-Boot both on a master and a secondary (slave) CPU, this is not the common behaviour on ARMv8 platforms. The norm is that U-Boot is entered from the master CPU only, while the other CPUs are kept in WFI (wait for interrupt) state. The code determining which CPU we are running on is using the MPIDR register, but the definition of that register varies with platform to some extent, and handling multi-cluster platforms (such as the Juno) will become cumbersome. It is better to only enable the multiple entry code on machines that actually need it and disable it by default. Make the single entry default and add a special ARMV8_MULTIENTRY KConfig option to be used by the platforms that need multientry and set it for the LS2085A. Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 boards as it is just totally unused and misleading, and make it conditional in the generic start.S code. This makes the Juno platform start U-Boot properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-09 09:53:21 +00:00
endif
Reference in a new issue Copy permalink