u-boot-brain/arch/arm/mach-uniphier/arm64/Makefile

#
# SPDX-License-Identifier:	GPL-2.0+
#

obj-y += mem_map.o
obj-$(CONFIG_ARCH_UNIPHIER_LD20) += lowlevel_init.o
ARM: uniphier: add PH1-LD20 SoC support This is the first ARMv8 SoC from Socionext Inc. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 2016-04-21 14:43:18 +09:00			`#`
			`# SPDX-License-Identifier: GPL-2.0+`
			`#`

ARM: uniphier: make SPL optional for ARVv8 SoCs We may want to run different firmware before running U-Boot. For example, ARM Trusted Firmware runs before U-Boot, making U-Boot a non-secure world boot loader. In this case, the SoC might be initialized there, which enables us to skip SPL entirely. This commit removes "select SPL" to make it configurable. This also enables the Multi SoC support for the UniPhier ARMv8 SoCs. (CONFIG_ARCH_UNIPHIER_V8_MULTI) Thanks to the driver model and Device Tree, the U-Boot proper part is now written in a generic way. The board/SoC parameters reside in DT. The Multi SoC support increases the memory footprint a bit, but the U-Boot proper does not have strict memory constraint. This will mitigate the per-SoC (sometimes per-board) defconfig burden. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 2017-01-21 18:05:22 +09:00			`obj-y += mem_map.o`
ARM: uniphier: add weird workaround code for LD20 When booting from ARM Trusted Firmware, U-Boot runs in EL1-NS. The boot flow is as follows: BL1 -> BL2 -> BL31 -> BL33 (i.e. U-Boot) This boot sequence works fine for LD11 SoC (Cortex-A53), but LD20 SoC (Cortex-A72) hangs in U-Boot. The solution I found is to read sctlr_el1 and write back the value as-is. This should be no effect, but surprisingly fixes the problem for LD20 to boot. I do not know why. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> 2017-05-12 22:49:02 +09:00			`obj-$(CONFIG_ARCH_UNIPHIER_LD20) += lowlevel_init.o`