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

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>

show more ...

Merge git://git.denx.de/u-boot-tegra

ARMv8: Allow dynamic early stack pointer

U-Boot typically uses a hard-coded value for the stack pointer before
relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
the initial SP

ARMv8: Allow dynamic early stack pointer

U-Boot typically uses a hard-coded value for the stack pointer before
relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
the initial SP at run-time. This is useful to avoid hard-coding addresses
into U-Boot, so that can be loaded and executed at arbitrary addresses and
thus avoid using arbitrary addresses at runtime. This option's value is
the offset added to &_bss_start in order to calculate the stack pointer.
This offset should be large enough so that the early malloc region, global
data (gd), and early stack usage do not overlap any appended DTB.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

armv8: fix gd after relocation

Commit 21f4486faa5d ("armv8: update gd after relocate") sets x18
without checking the return value of spl_relocate_stack_gd().

Reviewed-by: Stephen Warren <swarren@nv

armv8: fix gd after relocation

Commit 21f4486faa5d ("armv8: update gd after relocate") sets x18
without checking the return value of spl_relocate_stack_gd().

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: York Sun <york.sun@nxp.com>
CC: Kever Yang <kever.yang@rock-chips.com>
CC: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

show more ...

armv8: update gd after relocate

We need to update gd in assamble code after relocate,
this is a fix to:
adc421e arm: move gd handling outside of C code

Signed-off-by: Kever Yang <kever.yang@rock-ch

armv8: update gd after relocate

We need to update gd in assamble code after relocate,
this is a fix to:
adc421e arm: move gd handling outside of C code

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

show more ...

arm64: support running at addr other than linked to

This is required in the case where U-Boot is typically loaded and run at
a particular address, but for some reason the RAM at that location is not

arm64: support running at addr other than linked to

This is required in the case where U-Boot is typically loaded and run at
a particular address, but for some reason the RAM at that location is not
available, e.g. due to memory fragmentation loading other boot binaries or
firmware, splitting an SMP complex between various different OSs without
using e.g. the EL2 second-stage page tables to hide the memory asignments,
or due to known ECC failures.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

show more ...

ARMv8: get new GD address from gd->new_gd directly

the new GD address is calculated via board data BD currently
it require the new GD area locates below BD tightly, so a strict
constraint is imposed

ARMv8: get new GD address from gd->new_gd directly

the new GD address is calculated via board data BD currently
it require the new GD area locates below BD tightly, so a strict
constraint is imposed on memory layout which maybe make special
platform unpleasant.

fix it by getting new GD address from gd->new_gd directly.

Signed-off-by: zijun_hu <zijun_hu@htc.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-rockchip

armv8: TPL_STACK will always be defined, so test CONFIG_TPL_NEEDS_SEPARATE_STACK

Now that TPL_STACK has been moved off the whitelist (ok, I'm lying:
the 'moving off the whitelist' part comes in once

armv8: TPL_STACK will always be defined, so test CONFIG_TPL_NEEDS_SEPARATE_STACK

Now that TPL_STACK has been moved off the whitelist (ok, I'm lying:
the 'moving off the whitelist' part comes in once moveconfig
runs... which will be a few commits down the line) and added to
Kconfig, we need to test CONFIG_TPL_NEEDS_SEPARATE_STACK to see
whether the value from TPL_STACK should be used or whether we try to
inherit whatever SPL uses.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

armv8: spl: Support separate stack for TPL

To allow a TPL and SPL to run from different addresses/memories, we
need to split setup of the TPL and SPL stacks. To do so, we introduce
CONFIG_TPL_STACK

armv8: spl: Support separate stack for TPL

To allow a TPL and SPL to run from different addresses/memories, we
need to split setup of the TPL and SPL stacks. To do so, we introduce
CONFIG_TPL_STACK (not listed in Kconfig) which can be used to override
the initial stack pointer for TPL.

To provide backward compatibility for existing boards, this is added
as an optional configuration item and the normal search order (i.e.
SPL_STACK, then SYS_STACK) apply if not defined.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

armv8: spl: Call spl_relocate_stack_gd for ARMv8

As part of the startup process for boards using the SPL, we need to
call spl_relocate_stack_gd. This is needed to set up malloc with its
DRAM buffer.

armv8: spl: Call spl_relocate_stack_gd for ARMv8

As part of the startup process for boards using the SPL, we need to
call spl_relocate_stack_gd. This is needed to set up malloc with its
DRAM buffer.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

arm64: use store with auto-increment

Save one instruction.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

arm64: use xzr to zero-out the bss section

AArch64 has a zero register (xzr). Use it instead of x2.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chr

arm64: use xzr to zero-out the bss section

AArch64 has a zero register (xzr). Use it instead of x2.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

armv8: spl: Call board_init_r from crt0_64 in SPL

As part of the startup process for boards using the SPL, the
meaning of board_init_f changed such that it should return normally
rather than calling

armv8: spl: Call board_init_r from crt0_64 in SPL

As part of the startup process for boards using the SPL, the
meaning of board_init_f changed such that it should return normally
rather than calling board_init_r directly. (see
db910353a126d84fe8dff7a694ea792f50fcfb6a )
This was fixed in 32-bit arm, but broke when SPL was added to
64 bit arm. This fixes crt0_64 so that it calls board_init_r
during the SPL and removes the direct call from board_init_f
from the arm SPL example.

Signed-off-by: Jeremy Hunt <Jeremy.Hunt@DEShawResearch.com>

Acked-by: Simon Glass <sjg@chromium.org>

show more ...

arm: initialize gd for AArch64

Commit adc421e4cee8 "arm: move gd handling outside of C code" removed
the call to arch_setup_gd() on ARM and replaced it with assembly code
in crt0.S. However, AArch64

arm: initialize gd for AArch64

Commit adc421e4cee8 "arm: move gd handling outside of C code" removed
the call to arch_setup_gd() on ARM and replaced it with assembly code
in crt0.S. However, AArch64 uses a different startup file, and the same
change was not made to it. This leaves gd uninitialized on AArch64, which
typically leads to hangs or crashes. This change fixes that.

Fixes: adc421e4cee8 ("arm: move gd handling outside of C code")
Signed-off-by: Stephen Warren <swarren@nvidia.com>

show more ...

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime en

Fix board init code to respect the C runtime environment

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

arm: Switch aarch64 to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to

arm: Switch aarch64 to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.

Drop the unneeded code and adjust the hooks in board_f.c to cope.

Tested on LS2085ARDB and LS2085AQDS (armv8 SoC).
Tested-by: York Sun <yorksun@freescale.com>

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge branch 'master' of git://git.denx.de/u-boot-arm

arm: Correct comments in crt0.S for the recent SPL improvements

The current comments need a bit of tweaking since we now support stack
and global_data relocation in SPL. Also add a reference to the

arm: Correct comments in crt0.S for the recent SPL improvements

The current comments need a bit of tweaking since we now support stack
and global_data relocation in SPL. Also add a reference to the README.

For AArch64 this is not implemented, so leave a TODO for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tim Harvey <tharvey@gateworks.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-tegra

arm64: Handle arbitrary CONFIG_SYS_MALLOC_F_LEN values

The encoding of the sub instruction used to handle CONFIG_SYS_MALLOC_F_LEN
can only accept certain values, and the set of acceptable values dif

arm64: Handle arbitrary CONFIG_SYS_MALLOC_F_LEN values

The encoding of the sub instruction used to handle CONFIG_SYS_MALLOC_F_LEN
can only accept certain values, and the set of acceptable values differs
between the AArch32 and AArch64 instructions sets. The default value of
CONFIG_SYS_MALLOC_F_LEN works with either ISA. Tegra uses a non-default
value that can only be encoded in the AArch32 ISA. Fix the AArch64 crt0
assembly so it can handle completely arbitrary values.

Signed-off-by: Thierry Reding <treding@nvidia.com>
[twarren: trimmed Thierry's patch to remove changes already present]
Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, cleaned up patch, wrote description, re-wrote subject]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'u-boot/master' into 'u-boot-arm/master'

Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq