2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-24 20:13:39 +00:00
u-boot/arch/arm/mach-mvebu/Makefile

123 lines
3.1 KiB
Makefile
Raw Normal View History

# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (C) 2014-2016 Stefan Roese <sr@denx.de>
ifdef CONFIG_ARM64
obj-$(CONFIG_ARMADA_3700) += armada3700/
arm64: mvebu: Add basic support for the Marvell Armada 7K/8K SoC Compared to the Armada 3700, the Armada 7K and 8K are much more on the high-end side: they use a dual Cortex-A72 or a quad Cortex-A72, as opposed to the Cortex-A53 for the Armada 3700. The Armada 7K and 8K also use a fairly unique architecture, internally they are composed of several components: - One AP (Application Processor), which contains the processor itself and a few core hardware blocks. The AP used in the Armada 7K and 8K is called AP806, and is available in two configurations: dual Cortex-A72 and quad Cortex-A72. - One or two CP (Communication Processor), which contain most of the I/O interfaces (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP, while the 8K family chips integrate two CPs, providing two times the number of I/O interfaces available in the CP. The CP used in the 7K and 8K is called CP110. All in all, this gives the following combinations: - Armada 7020, which is a dual Cortex-A72 with one CP - Armada 7040, which is a quad Cortex-A72 with one CP - Armada 8020, which is a dual Cortex-A72 with two CPs - Armada 8040, which is a quad Cortex-A72 with two CPs This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support, starting with the Marvell DB-88F7040 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Neta Zur Hershkovits <neta@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Omri Itach <omrii@marvell.com> Cc: Igal Liberman <igall@marvell.com> Cc: Haim Boot <hayim@marvell.com> Cc: Hanna Hawa <hannah@marvell.com>
2016-05-25 06:13:45 +00:00
obj-$(CONFIG_ARMADA_8K) += armada8k/
obj-$(CONFIG_ALLEYCAT_5) += alleycat5/
arm64: mvebu: Add basic support for the Marvell Armada 7K/8K SoC Compared to the Armada 3700, the Armada 7K and 8K are much more on the high-end side: they use a dual Cortex-A72 or a quad Cortex-A72, as opposed to the Cortex-A53 for the Armada 3700. The Armada 7K and 8K also use a fairly unique architecture, internally they are composed of several components: - One AP (Application Processor), which contains the processor itself and a few core hardware blocks. The AP used in the Armada 7K and 8K is called AP806, and is available in two configurations: dual Cortex-A72 and quad Cortex-A72. - One or two CP (Communication Processor), which contain most of the I/O interfaces (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP, while the 8K family chips integrate two CPs, providing two times the number of I/O interfaces available in the CP. The CP used in the 7K and 8K is called CP110. All in all, this gives the following combinations: - Armada 7020, which is a dual Cortex-A72 with one CP - Armada 7040, which is a quad Cortex-A72 with one CP - Armada 8020, which is a dual Cortex-A72 with two CPs - Armada 8040, which is a quad Cortex-A72 with two CPs This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support, starting with the Marvell DB-88F7040 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Neta Zur Hershkovits <neta@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Omri Itach <omrii@marvell.com> Cc: Igal Liberman <igall@marvell.com> Cc: Haim Boot <hayim@marvell.com> Cc: Hanna Hawa <hannah@marvell.com>
2016-05-25 06:13:45 +00:00
obj-y += arm64-common.o
else # CONFIG_ARM64
ifdef CONFIG_ARCH_KIRKWOOD
obj-y = dram.o
obj-y += gpio.o
obj-y += mbus.o
else # CONFIG_ARCH_KIRKWOOD
obj-y = cpu.o
obj-y += dram.o
obj-y += lowlevel.o
obj-$(CONFIG_DM_RESET) += system-controller.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMADA_375) += ../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_ARMADA_MSYS) += ../../../drivers/ddr/marvell/axp/xor.o
ifdef CONFIG_ARMADA_38X
obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
endif
extra-y += kwbimage.cfg
ifneq ($(CONFIG_ARMADA_XP),)
KWB_REPLACE += CPU
KWB_CFG_CPU = SHEEVA
else ifneq ($(CONFIG_ARMADA_375)$(CONFIG_ARMADA_38X),)
KWB_REPLACE += CPU
KWB_CFG_CPU = A9
endif
arm: mvebu: Correctly set LOAD_ADDRESS for U-Boot SPL binary in kwbimage U-Boot SPL for mvebu platform is not compiled as position independent. Therefore it is required to instruct BootROM to load U-Boot SPL at the correct address. Loading of kwbimage binary code at specific address can be now achieved by the new LOAD_ADDRESS token as part of BINARY command in kwbimage config file. Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in. It is required to update regex for sed to find replacement tokens at any position on a line in kwbimage config file and not only at the beginning of the line. This is because LOAD_ADDRESS is specified at the end of line containing the BINARY command. It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value 0x40004030 or 0x40000030. Why this value? It is because main kwbimage header is at address 0x40004030 or 0x40000000 and it is 32 bytes long. After the main header there is the binary header, which consist of 1 byte for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved bytes and then 4 bytes for each argument. After these arguments comes the executable code. So arguments start at address 0x40004028 or 0x40000028. Before commit e6571f38c943 ("arm: mvebu: Remove dummy BIN header arguments for SPL binary") there were two (dummy) arguments, which resulted in load address of 0x40004030 or 0x40000030, always. After that commit (which removed dummy arguments), load address stayed same due to the 128-bit alignment done by mkimage. This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE), load address and dummy kwbimage arguments, and allows the user to adjust $(CONFIG_SPL_TEXT_BASE) config option to some other value. For unsupported values, when mkimage/kwbimage cannot set chosen load address as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails, instead of silently generating non-working kwbimage. Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS can only be done by compiling U-Boot SPL as position independent. But this currently is not possible for 32-bit ARM version of U-Boot SPL. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-01-12 17:20:45 +00:00
KWB_REPLACE += LOAD_ADDRESS
KWB_CFG_LOAD_ADDRESS = $(CONFIG_SPL_TEXT_BASE)
KWB_REPLACE += BOOT_FROM
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
KWB_CFG_BOOT_FROM=spi
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),)
KWB_CFG_BOOT_FROM=nand
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
KWB_CFG_BOOT_FROM=sdio
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
KWB_CFG_BOOT_FROM=sata
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX),)
KWB_CFG_BOOT_FROM=pex
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
KWB_CFG_BOOT_FROM=uart
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),)
KWB_REPLACE += NAND_PAGE_SIZE NAND_BLKSZ NAND_BADBLK_LOCATION
KWB_CFG_NAND_PAGE_SIZE = $(CONFIG_SYS_NAND_PAGE_SIZE)
KWB_CFG_NAND_BLKSZ = $(CONFIG_SYS_NAND_BLOCK_SIZE)
KWB_CFG_NAND_BADBLK_LOCATION = $(CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION)
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
KWB_REPLACE += SATA_BLKSZ
KWB_CFG_SATA_BLKSZ = $(CONFIG_MVEBU_SPL_SATA_BLKSZ)
endif
ifneq ($(CONFIG_SECURED_MODE_IMAGE),)
KWB_REPLACE += CSK_INDEX
KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX)
KWB_REPLACE += SEC_BOOT_DEV
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
KWB_CFG_SEC_BOOT_DEV=0x34
endif
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
KWB_CFG_SEC_BOOT_DEV=0x31
endif
KWB_REPLACE += SEC_FUSE_DUMP
KWB_CFG_SEC_FUSE_DUMP = a38x
endif
ifdef CONFIG_ARMADA_38X
# BootROM output is by default enabled on pre-A38x and disabled on A38x
# DEBUG flag on A38x for non-UART boot source only enable BootROM output and nothing more
KWB_REPLACE += DEBUG
KWB_CFG_DEBUG = 1
endif
quiet_cmd_kwbcfg = KWBCFG $@
arm: mvebu: Correctly set LOAD_ADDRESS for U-Boot SPL binary in kwbimage U-Boot SPL for mvebu platform is not compiled as position independent. Therefore it is required to instruct BootROM to load U-Boot SPL at the correct address. Loading of kwbimage binary code at specific address can be now achieved by the new LOAD_ADDRESS token as part of BINARY command in kwbimage config file. Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in. It is required to update regex for sed to find replacement tokens at any position on a line in kwbimage config file and not only at the beginning of the line. This is because LOAD_ADDRESS is specified at the end of line containing the BINARY command. It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value 0x40004030 or 0x40000030. Why this value? It is because main kwbimage header is at address 0x40004030 or 0x40000000 and it is 32 bytes long. After the main header there is the binary header, which consist of 1 byte for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved bytes and then 4 bytes for each argument. After these arguments comes the executable code. So arguments start at address 0x40004028 or 0x40000028. Before commit e6571f38c943 ("arm: mvebu: Remove dummy BIN header arguments for SPL binary") there were two (dummy) arguments, which resulted in load address of 0x40004030 or 0x40000030, always. After that commit (which removed dummy arguments), load address stayed same due to the 128-bit alignment done by mkimage. This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE), load address and dummy kwbimage arguments, and allows the user to adjust $(CONFIG_SPL_TEXT_BASE) config option to some other value. For unsupported values, when mkimage/kwbimage cannot set chosen load address as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails, instead of silently generating non-working kwbimage. Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS can only be done by compiling U-Boot SPL as position independent. But this currently is not possible for 32-bit ARM version of U-Boot SPL. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-01-12 17:20:45 +00:00
cmd_kwbcfg = sed -ne '$(foreach V,$(KWB_REPLACE),s/\#@$(V)/$(V) $(KWB_CFG_$(V))/;)p' \
<$< >$(dir $@)$(@F)
$(obj)/kwbimage.cfg: $(src)/kwbimage.cfg.in include/autoconf.mk \
include/config/auto.conf
$(call cmd,kwbcfg)
endif # CONFIG_SPL_BUILD
obj-y += gpio.o
obj-y += mbus.o
obj-$(CONFIG_SPL_BUILD) += spl.o
obj-$(CONFIG_SPL_BUILD) += lowlevel_spl.o
obj-$(CONFIG_ARMADA_38X) += serdes/a38x/
obj-$(CONFIG_ARMADA_XP) += serdes/axp/
endif # CONFIG_ARCH_KIRKWOOD
endif # CONFIG_ARM64