Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-04 18:41:03 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/mach-mvebu/Makefile

123 lines
3.1 KiB
Makefile
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
# SPDX-License-Identifier: GPL-2.0+
arm: armada-xp: Add basic support for Marvell Armada XP SoC This basic support for the Marvell Armada XP is base on the existing kirkwood support. Which has been generatized by moving some common files into common marvell locations. This is in preparation for the upcoming Armada XP MV78460 support. Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Luka Perkov <luka@openwrt.org>
2014-10-22 10:13:17 +00:00
#
arm64: mvebu: Add support for the Marvell Armada 3700 SoC The Armada 3700 integrates the following interfaces (not complete list): - Dual Cortex-A53 ARMv8 - USB 3.0 - SATA 3.0 - PCIe 2.0 - 2 x Gigabit Ethernet 1Gbps / 2.5Gbps - ... This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support for the Marvell DB-88F3720 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Wilson Ding <dingwei@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Hua Jing <jinghua@marvell.com> Cc: Terry Zhou <bjzhou@marvell.com> Cc: Hanna Hawa <hannah@marvell.com> Cc: Haim Boot <hayim@marvell.com>
2016-05-17 13:00:30 +00:00
# Copyright (C) 2014-2016 Stefan Roese <sr@denx.de>
arm: armada-xp: Add basic support for Marvell Armada XP SoC This basic support for the Marvell Armada XP is base on the existing kirkwood support. Which has been generatized by moving some common files into common marvell locations. This is in preparation for the upcoming Armada XP MV78460 support. Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Luka Perkov <luka@openwrt.org>
2014-10-22 10:13:17 +00:00
arm64: mvebu: Add support for the Marvell Armada 3700 SoC The Armada 3700 integrates the following interfaces (not complete list): - Dual Cortex-A53 ARMv8 - USB 3.0 - SATA 3.0 - PCIe 2.0 - 2 x Gigabit Ethernet 1Gbps / 2.5Gbps - ... This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support for the Marvell DB-88F3720 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Wilson Ding <dingwei@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Hua Jing <jinghua@marvell.com> Cc: Terry Zhou <bjzhou@marvell.com> Cc: Hanna Hawa <hannah@marvell.com> Cc: Haim Boot <hayim@marvell.com>
2016-05-17 13:00:30 +00:00
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/
arm: mvebu: Support for 98DX25xx/98DX35xx SoC Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with an integrated CPU (referred to as the CnM block in Marvell's documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support has been ported from Marvell's SDK which is based on a much older version of U-Boot. Signed-off-by: Chris Packham <judge.packham@gmail.com>
2022-11-05 04:23:59 +00:00
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
arm64: mvebu: Add support for the Marvell Armada 3700 SoC The Armada 3700 integrates the following interfaces (not complete list): - Dual Cortex-A53 ARMv8 - USB 3.0 - SATA 3.0 - PCIe 2.0 - 2 x Gigabit Ethernet 1Gbps / 2.5Gbps - ... This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support for the Marvell DB-88F3720 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Wilson Ding <dingwei@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Hua Jing <jinghua@marvell.com> Cc: Terry Zhou <bjzhou@marvell.com> Cc: Hanna Hawa <hannah@marvell.com> Cc: Haim Boot <hayim@marvell.com>
2016-05-17 13:00:30 +00:00
else # CONFIG_ARM64
rename symbol: CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD Have this symbol follow the pattern of all other such symbols. This patch also removes a TODO from the code. Reviewed-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:40 +00:00
ifdef CONFIG_ARCH_KIRKWOOD
arm: mvebu: Move mvebu-common into mach-mvebu Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2015-04-25 04:29:46 +00:00
obj-y = dram.o
obj-y += gpio.o
ARM: kirkwood: switch to using mvebu mbus The mvebu mbus code already had most of the support required for kirkwood. The only difference is that unlike the other mvebu targets kirkwood doesn't have a bridge control block so the code related to managing that needs to be compiled out. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
2019-03-13 07:47:03 +00:00
obj-y += mbus.o
arm: kirkwood: make it CONFIG_TIMER aware If we switch to CONFIG_TIMER, we don't need the legacy timer macros and functions anymore. Add the proper guards to exclude them from compiling. Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-08-17 19:37:50 +00:00
rename symbol: CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD Have this symbol follow the pattern of all other such symbols. This patch also removes a TODO from the code. Reviewed-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:40 +00:00
else # CONFIG_ARCH_KIRKWOOD
arm: mvebu: Move mvebu-common into mach-mvebu Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2015-04-25 04:29:46 +00:00
arm: armada-xp: Add basic support for Marvell Armada XP SoC This basic support for the Marvell Armada XP is base on the existing kirkwood support. Which has been generatized by moving some common files into common marvell locations. This is in preparation for the upcoming Armada XP MV78460 support. Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Luka Perkov <luka@openwrt.org>
2014-10-22 10:13:17 +00:00
obj-y = cpu.o
arm: mvebu: Move mvebu-common into mach-mvebu Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2015-04-25 04:29:46 +00:00
obj-y += dram.o
arm: mvebu: Move internal registers in arch_very_early_init() function Moving of internal registers from INTREG_BASE_ADDR_REG to SOC_REGS_PHY_BASE needs to be done very early, prior calling any function which may touch internal registers, like debug_uart_init(). So do it earlier in arch_very_early_init() instead of arch_cpu_init(). Movement is done in proper U-Boot, not in SPL. SPL may return to bootrom and bootrom requires internal registers at (old) expected location. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-05-06 09:05:14 +00:00
obj-y += lowlevel.o
arm: mvebu: Implement simple mvebu-reset driver for enabling/disabling PCIe ports Enabling and disabling PCIe ports is done via address space of system controller. All 32-bit Armada SoCs use low 4 bits in SoC Control 1 Register for enabling and disabling some or more PCIe ports. Correct mapping needs to be set in particular DTS files. DT API for mvebu-reset is prepared for implementing resets also for other HW blocks, but currently only PCIe is implemented via index 0. Currently this driver is not used as PCIe ports are automatically enabled by SerDes code executed by U-Boot SPL. But this will change in followup patches. Signed-off-by: Pali Rohár <pali@kernel.org>
2021-12-21 11:20:18 +00:00
obj-$(CONFIG_DM_RESET) += system-controller.o
arm: mvebu: Add complete SDRAM ECC scrubbing This patch introduces the SDRAM scrubbing for ECC enabled board to fill/initialize the ECC bytes. This is done via the XOR engine to speed up the process. The scrubbing is a 2-stage process: 1) SPL scrubs the area 0 - 0x100.0000 (16MiB) for the main U-Boot 2) U-Boot scrubs the remaining SDRAM area(s) Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-08-06 12:43:13 +00:00
ifndef CONFIG_SPL_BUILD
arm: mvebu: Add basic support for the Marvell Armada 375 SoC This patch adds basic support for the Armada 375. Please note that currently the SerDes and DDR3 init code for the A375 is not included / enabled. This will be done in a later, follow-up patch. Right now, this A375 mainline U-Boot can only be used by chainloading it via the original Marvell U-Boot. This can be done via this command: => tftpboot 00800000 a375/u-boot-dtb.bin;go 00800000 Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2016-02-10 06:23:00 +00:00
obj-$(CONFIG_ARMADA_375) += ../../../drivers/ddr/marvell/axp/xor.o
arm: mvebu: Move SoC selection (A38X vs AXP) into Kconfig Until now, the SoC selection for the ARCH_MVEBU platforms has been done in the config header. Using CONFIG_ARMADA_XP in a non-clear way. As it needed to get selected for AXP and A38x based boards. This patch now changes this to move the SoC selection to Kconfig. And also uses CONFIG_ARCH_MVEBU as a common define for both AXP and A38x. This makes things a bit clearer - especially for new board additions. Additionally the defines CONFIG_SYS_MVEBU_DDR_AXP and CONFIG_SYS_MVEBU_DDR_A38X are replaced with the already available CONFIG_ARMADA_38X and CONFIG_ARMADA_XP. And CONFIG_DDR3 is removed, as its not referenced anywhere. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-12-21 12:56:33 +00:00
obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
arm: mvebu: Add Marvell's integrated CPUs Marvell's switch chips with integrated CPUs (collectively referred to as MSYS) share common ancestry with the Armada SoCs. Some of the IP blocks (e.g. xor) are located at different addresses and DFX server exists as a separate target on the MBUS (on Armada-38x it's just part of the core complex registers). Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
2019-04-11 10:22:50 +00:00
obj-$(CONFIG_ARMADA_MSYS) += ../../../drivers/ddr/marvell/axp/xor.o
arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API. Banks 0-43 are reserved for accessing Security OTP (not implemented yet). Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2). Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3). Write support is not implemented yet because it looks like that both North and South Bridge OTPs are already burned in factory with some data. The meaning of some bits of North Bridge is documented in WTMI source code. The meaning of bits in South Bridge is unknown. 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-02-23 13:15:45 +00:00
ifdef CONFIG_ARMADA_38X
arm: mvebu: Implement secure boot The patch implements secure booting for the mvebu architecture. This includes: - The addition of secure headers and all needed signatures and keys in mkimage - Commands capable of writing the board's efuses to both write the needed cryptographic data and enable the secure booting mechanism - The creation of convenience text files containing the necessary commands to write the efuses The KAK and CSK keys are expected to reside in the files kwb_kak.key and kwb_csk.key (OpenSSL 2048 bit private keys) in the top-level directory. Signed-off-by: Reinhard Pfau <reinhard.pfau@gdsys.cc> Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Stefan Roese <sr@denx.de>
2017-01-11 15:01:00 +00:00
obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API. Banks 0-43 are reserved for accessing Security OTP (not implemented yet). Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2). Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3). Write support is not implemented yet because it looks like that both North and South Bridge OTPs are already burned in factory with some data. The meaning of some bits of North Bridge is documented in WTMI source code. The meaning of bits in South Bridge is unknown. 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-02-23 13:15:45 +00:00
endif
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
extra-y += kwbimage.cfg
arm: mvebu: Remove reference to ARMADA_370 Drop this as it is not referenced anywhere else in the code. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-01 20:19:20 +00:00
ifneq ($(CONFIG_ARMADA_XP),)
arm: mvebu: Set CPU for U-Boot SPL binary in kwbimage kwbimage needs to know CPU type, so set it in kwbimage config file. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-01-12 17:20:44 +00:00
KWB_REPLACE += CPU
KWB_CFG_CPU = SHEEVA
arm: mvebu: Drop reference to CONFIG_ARMADA_39X This is not defined anywhere. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-02-01 20:19:21 +00:00
else ifneq ($(CONFIG_ARMADA_375)$(CONFIG_ARMADA_38X),)
arm: mvebu: Set CPU for U-Boot SPL binary in kwbimage kwbimage needs to know CPU type, so set it in kwbimage config file. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-01-12 17:20:44 +00:00
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)
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
KWB_REPLACE += BOOT_FROM
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
KWB_CFG_BOOT_FROM=spi
endif
arm: mvebu: Add support for generating NAND kwbimage Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND which instruct make to generate kwbimage with NAND header. This image is used for booting from NAND flash (either SPI or parallel). Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then loads and executes U-Boot proper. To generate correct kwbimage NAND header, it is required to set following Kconfig options: CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION They are used only by make / mkimage when generating final kwbimage. CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION is a new mvebu specific Kconfig option which is set into kwbimage NAND_BADBLK_LOCATION header field. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-01-10 21:55:21 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),)
KWB_CFG_BOOT_FROM=nand
endif
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
KWB_CFG_BOOT_FROM=sdio
endif
arm: mvebu: add support for boot from SATA Add the required Kconfig and macro definitions to allow boot from SATA on Armada 38x systems. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Stefan Roese <sr@denx.de>
2019-05-16 10:03:58 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
KWB_CFG_BOOT_FROM=sata
endif
arm: mvebu: Add support for generating PEX kwbimage Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX which instruct make to generate kwbimage with PEX header. This image is used for booting from PCI Express device which is in the Root Complex mode. Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then start executing U-Boot proper. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-01-10 22:09:15 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX),)
KWB_CFG_BOOT_FROM=pex
endif
mvebu: support UART boot image The kwboot utility can use the generated image to boot mvebu SoCs from UART. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:26 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
KWB_CFG_BOOT_FROM=uart
endif
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
arm: mvebu: Add support for generating NAND kwbimage Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND which instruct make to generate kwbimage with NAND header. This image is used for booting from NAND flash (either SPI or parallel). Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then loads and executes U-Boot proper. To generate correct kwbimage NAND header, it is required to set following Kconfig options: CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION They are used only by make / mkimage when generating final kwbimage. CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION is a new mvebu specific Kconfig option which is set into kwbimage NAND_BADBLK_LOCATION header field. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-01-10 21:55:21 +00:00
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
arm: mvebu: spl: Allow to build SATA kwbimage for 4K Native disks Add a new config option CONFIG_MVEBU_SPL_SATA_BLKSZ for specifying block size of SATA disk. This information is used during building of SATA kwbimage and must be correctly set, otherwise BootROM does not load SPL. For 4K Native disks CONFIG_MVEBU_SPL_SATA_BLKSZ must be set to 4096. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Martin Rowe <martin.p.rowe@gmail.com>
2023-03-29 19:25:58 +00:00
ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
KWB_REPLACE += SATA_BLKSZ
KWB_CFG_SATA_BLKSZ = $(CONFIG_MVEBU_SPL_SATA_BLKSZ)
endif
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
ifneq ($(CONFIG_SECURED_MODE_IMAGE),)
KWB_REPLACE += CSK_INDEX
KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX)
KWB_REPLACE += SEC_BOOT_DEV
arm: mvebu: Use MVEBU_SPL_BOOT_DEVICE instead of SPL_BOOT_DEVICE Update the way KWB_CFG_SEC_BOOT_DEV is determined to use CONFIG_MVEBU_SPL_BOOT_DEVICE_{SPI,MMC} instead of CONFIG_SPL_BOOT_DEVICE. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-05-28 23:13:16 +00:00
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
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
KWB_REPLACE += SEC_FUSE_DUMP
KWB_CFG_SEC_FUSE_DUMP = a38x
endif
arm: mvebu: Enable BootROM output on A38x BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x' BootROM has its output on UART disabled by default. To enable BootROM output on A38x SoC, it is required to set DEBUG flag (which only enables BootROM output and nothing more) in kwbimage. For UART images this DEBUG flag is ignored by BootROM. Enable kwbimage DEBUG flag for all A38x boards. With this change BootROM prints the following (success) information on UART before booting U-Boot kwbimage: BootROM - 1.73 Booting from SPI flash 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:47 +00:00
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
arm: mvebu: Generate kwbimage.cfg with $(call cmd, ...) Usage of $(call cmd,...) is standard way to call other commands which generate things. It also has the advantage of printing build information in the form KWBCFG arch/arm/mach-mvebu/kwbimage.cfg if verbosity is disabled, and printing the build command otherwise. Note that the '#' character needs to be escaped in Makefile when used as value for make variable assignment. 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:39 +00:00
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' \
arm: mvebu: Generate kwbimage.cfg with $(call cmd, ...) Usage of $(call cmd,...) is standard way to call other commands which generate things. It also has the advantage of printing build information in the form KWBCFG arch/arm/mach-mvebu/kwbimage.cfg if verbosity is disabled, and printing the build command otherwise. Note that the '#' character needs to be escaped in Makefile when used as value for make variable assignment. 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:39 +00:00
<$< >$(dir $@)$(@F)
arm: mvebu: Avoid generating kwbimage.cfg in the source tree At present some boards generate kwbimage.cfg in the source tree during the build. This breaks buildman testing on some systems where the source tree is read-only. Update makefile rules to generate it in the build tree instead. Note some other boards have the kwbimage.cfg file written in advance, hence we need check if the file exists in the build tree first, otherwise we fall back to one in the source tree. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-10-28 14:25:01 +00:00
$(obj)/kwbimage.cfg: $(src)/kwbimage.cfg.in include/autoconf.mk \
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
include/config/auto.conf
arm: mvebu: Generate kwbimage.cfg with $(call cmd, ...) Usage of $(call cmd,...) is standard way to call other commands which generate things. It also has the advantage of printing build information in the form KWBCFG arch/arm/mach-mvebu/kwbimage.cfg if verbosity is disabled, and printing the build command otherwise. Note that the '#' character needs to be escaped in Makefile when used as value for make variable assignment. 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:39 +00:00
$(call cmd,kwbcfg)
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2018-06-18 18:56:25 +00:00
arm64: mvebu: Add support for the Marvell Armada 3700 SoC The Armada 3700 integrates the following interfaces (not complete list): - Dual Cortex-A53 ARMv8 - USB 3.0 - SATA 3.0 - PCIe 2.0 - 2 x Gigabit Ethernet 1Gbps / 2.5Gbps - ... This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support for the Marvell DB-88F3720 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Wilson Ding <dingwei@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Hua Jing <jinghua@marvell.com> Cc: Terry Zhou <bjzhou@marvell.com> Cc: Hanna Hawa <hannah@marvell.com> Cc: Haim Boot <hayim@marvell.com>
2016-05-17 13:00:30 +00:00
endif # CONFIG_SPL_BUILD
arm: mvebu: Move mvebu-common into mach-mvebu Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2015-04-25 04:29:46 +00:00
obj-y += gpio.o
obj-y += mbus.o
arm: armada-xp: Add SPL support used to include the DDR training code This patch adds SPL support to the Marvell Armada-XP. With this addition the bin_hdr integration is not needed any more. The SPL will first initialize the serdes/PHY and the call the DDR setup and training code now integrated into mainline U-Boot. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Luka Perkov <luka.perkov@sartura.hr>
2015-01-19 10:33:42 +00:00
obj-$(CONFIG_SPL_BUILD) += spl.o
obj-$(CONFIG_SPL_BUILD) += lowlevel_spl.o
arm: mvebu: Move mvebu-common into mach-mvebu Now that the mach-mvebu directory exists and is used by Armada XP we can move the mvebu-common files into this directory as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com> Tested-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2015-04-25 04:29:46 +00:00
arm: mvebu: Move SoC selection (A38X vs AXP) into Kconfig Until now, the SoC selection for the ARCH_MVEBU platforms has been done in the config header. Using CONFIG_ARMADA_XP in a non-clear way. As it needed to get selected for AXP and A38x based boards. This patch now changes this to move the SoC selection to Kconfig. And also uses CONFIG_ARCH_MVEBU as a common define for both AXP and A38x. This makes things a bit clearer - especially for new board additions. Additionally the defines CONFIG_SYS_MVEBU_DDR_AXP and CONFIG_SYS_MVEBU_DDR_A38X are replaced with the already available CONFIG_ARMADA_38X and CONFIG_ARMADA_XP. And CONFIG_DDR3 is removed, as its not referenced anywhere. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-12-21 12:56:33 +00:00
obj-$(CONFIG_ARMADA_38X) += serdes/a38x/
obj-$(CONFIG_ARMADA_XP) += serdes/axp/
arm: mvebu: serdes: Move Armada XP SERDES / PHY init code into new directory With the upcoming addition of the Armada 38x SPL support, which is not compatible to the Armada XP SERDES init code, we need to introduce a new directory infrastructure. So lets move the AXP serdes init code into a new directory. This way the A38x code can be added in a clean way. Signed-off-by: Stefan Roese <sr@denx.de>
2015-04-20 07:28:12 +00:00
rename symbol: CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD Have this symbol follow the pattern of all other such symbols. This patch also removes a TODO from the code. Reviewed-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:40 +00:00
endif # CONFIG_ARCH_KIRKWOOD
arm64: mvebu: Add support for the Marvell Armada 3700 SoC The Armada 3700 integrates the following interfaces (not complete list): - Dual Cortex-A53 ARMv8 - USB 3.0 - SATA 3.0 - PCIe 2.0 - 2 x Gigabit Ethernet 1Gbps / 2.5Gbps - ... This patch adds basic support for this ARMv8 based SoC into U-Boot. Future patches will integrate other device drivers and board support for the Marvell DB-88F3720 development board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nadav Haklai <nadavh@marvell.com> Cc: Kostya Porotchkin <kostap@marvell.com> Cc: Wilson Ding <dingwei@marvell.com> Cc: Victor Gu <xigu@marvell.com> Cc: Hua Jing <jinghua@marvell.com> Cc: Terry Zhou <bjzhou@marvell.com> Cc: Hanna Hawa <hannah@marvell.com> Cc: Haim Boot <hayim@marvell.com>
2016-05-17 13:00:30 +00:00
endif # CONFIG_ARM64
Reference in a new issue Copy permalink