ARM: uniphier: remove SPL support for ARMv8 SoCsIt has been a while since ARM Trusted Firmware supported UniPhier SoCfamily. U-Boot SPL was intended as a temporary loader that runs insecure worl
ARM: uniphier: remove SPL support for ARMv8 SoCsIt has been a while since ARM Trusted Firmware supported UniPhier SoCfamily. U-Boot SPL was intended as a temporary loader that runs insecure world. It is a maintenance headache to support two differentboot mechanisms. Secure firmware is realm of ARM Trusted Firmwareand now U-Boot only serves as a non-secure boot loader for UniPhierARMv8 SoCs.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
ARM: uniphier: fix various sparse warningsFix warnings reported by sparse: - ... was not declared. Should it be static?" - cast to restricted __be32While fixing those, the type conflict of cci5
ARM: uniphier: fix various sparse warningsFix warnings reported by sparse: - ... was not declared. Should it be static?" - cast to restricted __be32While fixing those, the type conflict of cci500_init() was found.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ARM: uniphier: add weird workaround code for LD20When 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 se
ARM: uniphier: add weird workaround code for LD20When 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 LD20SoC (Cortex-A72) hangs in U-Boot. The solution I found is toread sctlr_el1 and write back the value as-is. This should beno effect, but surprisingly fixes the problem for LD20 to boot.I do not know why.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ARM: uniphier: make SPL optional for ARVv8 SoCsWe may want to run different firmware before running U-Boot. Forexample, ARM Trusted Firmware runs before U-Boot, making U-Boota non-secure world b
ARM: uniphier: make SPL optional for ARVv8 SoCsWe may want to run different firmware before running U-Boot. Forexample, ARM Trusted Firmware runs before U-Boot, making U-Boota non-secure world boot loader. In this case, the SoC might beinitialized there, which enables us to skip SPL entirely.This commit removes "select SPL" to make it configurable. Thisalso enables the Multi SoC support for the UniPhier ARMv8 SoCs.(CONFIG_ARCH_UNIPHIER_V8_MULTI) Thanks to the driver model andDevice Tree, the U-Boot proper part is now written in a generic way.The board/SoC parameters reside in DT. The Multi SoC supportincreases the memory footprint a bit, but the U-Boot proper doesnot have strict memory constraint. This will mitigate the per-SoC(sometimes per-board) defconfig burden.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()This does not have much impact on behavior, but makes code look moremore like Linux. The use of devm_ioremap() often helps to delete.re
ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()This does not have much impact on behavior, but makes code look moremore like Linux. The use of devm_ioremap() often helps to delete.remove callbacks entirely.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
armv8: mmu: Add support of non-identical mappingIntroduce virtual and physical addresses in the mapping table. This changehave no impact on existing boards because they all use idential mapping.
armv8: mmu: Add support of non-identical mappingIntroduce virtual and physical addresses in the mapping table. This changehave no impact on existing boards because they all use idential mapping.Signed-off-by: York Sun <york.sun@nxp.com>
ARM: uniphier: insert dsb barrier to ensure visibility of storeI noticed secondary CPUs sometimes fail to wake up, and the rootcause is that the sev instruction wakes up slave CPUs before theprec
ARM: uniphier: insert dsb barrier to ensure visibility of storeI noticed secondary CPUs sometimes fail to wake up, and the rootcause is that the sev instruction wakes up slave CPUs before thepreceding the register write is observed by them.The read-back of the accessed register does not guarantee the order.In order to ensure the order between the register write and the sevinstruction, a dsb instruction should be executed prior to the sev.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ARM: uniphier: add PH1-LD20 SoC supportThis is the first ARMv8 SoC from Socionext Inc.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>