Whitebox
/
u-boot
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
53086 Commits
3 Branches
0 Tags
148 MiB
Tag: Branch: Tree: b85f4fe70c
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b85f4fe70c'
${ noResults }
u-boot/arch/arm/include/asm/arch-rockchip/boot0.h

60 lines
2.0 KiB
Raw Normal View History Unescape

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>
7 years ago
/* SPDX-License-Identifier: GPL-2.0+ */
rockchip: spl: RK3399: use boot0 hook to create space for SPL magic The SPL binary needs to be prefixed with the boot magic ('RK33' for the RK3399) on the Rockchip platform and starts execution of the instruction word following immediately after this boot magic. This poses a challenge for AArch64 (ARMv8) binaries, as the .text section would need to start on the odd address, violating natural alignment (and potentially triggering a fault for any code that tries to access 64bit values embedded in the .text section). A quick and easy fix is to have the .text section include the 'RK33' magic and pad it with a boot0 hook to insert 4 bytes of padding at the start of the section (with the intention of having mkimage overwrite this padding with the appropriate boot magic). This avoids having to modify the linker scripts or more complex logic in mkimage. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
8 years ago
/*
* Copyright 2017 Theobroma Systems Design und Consulting GmbH
*/
/*
* Execution starts on the instruction following this 4-byte header
rockchip: boot0: align to 0x20 for armv7 '_start' The '_start' is using as vector table base address, and will write to VBAR register, so it needs to be aligned to 0x20 for armv7. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> [Updated to current code base:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
* (containing the magic 'RK30', 'RK31', 'RK32' or 'RK33'). This
* magic constant will be written into the final image by the rkimage
* tool, but we need to reserve space for it here.
rockchip: spl: RK3399: use boot0 hook to create space for SPL magic The SPL binary needs to be prefixed with the boot magic ('RK33' for the RK3399) on the Rockchip platform and starts execution of the instruction word following immediately after this boot magic. This poses a challenge for AArch64 (ARMv8) binaries, as the .text section would need to start on the odd address, violating natural alignment (and potentially triggering a fault for any code that tries to access 64bit values embedded in the .text section). A quick and easy fix is to have the .text section include the 'RK33' magic and pad it with a boot0 hook to insert 4 bytes of padding at the start of the section (with the intention of having mkimage overwrite this padding with the appropriate boot magic). This avoids having to modify the linker scripts or more complex logic in mkimage. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
8 years ago
*
* To make life easier for everyone, we build the SPL binary with
* space for this 4-byte header already included in the binary.
*/
#ifdef CONFIG_SPL_BUILD
rockchip: spl: make boot0 hook TPL safe When building for a TPL/SPL setup (e.g. on the RK3368), we need the TPL stage to have the extra space for for the 'Rockchip SPL name' (i.e. 'RK33' word). Yet, the SPL will start execution at its first word (i.e. the first word in the SPL binary needs to be a valid instruction). To make things a bit more involved, CONFIG_SPL_BUILD is defined both for the SPL and the TPL stage. To avoid having to explicitly test for the first stage (TPL, if and only if TPL and SPL are built, SPL otherwise), this commit modifies the sequence to repeat the 'b reset' (instead of reserving 4 bytes of undefined space) at the start of the boot0 hook: if overwritten (and execution starts at the second word), the first instruction is still a 'b reset'... if not overwritten, we start on a 'b reset' as well. This solution wouldn't even require the check whether we are in the SPL/TPL build (i.e. CONFIG_SPL_BUILD), but we leave this check in for documentation purposes. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
7 years ago
/*
* We need to add 4 bytes of space for the 'RK33' at the
* beginning of the executable. However, as we want to keep
* this generic and make it applicable to builds that are like
* the RK3368 (TPL needs this, SPL doesn't) or the RK3399 (no
rockchip: boot0 hook: support early return for RK3188/RK3066-style BROM Some Rockchip BROM versions (e.g. the RK3188 and RK3066) first read 1KB data from NAND into SRAM and executes it. Then, following a return to bootrom, the BROM loads additional code to SRAM (not overwriting the first block read) and reenters at the same address as the first time. To support booting either a TPL (on the RK3066) or SPL (on the RK3188) using this model of having to count entries, this commit adds code to the boot0 hook to track the number of entries and handle them accordingly. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Tested-by: Andy Yan <andy.yan@rock-chips.com>
7 years ago
* TPL, but extra space needed in the SPL), we simply insert
* a branch-to-next-instruction-word with the expectation that
* the first one may be overwritten, if this is the first stage
* contained in the final image created with mkimage)...
rockchip: spl: make boot0 hook TPL safe When building for a TPL/SPL setup (e.g. on the RK3368), we need the TPL stage to have the extra space for for the 'Rockchip SPL name' (i.e. 'RK33' word). Yet, the SPL will start execution at its first word (i.e. the first word in the SPL binary needs to be a valid instruction). To make things a bit more involved, CONFIG_SPL_BUILD is defined both for the SPL and the TPL stage. To avoid having to explicitly test for the first stage (TPL, if and only if TPL and SPL are built, SPL otherwise), this commit modifies the sequence to repeat the 'b reset' (instead of reserving 4 bytes of undefined space) at the start of the boot0 hook: if overwritten (and execution starts at the second word), the first instruction is still a 'b reset'... if not overwritten, we start on a 'b reset' as well. This solution wouldn't even require the check whether we are in the SPL/TPL build (i.e. CONFIG_SPL_BUILD), but we leave this check in for documentation purposes. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
7 years ago
*/
rockchip: boot0 hook: support early return for RK3188/RK3066-style BROM Some Rockchip BROM versions (e.g. the RK3188 and RK3066) first read 1KB data from NAND into SRAM and executes it. Then, following a return to bootrom, the BROM loads additional code to SRAM (not overwriting the first block read) and reenters at the same address as the first time. To support booting either a TPL (on the RK3066) or SPL (on the RK3188) using this model of having to count entries, this commit adds code to the boot0 hook to track the number of entries and handle them accordingly. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Tested-by: Andy Yan <andy.yan@rock-chips.com>
7 years ago
b 1f /* if overwritten, entry-address is at the next word */
1:
#endif
#if CONFIG_IS_ENABLED(ROCKCHIP_EARLYRETURN_TO_BROM)
adr r3, entry_counter
ldr r0, [r3]
cmp r0, #1 /* check if entry_counter == 1 */
beq reset /* regular bootup */
add r0, #1
str r0, [r3] /* increment the entry_counter in memory */
mov r0, #0 /* return 0 to the BROM to signal 'OK' */
bx lr /* return control to the BROM */
entry_counter:
.word 0
rockchip: spl: RK3399: use boot0 hook to create space for SPL magic The SPL binary needs to be prefixed with the boot magic ('RK33' for the RK3399) on the Rockchip platform and starts execution of the instruction word following immediately after this boot magic. This poses a challenge for AArch64 (ARMv8) binaries, as the .text section would need to start on the odd address, violating natural alignment (and potentially triggering a fault for any code that tries to access 64bit values embedded in the .text section). A quick and easy fix is to have the .text section include the 'RK33' magic and pad it with a boot0 hook to insert 4 bytes of padding at the start of the section (with the intention of having mkimage overwrite this padding with the appropriate boot magic). This avoids having to modify the linker scripts or more complex logic in mkimage. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
8 years ago
#endif
rockchip: update boot0 hook Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not need it. The very beginning of U-Boot proper is different between armv7 and armv8: armv7 start with ARM_VECTORS while armv8 start with 'b reset'. Here is the map of very beginning for all cases: armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS armv7 U-Boot: ARM_VECTORS armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399) armv8 U-Boot: 'b reset' Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
#if (defined(CONFIG_SPL_BUILD) || defined(CONFIG_ARM64))
/* U-Boot proper of armv7 do not need this */
rockchip: spl: RK3399: use boot0 hook to create space for SPL magic The SPL binary needs to be prefixed with the boot magic ('RK33' for the RK3399) on the Rockchip platform and starts execution of the instruction word following immediately after this boot magic. This poses a challenge for AArch64 (ARMv8) binaries, as the .text section would need to start on the odd address, violating natural alignment (and potentially triggering a fault for any code that tries to access 64bit values embedded in the .text section). A quick and easy fix is to have the .text section include the 'RK33' magic and pad it with a boot0 hook to insert 4 bytes of padding at the start of the section (with the intention of having mkimage overwrite this padding with the appropriate boot magic). This avoids having to modify the linker scripts or more complex logic in mkimage. X-AffectedPlatforms: RK3399-Q7 Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
8 years ago
b reset
rockchip: update boot0 hook Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not need it. The very beginning of U-Boot proper is different between armv7 and armv8: armv7 start with ARM_VECTORS while armv8 start with 'b reset'. Here is the map of very beginning for all cases: armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS armv7 U-Boot: ARM_VECTORS armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399) armv8 U-Boot: 'b reset' Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
#endif
rockchip: boot0: align to 0x20 for armv7 '_start' The '_start' is using as vector table base address, and will write to VBAR register, so it needs to be aligned to 0x20 for armv7. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> [Updated to current code base:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
#if !defined(CONFIG_ARM64)
/*
* For armv7, the addr '_start' will used as vector start address
* and write to VBAR register, which needs to aligned to 0x20.
*/
rockchip: boot0 hook: support early return for RK3188/RK3066-style BROM Some Rockchip BROM versions (e.g. the RK3188 and RK3066) first read 1KB data from NAND into SRAM and executes it. Then, following a return to bootrom, the BROM loads additional code to SRAM (not overwriting the first block read) and reenters at the same address as the first time. To support booting either a TPL (on the RK3066) or SPL (on the RK3188) using this model of having to count entries, this commit adds code to the boot0 hook to track the number of entries and handle them accordingly. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Signed-off-by: Paweł Jarosz <paweljarosz3691@gmail.com> Tested-by: Andy Yan <andy.yan@rock-chips.com>
7 years ago
.align(5), 0x0
rockchip: boot0: align to 0x20 for armv7 '_start' The '_start' is using as vector table base address, and will write to VBAR register, so it needs to be aligned to 0x20 for armv7. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> [Updated to current code base:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
_start:
ARM_VECTORS
#endif
rockchip: reserve memory for rk3399 ATF data There are 3 regions used by rk3399 ATF: - bl31 code, located at 0x10000; - cortex-m0 code and data, located at 0xff8c0000; - bl31 data, located at 0xff8c1000 ~ 0xff8c4000; SPL_TEXT_BASE starts from 0xff8c2000, we need to reserve memory for ATF data, or else there will be memory corrupt after SPL loads the ATF image. More detail about cortex-M0 code in ATF: https://github.com/ARM-software/arm-trusted-firmware/commit/ 8382e17c4c6bffd15119dfce1ee4372e3c1a7890 Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
8 years ago
rockchip: update boot0 hook Rockchip SoCs only need boot0 hook at SPL, and the U-Boot proper do not need it. The very beginning of U-Boot proper is different between armv7 and armv8: armv7 start with ARM_VECTORS while armv8 start with 'b reset'. Here is the map of very beginning for all cases: armv7 SPL: TAG(overwrite 'b 1f')+'b reset' + ARM_VECTORS armv7 U-Boot: ARM_VECTORS armv8 SPL: TAG(overwrite 'b 1f')+'b reset' + Reserved_iram(rk3399) armv8 U-Boot: 'b reset' Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
7 years ago
#if defined(CONFIG_SPL_BUILD) && (CONFIG_ROCKCHIP_SPL_RESERVE_IRAM > 0)
rockchip: reserve memory for rk3399 ATF data There are 3 regions used by rk3399 ATF: - bl31 code, located at 0x10000; - cortex-m0 code and data, located at 0xff8c0000; - bl31 data, located at 0xff8c1000 ~ 0xff8c4000; SPL_TEXT_BASE starts from 0xff8c2000, we need to reserve memory for ATF data, or else there will be memory corrupt after SPL loads the ATF image. More detail about cortex-M0 code in ATF: https://github.com/ARM-software/arm-trusted-firmware/commit/ 8382e17c4c6bffd15119dfce1ee4372e3c1a7890 Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
8 years ago
.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM /* space for the ATF data */
#endif