Some SoCs of the H616 family use a die variant, that puts some CPU power
and reset control registers at a different address. There are examples
of two instances of the same board, using different die revisions of the
otherwise same H313 SoC. We need to write to a register in that block
*very* early in the SPL boot, to switch the core to AArch64.
Since the devices are otherwise indistinguishable, let the SPL code read
that die variant and use the respective RVBAR address based on that.
That is a bit tricky, since we need to do that in hand-coded AArch32
machine language, shared by all 64-bit SoCs. To avoid build dependencies
in this mess, we always provide two addresses to choose from, and just
give identical values for all other SoCs. This allows the same code to
run on all 64-bit SoCs, and controls this switch behaviour purely from
Kconfig.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
To switch the ARMv8 Allwinner SoCs into the 64-bit AArch64 ISA, we need
to program the 64-bit start code address into an MMIO mapped register
that shadows the architectural RVBAR register.
This address is SoC specific, with just two versions out there so far.
Now a third address emerged, on a *variant* of an existing SoC (H616).
Change the boot0.h start code to make this address a Kconfig
selectable option, to allow easier maintenance.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.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>
It turns out that there are at least 2 other SoCs which have basically
the same memory map, similar clocks and other features as H6. It's very
likely that we'll see more such SoCs in the future. In order to ease
porting to new SoCs and lower ifdef clutter, introduce common symbol for
them.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far we did not support the BootROM based FEL USB debug mode on the
64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
SPL runs in AArch64.
Returning back to AArch32 was not working as expected, since the RMR
reset into 32-bit mode always starts execution in the BootROM, but not
in the FEL routine.
After some debug and research and with help via IRC, the CPU hotplug
mechanism emerged as a solution: If a certain R_CPUCFG register contains
some magic, the BootROM will immediately branch to an address stored in
some other register. This works well for our purposes.
Enable the FEL feature by providing early AArch32 code to first save the
FEL state, *before* initially entering AArch64.
If we eventually determine that we should return to FEL, we reset back
into AArch32, and use the CPU hotplug mechanism to run some small
AArch32 code snippet that restores the initially saved FEL state.
That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
tool, with it returning into FEL mode, so that other payloads can be
transferred via FEL as well.
Tested on A64, H5 and H6.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Priit Laes <plaes@plaes.org> (on Olimex A64-Olinuxino)
Allwinner H6 has a different RVBAR address with A64/H5.
Add conditional RVBAR configuration into the code which does RMR switch.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.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>
The Allwinner A64 SoC starts execution in AArch32 mode, and both
the boot ROM and Allwinner's boot0 keep running in this mode.
So U-Boot gets entered in 32-bit, although we want it to run in AArch64.
By using a "magic" instruction, which happens to be an almost-NOP in
AArch64 and a branch in AArch32, we differentiate between being
entered in 64-bit or 32-bit mode.
If in 64-bit mode, we proceed with the branch to reset, but in 32-bit
mode we trigger an RMR write to bring the core into AArch64/EL3 and
re-enter U-Boot at CONFIG_SYS_TEXT_BASE.
This allows a 64-bit U-Boot to be both entered in 32 and 64-bit mode,
so we can use the same start code for the SPL and the U-Boot proper.
We use the existing custom header (boot0.h) functionality, but restrict
the existing boot0 header reservation to the non-SPL build now. A SPL
wouldn't need such header anyway. This allows to have both options
defined and lets us use one for the SPL and the other for U-Boot proper.
Also add arch/arm/mach-sunxi/rmr_switch.S, which contains the original
ARM assembly code and instructions how to re-generate the encoded
version.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.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>
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>
