Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-15 01:17:39 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/Makefile

123 lines
3.8 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+
Kbuild: introduce Makefile in arch/$ARCH/ Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-11-21 22:51:33 +00:00
rename symbol: CONFIG_TEGRA -> CONFIG_ARCH_TEGRA Have this symbol follow the pattern of all other such symbols. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:41 +00:00
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_ARCH_TEGRA),yy)
arm: v7: Kconfig: Rename CPU_V7 as CPU_V7A Currently CPU_V7 kconfig symbol supports only ARMv7A architectures under armv7 folder. This led to a misconception of creating separate folders for armv7m and armv7r. There is no reason to create separate folder for other armv7 based architectures when it can co-exist with few Kconfig symbols. As a first step towards a common folder, rename CPU_V7 as CPUV7A. Later separate Kconfig symbols can be added for CPU_V7R and CPU_V7M and can co exist in the same folder. Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Michal Simek <michal.simek@xilinx.com> Suggested-by: Alexander Graf <agraf@suse.de> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-04-26 12:51:26 +00:00
CONFIG_CPU_V7A=
ARM: fix arch/arm/Makefile for Tegra Since commit 79d75d752717 (ARM: move -march=* and -mtune= options to arch/arm/Makefile), all the Tegra boards are broken because the SPL is built for ARMv7. Insert Tegra-specific code to arch/arm/Makefile to set compiler flags for an earlier ARM architecture. Note: The v1 patch for commit 79d75d752717 *was* correct when it was submitted. Notice it was originally written for multi .config configuration where Kconfig set CONFIG_CPU_V7/CONFIG_CPU_ARM720T for Tegra U-Boot Main/SPL, respectively. But, until it was merged into the mainline, commit e02ee2548afe (kconfig: switch to single .config configuration) had been already applied there. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Stephen Warren <swarren@nvidia.com> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
2015-04-11 15:58:14 +00:00
CONFIG_CPU_ARM720T=y
endif
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
# This selects which instruction set is used.
arch-$(CONFIG_CPU_ARM720T) =-march=armv4
arm: the ARM920T is THUMB capable, so select the appropriate ISA Signed-off-by: David Müller <d.mueller@elsoft.ch>
2016-02-09 15:48:29 +00:00
arch-$(CONFIG_CPU_ARM920T) =-march=armv4t
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
arch-$(CONFIG_CPU_ARM926EJS) =-march=armv5te
arm: Treat arm946es as v5te The arm946es is armv5te , so use -march=armv5te instead of armv4t. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@konsulko.com>
2016-04-30 12:45:59 +00:00
arch-$(CONFIG_CPU_ARM946ES) =-march=armv5te
arm: -march=armv5t for ARM11 In GCC 9 support for the Armv5 and Armv5E architectures (which have no known implementations) has been removed, cf. https://gcc.gnu.org/gcc-9/changes.html Commit 16540d07fd62 ("arm: fix -march for ARM11") changed the value of the compiler flag from -march=armv5 and -march=armv5t into -march=armv6 for ARM11. The values prior to this patch were: arch-$(CONFIG_CPU_ARM1136) =-march=armv5 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t The change lead to a regression with the Raspberry Pi Zero W not booting anymore. Use -march=armv5t both for ARM1136 and ARM1176. Fixes: 16540d07fd62 ("arm: fix -march for ARM11") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Joris Offouga <offougajoris@gmail.com>
2019-12-07 08:14:50 +00:00
arch-$(CONFIG_CPU_ARM1136) =-march=armv5t
arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
arm: v7: Kconfig: Rename CPU_V7 as CPU_V7A Currently CPU_V7 kconfig symbol supports only ARMv7A architectures under armv7 folder. This led to a misconception of creating separate folders for armv7m and armv7r. There is no reason to create separate folder for other armv7 based architectures when it can co-exist with few Kconfig symbols. As a first step towards a common folder, rename CPU_V7 as CPUV7A. Later separate Kconfig symbols can be added for CPU_V7R and CPU_V7M and can co exist in the same folder. Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Michal Simek <michal.simek@xilinx.com> Suggested-by: Alexander Graf <agraf@suse.de> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-04-26 12:51:26 +00:00
arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
arm: armv7-a: Compile and tune for armv7-a instead of armv5 arch/arm/Makefile references armv5 for backwards compatibility with older compilers. This patch removes those references to armv5, since by now newer compilers are required which should have armv7 support enabled. The Makefile also also has a list of options for mtune, but the entry for CONFIG_CPU_V7A is empty, so this patch tunes the CPU_V7A architecture to generic-armv7-a. The following size changed apply to omap3_logic using GCC. Stock text data bss dec hex filename 50910 429 67580 118919 1d087 spl/u-boot-spl 540713 22700 327072 890485 d9675 u-boot Without Armv5 text data bss dec hex filename 50916 429 67580 118925 1d08d spl/u-boot-spl 540719 22700 327064 890483 d9673 u-boot mtune=generic-armv7-a text data bss dec hex filename 50932 429 67580 118941 1d09d spl/u-boot-spl 540519 22700 327080 890299 d95bb u-boot Signed-off-by: Adam Ford <aford173@gmail.com>
2018-08-04 21:34:54 +00:00
$(call cc-option, -march=armv7))
arm: armv7m: Clean up some thumb / compiler flag options - The correct way to build with thumb mode is to select SYS_THUMB_BUILD - We should be setting -march=armv7-m in arch/arm/Makefile not the sub-config.mk file. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-08 00:46:52 +00:00
arch-$(CONFIG_CPU_V7M) =-march=armv7-m
arm: v7R: Add initial support The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded, real-time systems. It implements the ARMv7-R architecture, and includes Thumb-2 technology for optimum code density and processing throughput. Except for MPU(Memory Protection Unit) and few CP15 registers, most of the features are compatible with v7 architecture. So,reuse the same armv7 folder and introduce a new config CPU_V7R in order to differentiate from v7 based platforms. Tested-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-04-26 12:51:29 +00:00
arch-$(CONFIG_CPU_V7R) =-march=armv7-r
crc32: Add crc32 implementation using __builtin_aarch64_crc32b ARMv8.0 has optional crc32 instruction for crc32 calculation. The instruction is mandatory since ARMv8.1. The crc32 calculation is faster using the dedicated instruction, e.g. 1.4 GHz iMX8MN gives: => time crc32 0x50000000 0x2000000 time: 0.126 seconds # crc32 instruction time: 0.213 seconds # software crc32 Add implementation using the compiler builtin wrapper for the crc32 instruction and enable it by default, since we don't support any platforms which do not implement this instruction. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> [trini: Make crc32_table guarded by CONFIG_ARM64_CRC32] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-30 13:05:23 +00:00
ifeq ($(CONFIG_ARM64_CRC32),y)
arch-$(CONFIG_ARM64) =-march=armv8-a+crc
else
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
arch-$(CONFIG_ARM64) =-march=armv8-a
crc32: Add crc32 implementation using __builtin_aarch64_crc32b ARMv8.0 has optional crc32 instruction for crc32 calculation. The instruction is mandatory since ARMv8.1. The crc32 calculation is faster using the dedicated instruction, e.g. 1.4 GHz iMX8MN gives: => time crc32 0x50000000 0x2000000 time: 0.126 seconds # crc32 instruction time: 0.213 seconds # software crc32 Add implementation using the compiler builtin wrapper for the crc32 instruction and enable it by default, since we don't support any platforms which do not implement this instruction. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> [trini: Make crc32_table guarded by CONFIG_ARM64_CRC32] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-08-30 13:05:23 +00:00
endif
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
ARM: Rework and correct barrier definitions As part of testing booting Linux kernels on Rockchip devices, it was discovered by Ziyuan Xu and Sandy Patterson that we had multiple and for some cases incomplete isb definitions. This was causing a failure to boot of the Linux kernel. In order to solve this problem as well as cover any corner cases that we may also have had a number of changes are made in order to consolidate things. First, <asm/barriers.h> now becomes the source of isb/dsb/dmb definitions. This however introduces another complexity. Due to needing to build SPL for 32bit tegra with -march=armv4 we need to borrow the __LINUX_ARM_ARCH__ logic from the Linux Kernel in a more complete form. Move this from arch/arm/lib/Makefile to arch/arm/Makefile and add a comment about it. Now that we can always know what the target CPU is capable off we can get always do the correct thing for the barrier. The final part of this is that need to be consistent everywhere and call isb()/dsb()/dmb() and NOT call ISB/DSB/DMB in some cases and the function names in others. Reviewed-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Ziyuan Xu <xzy.xu@rock-chips.com> Acked-by: Sandy Patterson <apatterson@sightlogix.com> Reported-by: Ziyuan Xu <xzy.xu@rock-chips.com> Reported-by: Sandy Patterson <apatterson@sightlogix.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-08-01 22:54:53 +00:00
# On Tegra systems we must build SPL for the armv4 core on the device
# but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
rename symbol: CONFIG_TEGRA -> CONFIG_ARCH_TEGRA Have this symbol follow the pattern of all other such symbols. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:41 +00:00
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_ARCH_TEGRA),yy)
ARM: Rework and correct barrier definitions As part of testing booting Linux kernels on Rockchip devices, it was discovered by Ziyuan Xu and Sandy Patterson that we had multiple and for some cases incomplete isb definitions. This was causing a failure to boot of the Linux kernel. In order to solve this problem as well as cover any corner cases that we may also have had a number of changes are made in order to consolidate things. First, <asm/barriers.h> now becomes the source of isb/dsb/dmb definitions. This however introduces another complexity. Due to needing to build SPL for 32bit tegra with -march=armv4 we need to borrow the __LINUX_ARM_ARCH__ logic from the Linux Kernel in a more complete form. Move this from arch/arm/lib/Makefile to arch/arm/Makefile and add a comment about it. Now that we can always know what the target CPU is capable off we can get always do the correct thing for the barrier. The final part of this is that need to be consistent everywhere and call isb()/dsb()/dmb() and NOT call ISB/DSB/DMB in some cases and the function names in others. Reviewed-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Ziyuan Xu <xzy.xu@rock-chips.com> Acked-by: Sandy Patterson <apatterson@sightlogix.com> Reported-by: Ziyuan Xu <xzy.xu@rock-chips.com> Reported-by: Sandy Patterson <apatterson@sightlogix.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-08-01 22:54:53 +00:00
arch-y += -D__LINUX_ARM_ARCH__=4
else
arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
endif
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
# Evaluate arch cc-option calls now
arch-y := $(arch-y)
# This selects how we optimise for the processor.
tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM920T) =
tune-$(CONFIG_CPU_ARM926EJS) =
tune-$(CONFIG_CPU_ARM946ES) =
tune-$(CONFIG_CPU_ARM1136) =
tune-$(CONFIG_CPU_ARM1176) =
arm: armv7-a: Compile and tune for armv7-a instead of armv5 arch/arm/Makefile references armv5 for backwards compatibility with older compilers. This patch removes those references to armv5, since by now newer compilers are required which should have armv7 support enabled. The Makefile also also has a list of options for mtune, but the entry for CONFIG_CPU_V7A is empty, so this patch tunes the CPU_V7A architecture to generic-armv7-a. The following size changed apply to omap3_logic using GCC. Stock text data bss dec hex filename 50910 429 67580 118919 1d087 spl/u-boot-spl 540713 22700 327072 890485 d9675 u-boot Without Armv5 text data bss dec hex filename 50916 429 67580 118925 1d08d spl/u-boot-spl 540719 22700 327064 890483 d9673 u-boot mtune=generic-armv7-a text data bss dec hex filename 50932 429 67580 118941 1d09d spl/u-boot-spl 540519 22700 327080 890299 d95bb u-boot Signed-off-by: Adam Ford <aford173@gmail.com>
2018-08-04 21:34:54 +00:00
tune-$(CONFIG_CPU_V7A) =-mtune=generic-armv7-a
arm: v7R: Add initial support The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded, real-time systems. It implements the ARMv7-R architecture, and includes Thumb-2 technology for optimum code density and processing throughput. Except for MPU(Memory Protection Unit) and few CP15 registers, most of the features are compatible with v7 architecture. So,reuse the same armv7 folder and introduce a new config CPU_V7R in order to differentiate from v7 based platforms. Tested-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-04-26 12:51:29 +00:00
tune-$(CONFIG_CPU_V7R) =
ARM: move -march=* and -mtune= options to arch/arm/Makefile My main motivations for this commit are: [1] Follow the arch/arm/Makefile style of Linux Kernel [2] Maintain compiler options systematically Currently, we give -march=* and -mtune=* options inconsistently: Only some of the CPUs pass -march=* and -mtune=* options. By collecting such options into the single place arch/arm/Makefile we can tell which options are missing at a glance. [3] Prepare for deprecating arch/*/cpu/*/config.mk Note: This commit just moves the compiler options so as not to change the behavior at all. It does not care about the correctness of the given options. Fox example, "-march=armv5te" might be better than "-march=armv4" for ARM946EJS, but it is beyond the scope this commit. Also, filling the missing -march=* and -tune=* is left to follow-up patches. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de>
2015-02-26 17:40:33 +00:00
tune-$(CONFIG_ARM64) =
# Evaluate tune cc-option calls now
tune-y := $(tune-y)
PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
ARM: prepare for moving SoC sources into mach-* In U-boot, the directory structure, arch/$(ARCH)/cpu/$(CPU)/$(SOC)/ has been adopted except that $(CPU) is missing from some architectures and $(SOC) is missing from some CPUs. This structure did not fit very well in some cases. [1] AT91 AT91 SoC family have been developed across some ARM processor generations. Generally speaking, some IPs are often re-used in the same SoC family (same SoC vendor) even when the main processor is updated. As a result, a SoC-common directory is needed in the upper level. Currently, AT91 source files are placed as follows: arch/arm/cpu/arm920t/at91/* arch/arm/cpu/arm926ejs/at91/* arch/arm/cpu/armv7/at91/* arch/arm/cpu/at91-common/* Once directories are split, the motivation for refactorings across CPU directories is lost. Some files in arm920t/at91/ and arm926ejs/at91/ are so similar that they could be merged. [2] Tegra Tegra is a little bit special case where different CPUs are used for SPL and the main U-boot. To obey the arch/$(ARCH)/cpu/$(CPU)/$(SOC) structure, the source files must be placed across the CPUs, again SoC-common directory is necessary in the upper level. Moreover, there are several families in Tegra: Tegra20, Tegra30, Tegra114, Tegra124. Here again, the tegra-common directory is needed to contain commonly-used files. Tegra directories have been sprinkled in the directory structure. arch/arm/cpu/arm720t/tegra20 arch/arm/cpu/arm720t/tegra30 arch/arm/cpu/arm720t/tegra114 arch/arm/cpu/arm720t/tegra124 arch/arm/cpu/arm720t/tegra-common arch/arm/cpu/armv7/tegra20 arch/arm/cpu/armv7/tegra30 arch/arm/cpu/armv7/tegra114 arch/arm/cpu/armv7/tegra124 arch/arm/cpu/armv7/tegra-common arch/arm/cpu/tegra20-common arch/arm/cpu/tegra30-common arch/arm/cpu/tegra114-common arch/arm/cpu/tegra124-common arch/arm/cpu/tegra-common As you see, splitting SoC code by the CPU is not going well, especially for ARM. Why don't we collect SoC-specific files into a single place? A good example we can follow is Linux's arch/arm/mach-* structure. This item was discussed in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188548/ Looks like I got some positive responses and we are almost ready to start this movement. This commit prepares arch/arm/Makefile for describing machdirs in it. After this commit, we can move SoC directory to arch/arm/mach-$(SOC) in simple steps although some cases such as AT91 and Tegra need more fixes. What we generally have to do is: [1] Move files arch/arm/cpu/$(CPU)/$(SOC)/* to arch/arm/mach-$(SOC)/* [2] Add machine entry into arch/arm/Makefile [3] Remove "obj-y += $(SOC)" from arch/arm/cpu/$(CPU)/Makefile [4] Fix the Kconfig file path in arch/arm/Kconfig [5] Modify MAINTAINERS if necessary Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:02 +00:00
# Machine directory name. This list is sorted alphanumerically
# by CONFIG_* macro name.
arm: apple: Add initial support for Apple's M1 SoC Add support for Apple's M1 SoC that is used in "Apple Silicon" Macs. This builds a basic U-Boot that can be used as a payload for the m1n1 boot loader being developed by the Asahi Linux project. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Add MAINTAINERS entry]
2021-10-23 14:58:03 +00:00
machine-$(CONFIG_ARCH_APPLE) += apple
aspeed: Add drivers common to all Aspeed SoCs Add support for Watchdog Timer, which is compatible with AST2400 and AST2500 watchdogs. There is no uclass for Watchdog yet, so the driver does not follow the driver model. It also uses fixed clock, so no clock driver is needed. Add support for timer for Aspeed ast2400/ast2500 devices. The driver actually controls several devices, but because all devices share the same Control Register, it is somewhat difficult to completely decouple them. Since only one timer is needed at the moment, this should be OK. The timer uses fixed clock, so does not rely on a clock driver. Add sysreset driver, which uses watchdog timer to do resets and particular watchdog device to use is hardcoded (0) Reviewed-by: Simon Glass <sjg@chromium.org>
2017-01-18 21:44:55 +00:00
machine-$(CONFIG_ARCH_ASPEED) += aspeed
ARM: at91: collect SoC sources into mach-at91 This commit moves source files as follows: arch/arm/cpu/arm920t/at91/* -> arch/arm/mach-at91/arm920t/* arch/arm/cpu/arm926ejs/at91/* -> arch/arm/mach-at91/arm926ejs/* arch/arm/cpu/armv7/at91/* -> arch/arm/mach-at91/armv7/* arch/arm/cpu/at91-common/* -> arch/arm/mach-at91/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Andreas Bießmann <andreas.devel@googlemail.co>
2015-02-20 08:04:03 +00:00
machine-$(CONFIG_ARCH_AT91) += at91
ARM: bcm283x: merge BCM2835/BCM2836 directories into mach-bcm283x BCM2835 (used on Raspberry Pi) and BCM2836 (used on Raspberry Pi 2) are similar enough. One of the biggest differences is the ARM processor. It is reasonable to collect the source files into a single place, arch/arm/mach-bcm283x/. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-03-19 10:42:56 +00:00
machine-$(CONFIG_ARCH_BCM283X) += bcm283x
arm: bcmbca: introduce the bcmbca architecture and 47622 SOC This is the initial support for Broadcom's ARM-based 47622 SOC. In this change, our first SOC is an armv7 platform called 47622. The initial support includes a bare-bone implementation and dts with ARM PL011 uart. The SOC-specific code resides in arch/arm/mach-bcmbca/<soc> and board related code is in board/broadcom/bcmba. The u-boot image can be loaded from flash or network to the entry point address in the memory and boot from there. Signed-off-by: William Zhang <william.zhang@broadcom.com> Signed-off-by: Kursad Oney <kursad.oney@broadcom.com> Signed-off-by: Anand Gore <anand.gore@broadcom.com> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
2022-05-09 16:28:02 +00:00
machine-$(CONFIG_ARCH_BCMBCA) += bcmbca
board: arm: Add support for Broadcom BCM7445 Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org> Cc: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Florian Fainelli <f.fainelli@gmail.com>
2018-06-08 21:59:45 +00:00
machine-$(CONFIG_ARCH_BCMSTB) += bcmstb
ARM: davinci: move SoC sources to mach-davinci Move arch/arm/cpu/arm926ejs/davinci/* -> arch/arm/mach-davinci/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Rini <trini@ti.com>
2015-02-20 08:04:05 +00:00
machine-$(CONFIG_ARCH_DAVINCI) += davinci
ARM: exynos: move SoC sources to mach-exynos Move arch/arm/cpu/armv7/exynos/* to arch/arm/mach-exynos/* to allow reuse of existing code for ARMv8 based Exynos platforms. Cc: Minkyu Kang <mk7.kang@samsung.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2015-08-03 12:28:00 +00:00
machine-$(CONFIG_ARCH_EXYNOS) += exynos
ARM: hpe: gxp: add core support The GXP is the HPE BMC SoC that is used in the majority of current generation HPE servers. Traditionally the asic will last multiple generations of server before being replaced. Info about SoC: HPE GXP is the name of the HPE Soc. This SoC is used to implement many BMC features at HPE. It supports ARMv7 architecture based on the Cortex A9 core. It is capable of using an AXI bus to whicha memory controller is attached. It has multiple SPI interfaces to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple i2c engines to drive connectivity with a host infrastructure. There currently are no public specifications but this process is being worked. Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
2022-06-08 21:21:34 +00:00
machine-$(CONFIG_ARCH_GXP) += hpe
ARM: highbank: move SoC sources to mach-highbank Move arch/arm/cpu/armv7/highbank/* -> arch/arm/mach-highbank/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Rob Herring <robh@kernel.org>
2015-02-20 08:04:08 +00:00
machine-$(CONFIG_ARCH_HIGHBANK) += highbank
arm: add support for Hisilicon HiSTB family SoCs First supported chip is hi3798mv200 (which is similar to Hi3798cv200 used by poplar). Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
2023-04-01 11:17:33 +00:00
machine-$(CONFIG_ARCH_HISTB) += histb
arm: Add support for Qualcomm IPQ40xx family This introduces initial support for the popular Qualcomm IPQ40x8 and IPQ40x9 WiSoC series. IPQ40xx series have 4x Cortex A7 ARM-v7A cores. Supported are: IPQ4018, IPQ4019, IPQ4028 and IPQ4029. IPQ40x8 and IPQ40x9 use the same cores, but differ in addressable RAM size (1GB for IPQ40x9 and 256MB for IPQ40x8) and supported peripherals (IPQ40x8 lacks RGMII, LCD controller and EMMC/SDHCI controllers). IQP4028/IPQ4029 models differ from IPQ4018/IPQ4019 only by their rated temperatures rates with IPQ402X models being rated for wider temperature ranges. Initially this supports: * Simple clock driver (Only for UART1 now, will be extended) * Pinctrl driver (Supports UARTX and GPIO now, will be extended) * GPIOs already supported by msm_gpio driver with updates * UARTs already supported by serial_msm driver with updates Further peripherals will come in later patches. Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2020-07-06 08:37:54 +00:00
machine-$(CONFIG_ARCH_IPQ40XX) += ipq40xx
arm: K3: Add initial support for TI's K3 generation of SoCs Add support for Texas Instruments' K3 Generation Processor families. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-08-27 10:27:08 +00:00
machine-$(CONFIG_ARCH_K3) += k3
ARM: keystone: move SoC sources to mach-keystone Move arch/arm/cpu/armv7/keystone/* -> arch/arm/mach-keystone/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Rini <trini@ti.com>
2015-02-20 08:04:11 +00:00
machine-$(CONFIG_ARCH_KEYSTONE) += keystone
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
machine-$(CONFIG_ARCH_KIRKWOOD) += kirkwood
arm: lpc32xx: move SoC to mach-lpc32xx Following the example of most other SoCs in arch/$(ARCH)/cpu/$(CPU)/$(SOC) move the lpc32xx code from arch/arm/cpu/arm926ejs/lpc32xx to arch/arm/mach-lpc32xx. Following the checklist from commit 01f14456306c ("ARM: prepare for moving SoC sources into mach-*"): [1] move files from arch/arm/cpu/arm926ejs/lpc32xx to arch/arm/mach-lpx32xx [2] add machine entry to arch/arm/Makefile [3] remove "obj-y += ..." from arch/arm/cpu/arm926ejs/Makefile [4] fix the Kconfig file path in arch/arm/Kconfig [5] (no MAINTAINERS update) Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:36 +00:00
machine-$(CONFIG_ARCH_LPC32XX) += lpc32xx
arm: MediaTek: add basic support for MT7629 boards This adds a general board file based on MT7629 SoCs from MediaTek. Apart from the generic parts (cpu) we add some low level init codes and initialize the early clocks. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-15 02:07:52 +00:00
machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
arm: add initial support for Amlogic Meson and ODROID-C2 This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a board definition for ODROID-C2. This initial submission only supports UART and Ethernet (through the existing Designware driver). DTS files are the ones submitted to Linux arm-soc for 4.7 [1]. [1] https://patchwork.ozlabs.org/patch/603583/ Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-05-08 06:30:16 +00:00
machine-$(CONFIG_ARCH_MESON) += meson
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
machine-$(CONFIG_ARCH_MVEBU) += mvebu
arm: add mach-nexell (all files except header files) Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01: - SPL not supported yet --> no spl-directory in arch/arm/mach-nexell. Appropriate line in Makefile removed. - clock.c: 'section(".data")' added to declaration of clk_periphs[] and core_hz. - Kconfig: Changes to have a structure like in mach-bcm283x/Kconfig, e.g. "config ..." entries moved from other Kconfig. - timer.c: 'section(".data")' added to declaration of timestamp and lastdec. - arch/arm/mach-nexell/serial.c removed because this is for the UARTs of the S5P6818 SoC which is not supported yet. S5P4418 UARTs are different, here the (existing) PL011-code is used. - '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where possible (and similar). Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
2020-07-10 17:07:26 +00:00
machine-$(CONFIG_ARCH_NEXELL) += nexell
arm: nuvoton: Add support for Nuvoton NPCM750 BMC Add basic support for the Nuvoton NPCM750 EVB (Poleg). Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
2022-04-19 05:32:19 +00:00
machine-$(CONFIG_ARCH_NPCM) += npcm
arch/arm/Makefile: sort machine names The comment immediately above the block of machine directory names implored users to keep the macro names sorted, but, alas, this is no longer the case. Put the list of machine directory names back in alphanumerical order by CONFIG_* macro name, as the comment asks. Sort all the symbols as though they all followed the convention of having the string "ARCH_" in the middle of their definitions. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:37 +00:00
machine-$(CONFIG_ARCH_OMAP2PLUS) += omap2
rename symbol: CONFIG_ORION5X -> CONFIG_ARCH_ORION5X Have this symbol follow the pattern of all other such symbols. This patch removes a TODO from the code. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:38 +00:00
machine-$(CONFIG_ARCH_ORION5X) += orion5x
arm: Add support for Actions Semi OWL SoC family This commit adds Actions Semi OWL SoC family support with S900 as the first target SoC. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2018-06-14 18:08:31 +00:00
machine-$(CONFIG_ARCH_OWL) += owl
arch/arm/Makefile: sort machine names The comment immediately above the block of machine directory names implored users to keep the macro names sorted, but, alas, this is no longer the case. Put the list of machine directory names back in alphanumerical order by CONFIG_* macro name, as the comment asks. Sort all the symbols as though they all followed the convention of having the string "ARCH_" in the middle of their definitions. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:37 +00:00
machine-$(CONFIG_ARCH_RMOBILE) += rmobile
machine-$(CONFIG_ARCH_ROCKCHIP) += rockchip
arm: s5pc1xx: move SoC to mach-s5pc1xx move arm/arm/cpu/armv7/s5pc1xx to arch/arm/mach-s5pc1xx Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2015-11-20 06:24:57 +00:00
machine-$(CONFIG_ARCH_S5PC1XX) += s5pc1xx
arm: Add support for Qualcomm Snapdragon family First supported chip is APQ8016 (that is compatible with MSM8916). Drivers in SoC code: - Reset controller (PSHOLD) - Clock controller (very simple clock configuration for MMC and UART) Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2016-03-31 21:12:32 +00:00
machine-$(CONFIG_ARCH_SNAPDRAGON) += snapdragon
ARM: socfpga: move SoC sources to mach-socfpga Our recent trend is to collect SoC files into arch/arm/mach-(SOC). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-04-21 11:38:21 +00:00
machine-$(CONFIG_ARCH_SOCFPGA) += socfpga
rename symbol: CONFIG_STM32 -> CONFIG_ARCH_STM32 Have this symbol follow the pattern of all other such symbols. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:42 +00:00
machine-$(CONFIG_ARCH_STM32) += stm32
arm: stm32: add new architecture for STM32MP family - add new arch stm32mp for STM32 MPU/Soc based on Cortex A - support for stm32mp157 SOC - SPL is used as first boot stage loader - using driver model for all the drivers, even in SPL - all security feature are deactivated (ETZC and TZC) - reused STM32 MCU drivers when it is possible Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2018-03-12 09:46:10 +00:00
machine-$(CONFIG_ARCH_STM32MP) += stm32mp
arch/arm/Makefile: sort machine names The comment immediately above the block of machine directory names implored users to keep the macro names sorted, but, alas, this is no longer the case. Put the list of machine directory names back in alphanumerical order by CONFIG_* macro name, as the comment asks. Sort all the symbols as though they all followed the convention of having the string "ARCH_" in the middle of their definitions. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:37 +00:00
machine-$(CONFIG_ARCH_SUNXI) += sunxi
rename symbol: CONFIG_TEGRA -> CONFIG_ARCH_TEGRA Have this symbol follow the pattern of all other such symbols. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:41 +00:00
machine-$(CONFIG_ARCH_TEGRA) += tegra
arm: Add support for ST-Ericsson U8500 SoC The NovaThor U8500 SoC was released by ST-Ericsson in 2011. It was used for some development boards like the CALAO Systems Snowball SBC, but mass production was primarily for Android smartphones like the Samsung Galaxy S III mini. Previous support for U8500 was removed in commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch") since none of the boards were converted to generic boards before the deadline. The new code does not have much in common with the previous code. I have completely rewritten everything, embracing the Driver Model and device trees wherever possible. The U8500 support is a bit more minimal for now - my primary use case is to use U-Boot as alternative bootloader for some of the U8500 Samsung smartphones. At the moment U-Boot is chain-loaded from the original Samsung bootloader. A side effect of this is that we can (temporarily) get away without implementing some functionality - e.g. all clocks are already enabled by the original bootloader. More functionality will be added in future patches. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: John Rigby <john.rigby@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-01-04 17:45:17 +00:00
machine-$(CONFIG_ARCH_U8500) += u8500
arm: octeontx: Add support for OcteonTX SoC platforms This patch adds support for all OcteonTX 81xx/83xx boards from Marvell. For 81xx boards, use octeontx_81xx_defconfig and for 83xx boards, use octeontx_83xx_defconfig. Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
2019-10-20 01:37:55 +00:00
machine-$(CONFIG_ARCH_OCTEONTX) += octeontx
arm: octeontx2: Add support for OcteonTX2 SoC platforms This patch adds support for all OcteonTX2 96xx/95xx boards from Marvell. For 96xx boards, use octeontx_96xx_defconfig and for 95xx boards, use octeontx_95xx_defconfig. Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
2019-10-20 01:47:37 +00:00
machine-$(CONFIG_ARCH_OCTEONTX2) += octeontx2
ARM: UniPhier: move SoC sources to mach-uniphier Move arch/arm/cpu/armv7/uniphier/* -> arch/arm/mach-uniphier/* Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-26 17:26:42 +00:00
machine-$(CONFIG_ARCH_UNIPHIER) += uniphier
arch/arm/Makefile: sort machine names The comment immediately above the block of machine directory names implored users to keep the macro names sorted, but, alas, this is no longer the case. Put the list of machine directory names back in alphanumerical order by CONFIG_* macro name, as the comment asks. Sort all the symbols as though they all followed the convention of having the string "ARCH_" in the middle of their definitions. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:37 +00:00
machine-$(CONFIG_ARCH_VERSAL) += versal
arm64: versal-net: Add support for Versal NET platform Versal NET platform is based on Versal chip which is reusing a lot of IPs. For more information about new IPs please take a look at DT which describe currently supported devices. The patch is adding architecture and board support with soc detection algorithm. Generic setting should be very similar to Versal but it will likely diverge in longer run. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/320206853dc370ce290a4e7b6d0bb26b05206021.1663589964.git.michal.simek@amd.com
2022-09-19 12:21:02 +00:00
machine-$(CONFIG_ARCH_VERSAL_NET) += versal-net
ARM: zynq: rename CONFIG_ZYNQ to CONFIG_ARCH_ZYNQ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-03-16 07:43:24 +00:00
machine-$(CONFIG_ARCH_ZYNQ) += zynq
arm64: zynqmp: Move SoC sources to mach-zynqmp Similar changes was done for Zynq in past and this patch just follow this pattern to separate cpu code from SoC code. Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/* And also fix references to these files. Based on "ARM: zynq: move SoC sources to mach-zynq" (sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc) Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-01-17 07:22:43 +00:00
machine-$(CONFIG_ARCH_ZYNQMP) += zynqmp
arm: zynqmp: Add ZynqMP minimal R5 support Xilinx ZynqMP also contains dual Cortex R5 which can run U-Boot. This patch is adding minimal support to get U-Boot boot. U-Boot on R5 runs out of DDR with default configuration that's why DDR needs to be partitioned if there is something else running on arm64. Console is done via Cadence uart driver and the first Cadence Triple Timer Counter is used for time. This configuration with uart1 was tested on zcu100-revC. U-Boot 2018.05-rc2-00021-gd058a08d907d (Apr 18 2018 - 14:11:27 +0200) Model: Xilinx ZynqMP R5 DRAM: 512 MiB WARNING: Caches not enabled MMC: In: serial@ff010000 Out: serial@ff010000 Err: serial@ff010000 Net: Net Initialization Skipped No ethernet found. ZynqMP r5> There are two ways how to run this on ZynqMP. 1. Run from ZynqMP arm64 tftpb 20000000 u-boot-r5.elf setenv autostart no && bootelf -p 20000000 cpu 4 disable && cpu 4 release 10000000 lockstep or cpu 4 disable && cpu 4 release 10000000 split 2. Load via jtag when directly to R5 Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2018-04-12 15:39:46 +00:00
machine-$(CONFIG_ARCH_ZYNQMP_R5) += zynqmp-r5
ARM: prepare for moving SoC sources into mach-* In U-boot, the directory structure, arch/$(ARCH)/cpu/$(CPU)/$(SOC)/ has been adopted except that $(CPU) is missing from some architectures and $(SOC) is missing from some CPUs. This structure did not fit very well in some cases. [1] AT91 AT91 SoC family have been developed across some ARM processor generations. Generally speaking, some IPs are often re-used in the same SoC family (same SoC vendor) even when the main processor is updated. As a result, a SoC-common directory is needed in the upper level. Currently, AT91 source files are placed as follows: arch/arm/cpu/arm920t/at91/* arch/arm/cpu/arm926ejs/at91/* arch/arm/cpu/armv7/at91/* arch/arm/cpu/at91-common/* Once directories are split, the motivation for refactorings across CPU directories is lost. Some files in arm920t/at91/ and arm926ejs/at91/ are so similar that they could be merged. [2] Tegra Tegra is a little bit special case where different CPUs are used for SPL and the main U-boot. To obey the arch/$(ARCH)/cpu/$(CPU)/$(SOC) structure, the source files must be placed across the CPUs, again SoC-common directory is necessary in the upper level. Moreover, there are several families in Tegra: Tegra20, Tegra30, Tegra114, Tegra124. Here again, the tegra-common directory is needed to contain commonly-used files. Tegra directories have been sprinkled in the directory structure. arch/arm/cpu/arm720t/tegra20 arch/arm/cpu/arm720t/tegra30 arch/arm/cpu/arm720t/tegra114 arch/arm/cpu/arm720t/tegra124 arch/arm/cpu/arm720t/tegra-common arch/arm/cpu/armv7/tegra20 arch/arm/cpu/armv7/tegra30 arch/arm/cpu/armv7/tegra114 arch/arm/cpu/armv7/tegra124 arch/arm/cpu/armv7/tegra-common arch/arm/cpu/tegra20-common arch/arm/cpu/tegra30-common arch/arm/cpu/tegra114-common arch/arm/cpu/tegra124-common arch/arm/cpu/tegra-common As you see, splitting SoC code by the CPU is not going well, especially for ARM. Why don't we collect SoC-specific files into a single place? A good example we can follow is Linux's arch/arm/mach-* structure. This item was discussed in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188548/ Looks like I got some positive responses and we are almost ready to start this movement. This commit prepares arch/arm/Makefile for describing machdirs in it. After this commit, we can move SoC directory to arch/arm/mach-$(SOC) in simple steps although some cases such as AT91 and Tegra need more fixes. What we generally have to do is: [1] Move files arch/arm/cpu/$(CPU)/$(SOC)/* to arch/arm/mach-$(SOC)/* [2] Add machine entry into arch/arm/Makefile [3] Remove "obj-y += $(SOC)" from arch/arm/cpu/$(CPU)/Makefile [4] Fix the Kconfig file path in arch/arm/Kconfig [5] Modify MAINTAINERS if necessary Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:02 +00:00
arm: makefile: cleanup mach-imx usage All the SoCs use mach-imx has CONFIG_MACH_IMX selected, so the macro could be the gate to build arch/arm/mach-imx to simplify the rules. Signed-off-by: Peng Fan <peng.fan@nxp.com>
2022-07-26 08:40:32 +00:00
machine-$(CONFIG_MACH_IMX) += imx
ARM: prepare for moving SoC sources into mach-* In U-boot, the directory structure, arch/$(ARCH)/cpu/$(CPU)/$(SOC)/ has been adopted except that $(CPU) is missing from some architectures and $(SOC) is missing from some CPUs. This structure did not fit very well in some cases. [1] AT91 AT91 SoC family have been developed across some ARM processor generations. Generally speaking, some IPs are often re-used in the same SoC family (same SoC vendor) even when the main processor is updated. As a result, a SoC-common directory is needed in the upper level. Currently, AT91 source files are placed as follows: arch/arm/cpu/arm920t/at91/* arch/arm/cpu/arm926ejs/at91/* arch/arm/cpu/armv7/at91/* arch/arm/cpu/at91-common/* Once directories are split, the motivation for refactorings across CPU directories is lost. Some files in arm920t/at91/ and arm926ejs/at91/ are so similar that they could be merged. [2] Tegra Tegra is a little bit special case where different CPUs are used for SPL and the main U-boot. To obey the arch/$(ARCH)/cpu/$(CPU)/$(SOC) structure, the source files must be placed across the CPUs, again SoC-common directory is necessary in the upper level. Moreover, there are several families in Tegra: Tegra20, Tegra30, Tegra114, Tegra124. Here again, the tegra-common directory is needed to contain commonly-used files. Tegra directories have been sprinkled in the directory structure. arch/arm/cpu/arm720t/tegra20 arch/arm/cpu/arm720t/tegra30 arch/arm/cpu/arm720t/tegra114 arch/arm/cpu/arm720t/tegra124 arch/arm/cpu/arm720t/tegra-common arch/arm/cpu/armv7/tegra20 arch/arm/cpu/armv7/tegra30 arch/arm/cpu/armv7/tegra114 arch/arm/cpu/armv7/tegra124 arch/arm/cpu/armv7/tegra-common arch/arm/cpu/tegra20-common arch/arm/cpu/tegra30-common arch/arm/cpu/tegra114-common arch/arm/cpu/tegra124-common arch/arm/cpu/tegra-common As you see, splitting SoC code by the CPU is not going well, especially for ARM. Why don't we collect SoC-specific files into a single place? A good example we can follow is Linux's arch/arm/mach-* structure. This item was discussed in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188548/ Looks like I got some positive responses and we are almost ready to start this movement. This commit prepares arch/arm/Makefile for describing machdirs in it. After this commit, we can move SoC directory to arch/arm/mach-$(SOC) in simple steps although some cases such as AT91 and Tegra need more fixes. What we generally have to do is: [1] Move files arch/arm/cpu/$(CPU)/$(SOC)/* to arch/arm/mach-$(SOC)/* [2] Add machine entry into arch/arm/Makefile [3] Remove "obj-y += $(SOC)" from arch/arm/cpu/$(CPU)/Makefile [4] Fix the Kconfig file path in arch/arm/Kconfig [5] Modify MAINTAINERS if necessary Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:02 +00:00
machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
ARM: prepare for including <mach/*.h> This commit adds $(srctree)/arch/arm/$(machdirs)/include/mach to the headers search path. It allows us to replace "#include <asm/arch/foo.h>" with "#include <mach/foo.h>". As "#include <asm/arch/foo.h>" is still supported, we can modify each file one by one. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:19 +00:00
PLATFORM_CPPFLAGS += $(patsubst %,-I$(srctree)/%include,$(machdirs))
ARM: prepare for moving SoC sources into mach-* In U-boot, the directory structure, arch/$(ARCH)/cpu/$(CPU)/$(SOC)/ has been adopted except that $(CPU) is missing from some architectures and $(SOC) is missing from some CPUs. This structure did not fit very well in some cases. [1] AT91 AT91 SoC family have been developed across some ARM processor generations. Generally speaking, some IPs are often re-used in the same SoC family (same SoC vendor) even when the main processor is updated. As a result, a SoC-common directory is needed in the upper level. Currently, AT91 source files are placed as follows: arch/arm/cpu/arm920t/at91/* arch/arm/cpu/arm926ejs/at91/* arch/arm/cpu/armv7/at91/* arch/arm/cpu/at91-common/* Once directories are split, the motivation for refactorings across CPU directories is lost. Some files in arm920t/at91/ and arm926ejs/at91/ are so similar that they could be merged. [2] Tegra Tegra is a little bit special case where different CPUs are used for SPL and the main U-boot. To obey the arch/$(ARCH)/cpu/$(CPU)/$(SOC) structure, the source files must be placed across the CPUs, again SoC-common directory is necessary in the upper level. Moreover, there are several families in Tegra: Tegra20, Tegra30, Tegra114, Tegra124. Here again, the tegra-common directory is needed to contain commonly-used files. Tegra directories have been sprinkled in the directory structure. arch/arm/cpu/arm720t/tegra20 arch/arm/cpu/arm720t/tegra30 arch/arm/cpu/arm720t/tegra114 arch/arm/cpu/arm720t/tegra124 arch/arm/cpu/arm720t/tegra-common arch/arm/cpu/armv7/tegra20 arch/arm/cpu/armv7/tegra30 arch/arm/cpu/armv7/tegra114 arch/arm/cpu/armv7/tegra124 arch/arm/cpu/armv7/tegra-common arch/arm/cpu/tegra20-common arch/arm/cpu/tegra30-common arch/arm/cpu/tegra114-common arch/arm/cpu/tegra124-common arch/arm/cpu/tegra-common As you see, splitting SoC code by the CPU is not going well, especially for ARM. Why don't we collect SoC-specific files into a single place? A good example we can follow is Linux's arch/arm/mach-* structure. This item was discussed in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188548/ Looks like I got some positive responses and we are almost ready to start this movement. This commit prepares arch/arm/Makefile for describing machdirs in it. After this commit, we can move SoC directory to arch/arm/mach-$(SOC) in simple steps although some cases such as AT91 and Tegra need more fixes. What we generally have to do is: [1] Move files arch/arm/cpu/$(CPU)/$(SOC)/* to arch/arm/mach-$(SOC)/* [2] Add machine entry into arch/arm/Makefile [3] Remove "obj-y += $(SOC)" from arch/arm/cpu/$(CPU)/Makefile [4] Fix the Kconfig file path in arch/arm/Kconfig [5] Modify MAINTAINERS if necessary Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:02 +00:00
libs-y += $(machdirs)
Kbuild: introduce Makefile in arch/$ARCH/ Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-11-21 22:51:33 +00:00
head-y := arch/arm/cpu/$(CPU)/start.o
ifeq ($(CONFIG_SPL_BUILD),y)
spl: Remove CONFIG_SPL_START_S_PATH and rework the logic behind it In some cases, when we don't use CONFIG_SPL_FRAMEWORK nor are we on PowerPC using their specific SPL/TPL framework, we need to specify the start.S file to use for these typically very constrained systems. Do this within the Makefile logic, rather than introducing a string-based CONFIG option, as this would get slightly complex to do in Kconfig for a very limited number of users. Signed-off-by: Tom Rini <trini@konsulko.com>
2022-05-28 16:40:40 +00:00
ifeq ($(CONFIG_SYS_SOC)$(CONFIG_SPL_FRAMEWORK),"mxs")
head-y := arch/arm/cpu/arm926ejs/mxs/start.o
Kbuild: introduce Makefile in arch/$ARCH/ Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-11-21 22:51:33 +00:00
endif
endif
libs-y += arch/arm/cpu/$(CPU)/
libs-y += arch/arm/cpu/
libs-y += arch/arm/lib/
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
ifneq (,$(filter $(SOC), kirkwood))
libs-y += arch/arm/mach-mvebu/
Kbuild: introduce Makefile in arch/$ARCH/ Introduce a Makefile under arch/$ARCH/ and include it in the top Makefile (similar to Linux kernel). This allows further refactoringi like moving architecture-specific code out of global makefiles, deprecating config variables (CPU, CPUDIR, SOC) or deprecating arch/$ARCH/config.mk. In contrary to Linux kernel, U-Boot defines the ARCH variable by Kconfig, thus the arch Makefile can only included conditionally after the top config.mk. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-11-21 22:51:33 +00:00
endif
ARM: prepare for moving SoC sources into mach-* In U-boot, the directory structure, arch/$(ARCH)/cpu/$(CPU)/$(SOC)/ has been adopted except that $(CPU) is missing from some architectures and $(SOC) is missing from some CPUs. This structure did not fit very well in some cases. [1] AT91 AT91 SoC family have been developed across some ARM processor generations. Generally speaking, some IPs are often re-used in the same SoC family (same SoC vendor) even when the main processor is updated. As a result, a SoC-common directory is needed in the upper level. Currently, AT91 source files are placed as follows: arch/arm/cpu/arm920t/at91/* arch/arm/cpu/arm926ejs/at91/* arch/arm/cpu/armv7/at91/* arch/arm/cpu/at91-common/* Once directories are split, the motivation for refactorings across CPU directories is lost. Some files in arm920t/at91/ and arm926ejs/at91/ are so similar that they could be merged. [2] Tegra Tegra is a little bit special case where different CPUs are used for SPL and the main U-boot. To obey the arch/$(ARCH)/cpu/$(CPU)/$(SOC) structure, the source files must be placed across the CPUs, again SoC-common directory is necessary in the upper level. Moreover, there are several families in Tegra: Tegra20, Tegra30, Tegra114, Tegra124. Here again, the tegra-common directory is needed to contain commonly-used files. Tegra directories have been sprinkled in the directory structure. arch/arm/cpu/arm720t/tegra20 arch/arm/cpu/arm720t/tegra30 arch/arm/cpu/arm720t/tegra114 arch/arm/cpu/arm720t/tegra124 arch/arm/cpu/arm720t/tegra-common arch/arm/cpu/armv7/tegra20 arch/arm/cpu/armv7/tegra30 arch/arm/cpu/armv7/tegra114 arch/arm/cpu/armv7/tegra124 arch/arm/cpu/armv7/tegra-common arch/arm/cpu/tegra20-common arch/arm/cpu/tegra30-common arch/arm/cpu/tegra114-common arch/arm/cpu/tegra124-common arch/arm/cpu/tegra-common As you see, splitting SoC code by the CPU is not going well, especially for ARM. Why don't we collect SoC-specific files into a single place? A good example we can follow is Linux's arch/arm/mach-* structure. This item was discussed in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188548/ Looks like I got some positive responses and we are almost ready to start this movement. This commit prepares arch/arm/Makefile for describing machdirs in it. After this commit, we can move SoC directory to arch/arm/mach-$(SOC) in simple steps although some cases such as AT91 and Tegra need more fixes. What we generally have to do is: [1] Move files arch/arm/cpu/$(CPU)/$(SOC)/* to arch/arm/mach-$(SOC)/* [2] Add machine entry into arch/arm/Makefile [3] Remove "obj-y += $(SOC)" from arch/arm/cpu/$(CPU)/Makefile [4] Fix the Kconfig file path in arch/arm/Kconfig [5] Modify MAINTAINERS if necessary Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-20 08:04:02 +00:00
# deprecated
-include $(machdirs)/config.mk
Reference in a new issue Copy permalink