When PIE is enabled in start.S, u-boot/-spl use __rel_dyn_start
and _rel_dyn_end symbol to be loaded to and executed at a
different address than it was linked at.
u-boot-spl.lds is used in SPL build, but relocation information
section(.rela*) were discarded.
In line number 80 in arch/arm/cpu/armv8/u-boot-spl.lds
/DISCARD/ : { *(.rela*) }
If PIE enabled in SPL, __rel_dyn_start which is defined as
.rel_dyn_start in sections.c will be apended to the end of
.bss section.
In our ASPEED case, size of .bss section would let .rel_dyn_start
without 8-byte alignment, leading to alignment fault when
executing ldp instuction in pie_fix_loop.
Signed-off-by: Kevin Chen <kevin_chen@aspeedtech.com>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently get_tcr() takes an "el" parameter, to select the proper
version of the TCR_ELx system register.
This is problematic in case of the Apple M1, since it runs with
HCR_EL2.E2H fixed to 1, so TCR_EL2 is actually using the TCR_EL1 layout,
and we get the wrong version.
For U-Boot's purposes the only sensible choice here is the current
exception level, and indeed most callers treat it like that, so let's
remove that parameter and read the current EL inside the function.
This allows us to check for the E2H bit, and pretend it's EL1 in this
case.
There are two callers which don't care about the EL, and they pass 0,
which looks wrong, but is irrelevant in these two cases, since we don't
use the return value there. So the change cannot affect those two.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Mark Kettenis <kettenis@openbsd.org>
Since COUNTER_FREQUENCY is obselete, so set cntfrq_el0 if
CONFIG_COUNTER_FREQUENCY is valid
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
The branch_if_master macro jumps to a label if the CPU is the "master"
core, which we define as having all affinity levels set to 0. To check
for this condition, we need to mask off some bits from the MPIDR
register, then compare the remaining register value against zero.
The implementation of this was slighly broken (it preserved the upper
RES0 bits), overly complicated and hard to understand, especially since
it lacked comments. The same was true for the very similar
branch_if_slave macro.
Use a much shorter assembly sequence for those checks, use the same
masking for both macros (just negate the final branch), and put some
comments on them, to make it clear what the code does.
This allows to drop the second temporary register for branch_if_master,
so we adjust all call sites as well.
Also use the opportunity to remove a misleading comment: the macro
works fine on SoCs with multiple clusters. Judging by the commit
message, the original problem with the Juno SoC stems from the fact that
the master CPU *can* be configured to be from cluster 1, so the
assumption that the master CPU has all affinity values set to 0 does not
hold there. But this is already mentioned above in a comment, so remove
the extra comment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
In ARMv8 we have the choice between two stack pointers to use: SP_EL0 or
SP_ELx, which is banked per exception level. This choice is stored in
the SP field of PState, and can be read and set via the SPSel special
register. When the CPU takes an exception, it automatically switches to
the SP_ELx stack pointer.
Trusted Firmware enters U-Boot typically with SPSel set to 1, so we use
SP_ELx all along as our sole stack pointer, both for normal operation and
for exceptions.
But if we now for some reason enter U-Boot with SPSel cleared, we will
setup and use SP_EL0, which is fine, but leaves SP_ELx uninitialised.
When we now take an exception, we try to save the GPRs to some undefined
location, which will usually end badly.
To make sure we always have SP_ELx pointing to some memory, set SPSel
to 1 in the early boot code, to ensure safe operation at all times.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The ARMv8 architecture describes the "SError interrupt" as the fourth
kind of exception, next to synchronous exceptions, IRQs, and FIQs.
Those SErrors signal exceptional conditions from which the system might
not easily recover, and are normally generated by the interconnect as a
response to some bus error. A typical situation is access to a
non-existing memory address or device, but it might be deliberately
triggered by a device as well.
The SError interrupt replaces the Armv7 asynchronous abort.
Trusted Firmware enters U-Boot (BL33) typically with SErrors masked,
and we never enable them. However any SError condition still triggers
the SError interrupt, and this condition stays pending, it just won't be
handled. If now later on the Linux kernel unmasks the "A" bit in PState,
it will immediately take the exception, leading to a kernel crash.
This leaves many people scratching their head about the reason for
this, and leads to long debug sessions, possibly looking at the wrong
places (the kernel, but not U-Boot).
To avoid the situation, just unmask SErrors early in the ARMv8 boot
process, so that the U-Boot exception handlers reports them in a timely
manner. As SErrors are typically asynchronous, the register dump does
not need to point at the actual culprit, but it should happen very
shortly after the condition.
For those exceptions to be taken, we also need to route them to EL2,
if U-Boot is running in this exception level.
This removes the respective code snippet from the Freescale lowlevel
routine, as this is now handled in generic ARMv8 code.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
There is some code that tries to "reset" the SCTLR_ELx register early in
the boot process. The idea seems to be to guarantee some sane settings
that U-Boot actually relies on, for instance running in little-endian
mode, with the MMU off initially.
However the current code has multiple problems:
- For a start, no platform or config defines the symbol that would
enable that code.
- The code itself really only works if the bits that it tries to clear
are already cleared:
- If we run in big-endian mode initially, any previous loads would have
been wrong already. That applies to the (optional) relocation code,
but more prominently to the mask that it uses to clear those bits:
"ldr x1, =0xfdfffffa" looks innocent, but actually involves a memory
access to the literal pool, using the current endianness.
- If we run with the MMU enabled, we are probably doomed already. We
*could* hope that we are running with an identity mapping, but would
need to do some cache maintenance to avoid losing dirty cache lines.
- The idea of doing a read-modify-write of SCTLR is somewhat
questionable to begin with, because as the owner of the current
exception level we should initialise all bits of this register with a
certain fixed value.
- The code is unnecessarily complicated, and the function name is
misspelled.
While those problems *could* admittedly be fixed, the point that is does
not seem to be used at all at the moment tells me we should just remove
this code, and be it to not give a bad example.
If people care, I could introduce some proper SCTLR initialisation code.
We are about to work this out for the boot-wrapper[1] as we speak, but
apparently we got away without doing this in U-Boot ever since, so it
might not be worth the potential trouble.
[1] https://lore.kernel.org/linux-arm-kernel/20220114105653.3003399-7-mark.rutland@arm.com/
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
CNTFRQ_EL0 is only writable from the highest supported exception
level on the platform. For Armv8-A, this is typically EL3, but
technically EL2 and EL3 are optional so it may need to be
initialized at EL2 or EL1. For Armv8-R, the highest exception
level is always EL2.
This patch moves the initialization outside of the switch_el
block and uses a new macro branch_if_not_highest_el which
dynamically detects whether it is at the highest supported
exception level.
Linux's docs state that CNTFRQ_EL0 should be initialized by the
bootloader. If not set, the the U-Boot prompt countdown hangs.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
On implementations that support VHE, the layout of the CPTR_EL2
register depends on whether HCR_EL2.E2H is set. If the bit is
set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
be accessed through that register. In that case, jump to the
EL1 code to enable access to the FP/SIMD registers. This allows
U-Boot to run on systems that pass control to U-Boot in EL2 with
EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Acked-by: Marc Zyngier <maz@kernel.org>
When the actual offset between link and runtime address is zero, there
is no need for patching up U-Boot early when running with
CONFIG_POSITION_INDEPENDENT.
Skip the whole routine when the distance is 0.
This helps when U-Boot is loaded into ROM, or in otherwise sensitive
memory locations.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Linking a U-Boot larger than 1MB fails with PIE enabled:
u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
defined in .bss_start section in u-boot.
This extends the supported range by using adrp & add to load symbols
early while starting up.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
PIE requires a 4K aligned load address. If this is not met, trap
the startup sequence in a WFI loop rather than running into obscure
failures.
Tested-by: Michal Simek <michal.simek@xilinx.com>
Suggested-by: André Przywara <andre.przywara@arm.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
ARM Architecture reference manual clearly states that PE pipeline
should be flushed after changes to some system registers. Refer to
paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI
0487B.a).
Failing to issue instruction synchronization barrier can lead to
spurious errors, like synchronous exception when accessing FPU
registers. This is very prominent on CPUs with long instruction
pipeline, like ARM Cortex A72.
This change fixes the following U-Boot panic:
"Synchronous Abort" handler, esr 0x1fe00000
elr: 00000000800948cc lr : 0000000080091e04
x0 : 00000000801ffdc8 x1 : 00000000000000c8
x2 : 00000000800979d4 x3 : 00000000801ffc60
x4 : 00000000801ffd40 x5 : ffffff80ffffffd8
x6 : 00000000801ffd70 x7 : 00000000801ffd70
x8 : 000000000000000a x9 : 0000000000000000
x10: 0000000000000044 x11: 0000000000000000
x12: 0000000000000000 x13: 0000000000000000
x14: 0000000000000000 x15: 0000000000000000
x16: 000000008008b2e0 x17: 0000000000000000
x18: 00000000801ffec0 x19: 00000000800957b0
x20: 00000000000000c8 x21: 00000000801ffdc8
x22: 000000008009909e x23: 0000000000000000
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000000000 x29: 00000000801ffc50
Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0)
While executing instruction
str q0, [sp, #112]
in vsnprintf() prologue. This panic was observed only on Cortex A72 so
far.
This patch places ISBs on other strategic places as well.
Also, this probably is the right fix for the issue workarounded in the
commit 45f41c134b ("ARM: uniphier: add weird workaround code for LD20")
Reported-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Suggested-by: Julien Grall <julien.grall.oss@gmail.com>
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
CC: Tom Rini <trini@konsulko.com>
CC: Masahiro Yamada <yamada.masahiro@socionext.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien@xen.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This is fix to:
e2a12f590d rockchip: use 'arch-rockchip' as header file path
The V2 of origin patch set has fix this, but we merge V1 by
mistake, so lets correct it.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
rockchip platform header file is in 'arch-rockchip'
instead of arch-$(SOC) for all SoCs.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Commit 1416e2d225 ("armv8: make SPL exception vectors optional") had a
typo in it which effectively disabled exception handling in SPL code always.
Since nobody complained, I guess we may as well disable exception handling
in SPL always by default.
So fix the bug to make the config option effective, but disable exception
handling in SPL by default. This gets us to the same functionality as before
by default, but with much less code included in the binary.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Even though the exception vector table is a fundamental part of the ARM
architecture, U-Boot mostly does not make real use of it, except when
crash dumping. But having it in takes up quite some space, partly due to
the architectural alignment requirement of 2KB. Since we don't take special
care of that, the compiler adds a more or less random amount of padding
space, which increases the image size quite a bit, especially for the SPL.
On a typical Allwinner build this is around 1.5KB of padding, plus 1KB
for the vector table (mostly padding space again), then some extra code
to do the actual handling. This amounts to almost 10% of the maximum image
size, which is quite a lot for a pure debugging feature.
Add a Kconfig symbol to allow the exception vector table to be left out
of the build for the SPL.
For now this is "default y" for everyone, but specific defconfigs,
platforms or .config files can opt out here at will, to mitigate the code
size pressure we see for some SPLs.
Signed-off-by: Andre Przywara <andre.przywara@arm.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>
Allow placing a Linux kernel image header at the start of the U-Boot
binary. This is useful since the image header reports the amount of memory
(BSS and similar) that U-Boot needs to use, but that isn't part of the
binary size. This can be used by the code that loads U-Boot into memory to
determine where to load U-Boot, based on other users of memory.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
855873: An eviction might overtake a cache clean operation
Workaround: The erratum can be avoided by upgrading cache clean by
address operations to cache clean and invalidate operations. For
Cortex-A53 r0p3 and later release, this can be achieved by setting
CPUACTLR.ENDCCASCI to 1.
This patch is to implement the workaround for this erratum.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
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>
When U-Boot boots from EL2, skip some lowlevel init code requiring
EL3, including CCI-400/CCN-504, trust zone, GIC, etc. These
initialization tasks are carried out before U-Boot runs. This applies
to the RAM version image used for SPL boot if PPA is loaded first.
Signed-off-by: York Sun <york.sun@nxp.com>
The SMPEN bit is located in the cpuectlr_el1 register and not the
cpuactlr_el1 register. Adjust the comment accordingly and also fix
a spelling error.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
CC: Mingkai Hu <mingkai.hu@nxp.com>
CC: Gong Qianyu <Qianyu.Gong@nxp.com>
CC: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
CC: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
CC: York Sun <york.sun@nxp.com>
CC: Albert Aribaud <albert.u.boot@aribaud.net>
CC: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: York Sun <york.sun@nxp.com>
For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
of boot protocol. To fix this issue, input argument 4 is added for
armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4 will
be set to the right value, such as zero.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: York Sun <york.sun@nxp.com>
For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
set. The SMPEN bit should be set before enabling the data cache.
If not enabled, the cache is not coherent with other cores and
data corruption could occur.
For A57/A72, SMPEN bit enables the processor to receive instruction
cache and TLB maintenance operations broadcast from other processors
in the cluster. This bit should be set before enabling the caches and
MMU, or performing any cache and TLB maintenance operations.
Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Using CONFIG_IS_ENABLED() doesn't work in SPL. This patch replaces the only
occurrence of CONFIG_IS_ENABLED() in start.S to a regular #if defined().
It also adds "&& !defined(CONFIG_SPL_BUILD)" to that #if statement because
the spin-table code can't currently work in SPL, and the spin-table file
isn't even compiled in SPL.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
For prepending some board specific header area to U-Boot images we
were so far including a header file with a macro definition containing
the actual header specification.
This works fine if there are just a few statements and if there is only
one alternative.
However adding more complex code quickly gets messy with this approach,
so let's just drop that intermediate macro and let the #include actually
insert the code directly.
This converts the callers and the callees, but doesn't change anything
at this point.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Steve Rae <steve.rae@raedomain.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The boot0 hook we have so far is applied _after_ the initial branch
to the "reset" entry point. An upcoming change requires even this
branch to be changed, so we apply the hook macro at the earliest
point, and have the branch in the hook file as well.
This is no functional change at this point, just refactoring to simplify
upcoming patches.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
To support loading a 32-bit OS, the execution state will change from
AArch64 to AArch32 when jumping to kernel.
The architecture information will be got through checking FIT image,
then U-Boot will load 32-bit OS or 64-bit OS automatically.
Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Signed-off-by: Chenhui Zhao <chenhui.zhao@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Implement a hook to allow boards to save boot-time CPU state for later
use. When U-Boot is chain-loaded by another bootloader, CPU registers may
contain useful information such as system configuration information. This
feature mirrors the equivalent ARMv7 feature.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
There are two enable methods supported by ARM64 Linux; psci and
spin-table. The latter is simpler and helpful for quick SoC bring
up. My main motivation for this patch is to improve the spin-table
support, which allows us to boot an ARMv8 system without the ARM
Trusted Firmware.
Currently, we have multi-entry code in arch/arm/cpu/armv8/start.S
and the spin-table is supported in a really ad-hoc way, and I see
some problems:
- We must hard-code CPU_RELEASE_ADDR so that it matches the
"cpu-release-addr" property in the DT that comes from the
kernel tree.
- The Documentation/arm64/booting.txt in Linux requires that
the release address must be zero-initialized, but it is not
cared by the common code in U-Boot. We must do it in a board
function.
- There is no systematic way to protect the spin-table code from
the kernel. We are supposed to do it in a board specific manner,
but it is difficult to predict where the spin-table code will be
located after the relocation. So, it also makes difficult to
hard-code /memreserve/ in the DT of the kernel.
So, here is a patch to solve those problems; the DT is run-time
modified to reserve the spin-table code (+ cpu-release-addr).
Also, the "cpu-release-addr" property is set to an appropriate
address after the relocation, which means we no longer need the
hard-coded CPU_RELEASE_ADDR.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Upon further review this breaks most other platforms as we need to check
what core we're running on before touching it at all.
This reverts commit d73718f323.
Signed-off-by: Tom Rini <trini@konsulko.com>
For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
set. The SMPEN bit should be set before enabling the data cache.
If not enabled, the cache is not coherent with other cores and
data corruption could occur.
For A57/A72, SMPEN bit enables the processor to receive instruction
cache and TLB maintenance operations broadcast from other processors
in the cluster. This bit should be set before enabling the caches and
MMU, or performing any cache and TLB maintenance operations.
Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
gic_kick_secondary_cpus can directly return to the caller of
smp_kick_all_cpus. We do not have to use x29 register here.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Some SPL loaders (like Allwinner's boot0, and Broadcom's boot0)
require a header before the actual U-Boot binary to both check its
validity and to find other data to load. Sometimes this header may
only be a few bytes of information, and sometimes this might simply
be space that needs to be reserved for a post-processing tool.
Introduce a config option to allow assembler preprocessor commands
to be inserted into the code at the appropriate location; typical
assembler preprocessor commands might be:
.space 1000
.word 0x12345678
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Steve Rae <srae@broadcom.com>
Commit Notes:
Please note that the current code:
start.S (arm64) and
vectors.S (arm)
already jumps over some portion of data already, so this option basically
just increases the size of this region (and the resulting binary).
For use with Allwinner's boot0 blob there is a tool called boot0img[1],
which fills the header to allow booting A64 based boards.
For the Pine64 we need a 1536 byte header (including the branch
instruction) at the moment, so we add this to the defconfig.
[1] https://github.com/apritzel/pine64/tree/master/tools
END
Reviewed-by: Tom Rini <trini@konsulko.com>
Commit 724219a65f "ARM: always perform per-CPU GIC init" removed some
ifdefs to unify the MULTIENTRY-vs-non-MULTIENTRY paths. However, the
wrong endif was removed. This patch adds back that missing endif, and
adds a new ifdef to match the endif the now-correctly-terminated block
used to match against. Use "git show -U25 724219a65f55" to see enough
context to make the original issue clear.
In practical terms, this makes no difference to runtime behaviour. The
code that was incorrectly compiled into the binary when ifndef MULTIENTRY
is a no-op for other cases, since branch_if_master evaluates to a hard-
coded jump. The only issues were:
- A few extra instructions were added to the binary.
- The comment on the endif at the very end of the function, indicating
which ifdef it matched, were wrong.
An alternative might be to simply fix the comment on that trailing ifdef,
but that only addresses the second point above, not the first.
Fixes: 724219a65f ("ARM: always perform per-CPU GIC init")
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The current code in ARMv8's lowlevel_init() skips the per-CPU GIC
initialization ifndef CONFIG_ARMV8_MULTIENTRY. However, the per-CPU init
should always occur; it's just the one-time init that should only happen
on the master.
Once this consideration is taken into account, the only difference between
the paths when CONFIG_ARMV8_MULTIENTRY is undefined/defined is the use of
branch_if_slave. Naively, any unified code would need to invoke this
conditionally upon ifdef CONFIG_ARMV8_MULTIENTRY. However, branch_if_slave
already checks CONFIG_ARMV8_MULTIENTRY and does nothing if it isn't
defined, so we don't even need that ifdef at the call site.
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
There are ARM SoCs (such as the BCM2837) do not contain an ARM GIC. Fix
the ARMv8 CPU startup code to compile in this case.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
829520: Code bounded by indirect conditional branch might corrupt
instruction stream.
Workaround: Set CPUACTLR_EL1[4] = 1'b1 to disable the Indirect
Predictor.
833471: VMSR FPSCR functional failure or deadlock.
Workaround: Set CPUACTLR[38] to 1, which forces FPSCR write flush.
Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
This patch adds code which sets up 2-level page tables on ARM64 thus
extending available VA space. CPUs implementing 64k translation
granule are able to use direct PA-VA mapping of the whole 48 bit
address space.
It also adds the ability to reset the SCTRL register at the very beginning
of execution to avoid interference from stale mappings set up by early
firmware/loaders/etc.
Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Some platforms have the means to determine the counter frequency at
runtime, so give them an opportunity to do so.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This patch updates the setting of required bits for A57 cores erratas
- 828024 and 826974
Signed-off-by: Bhupesh Sharma <bhupesh.sharma at freescale.com>
Signed-off-by: Dai Haruki <dai.haruki at freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar at freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Various files are needlessly rebuilt every time due to the version and
build time changing. As version.h is not actually needed, remove the
include.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Macpaul Lin <macpaul@andestech.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: York Sun <yorksun@freescale.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Cc: Eric Jarrige <eric.jarrige@armadeus.org>
Cc: "David Müller" <d.mueller@elsoft.ch>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Torsten Koschorrek <koschorrek@synertronixx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Łukasz Majewski <l.majewski@samsung.com>
While the Freescale ARMv8 board LS2085A will enter U-Boot both
on a master and a secondary (slave) CPU, this is not the common
behaviour on ARMv8 platforms. The norm is that U-Boot is entered
from the master CPU only, while the other CPUs are kept in
WFI (wait for interrupt) state.
The code determining which CPU we are running on is using the
MPIDR register, but the definition of that register varies with
platform to some extent, and handling multi-cluster platforms
(such as the Juno) will become cumbersome. It is better to only
enable the multiple entry code on machines that actually need
it and disable it by default.
Make the single entry default and add a special
ARMV8_MULTIENTRY KConfig option to be used by the
platforms that need multientry and set it for the LS2085A.
Delete all use of the CPU_RELEASE_ADDR from the Vexpress64
boards as it is just totally unused and misleading, and
make it conditional in the generic start.S code.
This makes the Juno platform start U-Boot properly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds basic constructs in the ARMv8 u-boot code
to handle and apply Cortex-A57 specific erratas.
As and example, the framework showcases how erratas 833069, 826974
and 828024 can be handled and applied.
Later on this framework can be extended to include other
erratas.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
