Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-17 16:53:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/include/asm/arch-sunxi/boot0.h

60 lines
2 KiB
C
Raw Normal View History

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>
2018-05-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
arm/arm64: implement a boot header capability 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>
2016-05-31 17:45:06 +00:00
/*
* Configuration settings for the Allwinner A64 (sun50i) CPU
*/
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) && !defined(CONFIG_SPL_BUILD)
arm/arm64: implement a boot header capability 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>
2016-05-31 17:45:06 +00:00
/* reserve space for BOOT0 header information */
ARM: boot0 hook: remove macro, include whole header file 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>
2017-01-02 11:48:34 +00:00
b reset
arm/arm64: implement a boot header capability 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>
2016-05-31 17:45:06 +00:00
.space 1532
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
#elif defined(CONFIG_ARM_BOOT_HOOK_RMR)
/*
* Switch into AArch64 if needed.
* Refer to arch/arm/mach-sunxi/rmr_switch.S for the original source.
*/
tst x0, x0 // this is "b #0x84" in ARM
b reset
.space 0x7c
sunxi: Add arm64 FEL support 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)
2016-08-23 21:19:30 +00:00
sunxi: arm64: boot0.h: runtime check for RVBAR address 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>
2023-04-05 20:30:11 +00:00
.word 0xe28f0070 // add r0, pc, #112 // @(fel_stash - .)
.word 0xe59f106c // ldr r1, [pc, #108] // fel_stash - .
sunxi: Add arm64 FEL support 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)
2016-08-23 21:19:30 +00:00
.word 0xe0800001 // add r0, r0, r1
.word 0xe580d000 // str sp, [r0]
.word 0xe580e004 // str lr, [r0, #4]
.word 0xe10fe000 // mrs lr, CPSR
.word 0xe580e008 // str lr, [r0, #8]
.word 0xee11ef10 // mrc 15, 0, lr, cr1, cr0, {0}
.word 0xe580e00c // str lr, [r0, #12]
.word 0xee1cef10 // mrc 15, 0, lr, cr12, cr0, {0}
.word 0xe580e010 // str lr, [r0, #16]
sunxi: arm64: boot0.h: runtime check for RVBAR address 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>
2023-04-05 20:30:11 +00:00
.word 0xe59f1034 // ldr r1, [pc, #52] ; RVBAR_ADDRESS
.word 0xe59f0034 // ldr r0, [pc, #52] ; SUNXI_SRAMC_BASE
.word 0xe5900024 // ldr r0, [r0, #36] ; SRAM_VER_REG
.word 0xe21000ff // ands r0, r0, #255 ; 0xff
.word 0x159f102c // ldrne r1, [pc, #44] ; RVBAR_ALTERNATIVE
.word 0xe59f002c // ldr r0, [pc, #44] ; CONFIG_*TEXT_BASE
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
.word 0xe5810000 // str r0, [r1]
.word 0xf57ff04f // dsb sy
.word 0xf57ff06f // isb sy
.word 0xee1c0f50 // mrc 15, 0, r0, cr12, cr0, {2} ; RMR
.word 0xe3800003 // orr r0, r0, #3
.word 0xee0c0f50 // mcr 15, 0, r0, cr12, cr0, {2} ; RMR
.word 0xf57ff06f // isb sy
.word 0xe320f003 // wfi
.word 0xeafffffd // b @wfi
sunxi: boot0.h: allow RVBAR MMIO address customisation 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>
2022-12-08 20:33:57 +00:00
.word CONFIG_SUNXI_RVBAR_ADDRESS // writable RVBAR mapping addr
sunxi: arm64: boot0.h: runtime check for RVBAR address 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>
2023-04-05 20:30:11 +00:00
.word SUNXI_SRAMC_BASE
.word CONFIG_SUNXI_RVBAR_ALTERNATIVE // address for die variant
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
#ifdef CONFIG_SPL_BUILD
.word CONFIG_SPL_TEXT_BASE
#else
Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASE 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>
2022-10-21 00:22:39 +00:00
.word CONFIG_TEXT_BASE
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
#endif
sunxi: Add arm64 FEL support 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)
2016-08-23 21:19:30 +00:00
.word fel_stash - .
sunxi: A64: do an RMR switch if started in AArch32 mode 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>
2017-01-02 11:48:36 +00:00
#else
/* normal execution */
b reset
#endif
Reference in a new issue Copy permalink