Commit graph

18 commits

Author SHA1 Message Date
York Sun
e421b646fc armv8: fix gd after relocation
Commit 21f4486faa ("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>
2017-12-07 17:00:06 -05:00
Kever Yang
21f4486faa 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>
2017-11-17 07:44:13 -05:00
Stephen Warren
49e93875a6 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>
2017-11-17 07:44:13 -05:00
zijun_hu
01a8359989 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>
2017-10-08 16:19:56 -04:00
Philipp Tomsich
faa18dbe25 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>
2017-08-13 17:12:35 +02:00
Philipp Tomsich
c3be6190f9 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>
2017-08-13 17:12:21 +02:00
Philipp Tomsich
7a70c9985c 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>
2017-03-01 21:28:34 -05:00
Masahiro Yamada
07a63c7e7d 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>
2017-02-08 09:17:31 -05:00
Masahiro Yamada
b913c3f079 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>
2017-02-08 09:17:30 -05:00
Jeremy Hunt
b8cb51d0de 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
db910353a1 )
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>
2016-07-22 14:46:23 -04:00
Stephen Warren
a737028e80 arm: initialize gd for AArch64
Commit adc421e4ce "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: adc421e4ce ("arm: move gd handling outside of C code")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
2016-01-14 16:27:13 -05:00
Albert ARIBAUD
ecc306639e 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>
2016-01-13 21:05:17 -05:00
Simon Glass
931bec31b4 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>
2015-10-24 13:50:36 -04:00
Simon Glass
ed64190f67 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>
2015-09-12 09:00:35 +02:00
Thierry Reding
502a2aff76 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>
2015-07-27 15:54:28 -07:00
Scott Wood
b2d5ac5985 armv8/ls2085aqds: NAND boot support
This adds NAND boot support for LS2085AQDS, using SPL framework.
Details of forming NAND image can be found in README.

Signed-off-by: Scott Wood <scottwood@freescale.com>
[York Sun: Remove +S from defconfig after commit 252ed872]
Signed-off-by: York Sun <yorksun@freescale.com>
2015-04-23 16:46:50 -07:00
David Feng
b263302aa5 ARMv8: enable pre-allocation malloc
Allocate memory space for pre-allocation malloc and zero global data.
This code is partly from crt0.S.

Signed-off-by: David Feng <fenghua@phytium.com.cn>
2015-03-27 16:28:58 +01:00
David Feng
0ae7653128 arm64: core support
Relocation code based on a patch by Scott Wood, which is:
Signed-off-by: Scott Wood <scottwood@freescale.com>

Signed-off-by: David Feng <fenghua@phytium.com.cn>
2014-01-09 16:08:44 +01:00