Add configuration for ARMv8-M aarch32 core, which are currently
Cortex-M23/M33 cores. These cores are treated similar to ARMv7-M
cores, except the code has to be compiled with matching compiler
-march=armv8-m.main flag . These cores have no MMU, they have MPU,
which is currently not configured.

Unlike ARMv7-M, these cores have 512 interrupt vectors. While the
SYS_ARM_ARCH should be set to 8, it is set to 7 because all of the
initialization code is built from arch/arm/cpu/armv7m and not armv8.
Furthermore, CONFIG_ARM64 must be disabled, although DTs for devices
using these cores do come from arch/arm64/boot/dts.

To avoid excess duplication in Makefiles, introduce one new Kconfig
symbol, CPU_V7M_V8M. The CPU_V7M_V8M cover both ARMv7-M and ARMv8-M
cores.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Udit Kumar <u-kumar1@ti.com>

Introduce new mode of relocation which relocates only data, not code.
This is mainly meant to relocate data to read-write portion of the RAM,
while the code remains in read-only portion of the RAM from which it is
allowed to execute. This split configuration is present on various secure
cores.

The result of the relocation is U-Boot running at its original address,
data relocated to the end of DRAM, but with added read-write area offset.
The U-Boot binary area is not reserved from the end of the DRAM in this
relocation mode, because U-Boot itself is not relocated.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

The code in the __XSCALE__ section is unused, since there is no more
XScale support in U-Boot. Remove the stale code. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Because the beginning is already computed

Signed-off-by: Liya Huang <1425075683@qq.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

It is a bad idea, and more modern toolchains will fail, if you declare
an assembly function to be global and then weak, instead of declaring it
weak to start with. Update assorted assembly files to use the WEAK macro
directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Pali Rohár <pali@kernel.org>

There is currently a problem that U-Boot can not work on ARMv4
because assembly imlementations of memcpy() and some other functions
use "bx lr" instruction that is not available on ARMv4 ("mov pc, lr"
should be used instead).

A working preprocessor-based solution to this problem is found in
arch/arm/lib/relocate.S. Move it to the "ret" macro in
arch/arm/include/asm/assembler.h and change all "bx lr" code
to "ret lr" in functions that may run on ARMv4. Linux source code
deals with this problem in the same manner.

v1 -> v2:
Comment update. Pointed out by Andre Przywara.

Signed-off-by: Sergei Antonov <saproj@gmail.com>
CC: Samuel Holland <samuel@sholland.org>
CC: Ye Li <ye.li@nxp.com>
CC: Simon Glass <sjg@chromium.org>
CC: Andre Przywara <andre.przywara@arm.com>
CC: Marek Vasut <marex@denx.de>
CC: Sean Anderson <sean.anderson@seco.com>
CC: Tom Rini <trini@konsulko.com>

The generic ARM relocate_code function was using its own function entry
point as a relocation base, and it was obtaining that address by using
the "adr" instruction on that entry point label.
However that label is not just an ordinary label, instead we explicitly
mark it as a function start address. Normally that doesn't change much
(other than for debugging), but when assembled in Thumb mode, newer
versions of the GNU assembler prepare everything for this address being
used as the argument to a "bx" call, so make sure bit 0 is set in there
to mark this function as Thumb code. Of course this doesn't end up very
well when we use this address for the ensuing memcpy operation.

To avoid this problem, and to solve it in a robust way, add an extra
label, which is not marked as a function entry, and use that for the adr
instruction. This lets all assemblers generate the right immediate offset
in the "adr" instruction.

This fixes in particular ARMv7-M ports when using GNU binutils v2.37 or
newer (commit d3e52e120b68 seems to trigger the change in behaviour).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Jesse Taube <mr.bossman075@gmail.com>

A U-Boot image could be loaded and executed at a different
location than it was linked at.

For example, Aspeed takes a stable release version of U-Boot image
as the golden one for recovery purposes. When the primary storage
such as flash is corrupted, the golden image would be loaded to any
SRAM/DRAM address on demands through ethernet/UART/etc and run for
rescue.

To deal with this condition, the PIE is needed as there is only one
signed, golden image, which could be however executed at different
places.

This patch adds the PIE support for ARMv7 platform.

Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>

unified syntax should be selected by config ARM_ASM_UNIFIED

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>

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>