rockchip: back-to-bootrom: replace assembly-implementation with C-code

The boot0 hook on ARM does not insert its payload before the vector table. This is both a mismatch with thec comment above it and contradict usage of the boot0 hook on ARM64.

To fix this (and unify the semantics for ARM and ARM64), we change the boot0-hook semantics on ARM to match those on ARM64:
(1) if a boot0-hook is present it is inserted at the start of the image
(2) if a boot0-hook is present, emitting the ARM vector table (and the _start) symbol are suppressed in vectors.S and the boot0-hook has full control over where and when it wants to emit these

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-rockchip/boot0.h |  1 -
 arch/arm/lib/vectors.S                     | 54 +++++++++++++++++++-----------
 2 files changed, 35 insertions(+), 20 deletions(-)

From: Kever Yang <[email protected]>

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 <[email protected]>

[Updated to current code base:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-rockchip/boot0.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

From: Kever Yang <[email protected]>

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 <[email protected]>

[Updated to current code base:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/include/asm/arch-rockchip/boot0.h | 14 ++++++++++++--
  1 file changed, 12 insertions(+), 2 deletions(-)

arch/arm/include/asm/arch-rockchip/boot0.h +3 -2

index 455d842..f7c6146 100644
@@ -6,12 +6,13 @@
 
  /*
   * Execution starts on the instruction following this 4-byte header
- * (containing the magic 'RK33').
+ * (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.
   *
   * 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
  	/*
  	 * We need to add 4 bytes of space for the 'RK33' at the

arch/arm/include/asm/arch-rockchip/boot0.h +9 -0

+#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.
+	 */
+	.align(5)
+_start:
+	ARM_VECTORS
+#endif
 
  #if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
  	.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM	/* space for the ATF data */

Hi Phipipp, Kever:

Quoted 37 lines · Philipp Tomsich

From: Kever Yang <[email protected]>

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 <[email protected]>

[Updated to current code base:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-rockchip/boot0.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

arch/arm/include/asm/arch-rockchip/boot0.h +3 -2

index 455d842..f7c6146 100644
@@ -6,12 +6,13 @@
   /*
  * Execution starts on the instruction following this 4-byte header
- * (containing the magic 'RK33').
+ * (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.
  *
  * 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
 	/*

arch/arm/include/asm/arch-rockchip/boot0.h line 29

Quoted 5 lines

arch/arm/include/asm/arch-rockchip/boot0.h +0 -0

 	 * We need to add 4 bytes of space for the 'RK33' at the

@@ -26,6 +27,15 @@
 	b reset	 /* may be overwritten --- should be 'nop' or a 'b reset' */
 #endif
 	b reset

Do we really need the "b reset" here? the macro ARM_VECTORS already has a b reset.
Besides Joseph found that the irq function will not work with this "b reset”

Quoted 11 lines

arch/arm/include/asm/arch-rockchip/boot0.h +9 -0

+#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.
+	 */
+	.align(5)
+_start:
+	ARM_VECTORS
+#endif
   #if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
 	.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM	/* space for the ATF data */

Andy,

Quoted 40 lines · Andy Yan

Hi Phipipp, Kever:

Quoted 36 lines · Philipp Tomsich

From: Kever Yang <[email protected]>

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 <[email protected]>

[Updated to current code base:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

  arch/arm/include/asm/arch-rockchip/boot0.h | 14 ++++++++++++--
  1 file changed, 12 insertions(+), 2 deletions(-)

arch/arm/include/asm/arch-rockchip/boot0.h +3 -2

index 455d842..f7c6146 100644
@@ -6,12 +6,13 @@
    /*
   * Execution starts on the instruction following this 4-byte header
- * (containing the magic 'RK33').
+ * (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.
   *
   * 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

Quoted 8 lines

arch/arm/include/asm/arch-rockchip/boot0.h line 29

Quoted 6 lines

arch/arm/include/asm/arch-rockchip/boot0.h +0 -0

  	/*
  	 * We need to add 4 bytes of space for the 'RK33' at the

@@ -26,6 +27,15 @@
  	b reset	 /* may be overwritten --- should be 'nop' or a 'b reset' */
  #endif
  	b reset

Do we really need the "b reset" here? the macro ARM_VECTORS already has a b reset.
Besides Joseph found that the irq function will not work with this "b reset”

The quoted code was from an older version of the series, but the ‘b reset’ is still there in the newer version.

What IRQ function does not work?
Shouldn't the IRQ be jumping into the ARM_VECTORS and never see the ‘b reset’?

Quoted 13 lines

Quoted 12 lines

arch/arm/include/asm/arch-rockchip/boot0.h +9 -0

+#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.
+	 */
+	.align(5)
+_start:
+	ARM_VECTORS
+#endif
    #if defined(CONFIG_ROCKCHIP_RK3399) && defined(CONFIG_SPL_BUILD)
  	.space CONFIG_ROCKCHIP_SPL_RESERVE_IRAM	/* space for the ATF data */

Rockchip SoCs bootrom design is like this:
- First 2KB or 4KB internal memory is for bootrom stack and heap;
- Then the first 4-byte suppose to be a TAG like 'RK33';
- The the following memory address end with '0004' is the first instruction load and running by bootrom;

Let's use the boot0 hook to reserve the first 4-byte tag for all the Rockchip SoCs.

Signed-off-by Philipp Tomsich <philipp.tomsich@theobroma-systems>

[Commit message:]

Signed-off-by Kever Yang <[email protected]>

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/Kconfig               | 1 +
 arch/arm/mach-rockchip/Kconfig | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

From: Kever Yang <[email protected]>

Enable the spl_boot0 in SPL and use the pre-padding TAG memory, the mkimage do not need to pad it but only need to replace the value with correct TAG value.

Signed-off-by Kever Yang <[email protected]>

[Updated:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 tools/rkcommon.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

From: Kever Yang <[email protected]>

After we use boot0 hook, we can use offset '000' instead of '004' as SPL_TEXT_BASE.

Signed-off-by Kever Yang <[email protected]>

[Updated tag in commit summary:]

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/configs/rk3288_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

With the boot0-hook inserting the additional padding to receive our SPL magic, the SPL_TEXT_BASE can be aligned again.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/configs/rk3036_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

With the updated boot0 semantics (i.e. giving the boot0-hook control over when and where the vector table is emitted), the boot0-hook for the socfpga needs to be adjusted.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

arch/arm/mach-socfpga/include/mach/boot0.h | 3 +++

1 file changed, 3 insertions(+)

arch/arm/mach-socfpga/include/mach/boot0.h +3 -0

index 22d9e7f..d6b9435 100644
@@ -7,6 +7,9 @@
 #ifndef __BOOT0_H
 #define __BOOT0_H
 
+_start:
+	ARM_VECTORS
+
 #ifdef CONFIG_SPL_BUILD
 	.balignl 64,0xf33db33f;
 

Signature · 1 line

2.1.4

Marek & Tien Fong,

could either of you have a look at the below change (in the context of
https://patchwork.ozlabs.org/patch/823872/, which is also contained in the same series) and give me an ok on this, so I can merge this series early in the upcoming merge window?

Thanks,
Philipp.

Quoted 34 lines · Philipp Tomsich

With the updated boot0 semantics (i.e. giving the boot0-hook control over when and where the vector table is emitted), the boot0-hook for the socfpga needs to be adjusted.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

arch/arm/mach-socfpga/include/mach/boot0.h | 3 +++

1 file changed, 3 insertions(+)

arch/arm/mach-socfpga/include/mach/boot0.h +3 -0

index 22d9e7f..d6b9435 100644
@@ -7,6 +7,9 @@
 #ifndef __BOOT0_H
 #define __BOOT0_H
 
+_start:
+	ARM_VECTORS
+
 #ifdef CONFIG_SPL_BUILD
 	.balignl 64,0xf33db33f;
 

Signature · 1 line

2.1.4

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 6 lines · Dr. Philipp Tomsich

Marek & Tien Fong,

could either of you have a look at the below change (in the context of
https://patchwork.ozlabs.org/patch/823872/, which is also contained in the same series) and give me an ok on this, so I can merge this series early in the upcoming merge window?

Please stop top-posting.

Does it still generate that structure at offset 0x40 in u-boot*sfp on SoCFPGA ? If so, fine by me.

Quoted 43 lines

Thanks,
Philipp.

Quoted 34 lines · Philipp Tomsich

With the updated boot0 semantics (i.e. giving the boot0-hook control over when and where the vector table is emitted), the boot0-hook for the socfpga needs to be adjusted.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

arch/arm/mach-socfpga/include/mach/boot0.h | 3 +++

1 file changed, 3 insertions(+)

arch/arm/mach-socfpga/include/mach/boot0.h +3 -0

index 22d9e7f..d6b9435 100644
@@ -7,6 +7,9 @@
 #ifndef __BOOT0_H
 #define __BOOT0_H
 
+_start:
+	ARM_VECTORS
+
 #ifdef CONFIG_SPL_BUILD
 	.balignl 64,0xf33db33f;
 

Signature · 1 line

2.1.4

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Signature · 2 lines

Best regards,
Marek Vasut

Quoted 11 lines · Marek Vasut

Quoted 6 lines · Dr. Philipp Tomsich

Marek & Tien Fong,

could either of you have a look at the below change (in the context of
https://patchwork.ozlabs.org/patch/823872/, which is also contained in the same series) and give me an ok on this, so I can merge this series early in the upcoming merge window?

Quoted 4 lines

Please stop top-posting.

Does it still generate that structure at offset 0x40 in u-boot*sfp on SoCFPGA ? If so, fine by me.

Yes it does.
And the binary still looks the same around the magic offset.

Quoted 17 lines · Dr. Philipp Tomsich

Quoted 17 lines

On 6 Nov 2017, at 18:54, Marek Vasut <[email protected]> wrote:

Quoted 10 lines · Dr. Philipp Tomsich

Marek & Tien Fong,

could either of you have a look at the below change (in the context of
https://patchwork.ozlabs.org/patch/823872/, which is also contained inÂ
the same series) and give me an ok on this, so I can merge this series
early in the upcoming merge window?

Quoted 7 lines

Quoted 5 lines

Please stop top-posting.

Does it still generate that structure at offset 0x40 in u- boot*sfp on
SoCFPGA ? If so, fine by me.

Yes it does.
And the binary still looks the same around the magic offset.

OK, fine by me then.

With the updated boot0 semantics (i.e. giving the boot0-hook control over when and where the vector table is emitted), the boot0-hook for the socfpga needs to be adjusted.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-socfpga/include/mach/boot0.h | 3 +++
 1 file changed, 3 insertions(+)

This updates the BCM235xx boot0-hook to the updated boot0 semantics by emitting _start and the vector table before the boot0 hook (as was the case before).

Signed-off-by Philipp Tomsich <[email protected]>

Version-changes: 5
- ran 'whitespace-cleanup'
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-bcm235xx/boot0.h | 2 ++
 1 file changed, 2 insertions(+)

This updates the BCM281xx boot0-hook to the updated boot0 semantics by emitting _start and the vector table before the boot0 hook (as was the case before).

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-bcm281xx/boot0.h | 2 ++
 1 file changed, 2 insertions(+)

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 <[email protected]>

Signed-off-by PaweÅ‚ Jarosz <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5:
- set return value to 0 before returning to the BROM

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-rockchip/boot0.h | 25 +++++++++++++++++++------
 arch/arm/mach-rockchip/Kconfig             | 28 ++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 6 deletions(-)

The save_boot_params_ret() prototype (for those of us, that have a valid SP on entry and can implement save_boot_params() in C), was previously only defined for !defined(CONFIG_ARM64).

This moves the declaration to a common block to ensure the prototype is available to everyone that might need it.

Signed-off-by Philipp Tomsich <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/system.h | 62 +++++++++++++++++++++----------------------
 1 file changed, 31 insertions(+), 31 deletions(-)

As no '.type' was set for save_boot_params_ret in start.S, binutils did not track whether it was emitted as A32 or T32. By properly marking save_boot_params_ret as a potential function entry, we can make sure that the compiler will insert the appropriate instructions for branching to save_boot_params_ret both for call-sites emitted as A32 and T32.

Reported-by Andy Yan <[email protected]>

Signed-off-by Philipp Tomsich <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3:
- tracked the root-cause why no interwork branch was emitted and fixed it using a '.type'-directive in start.S to mark save_boot_params_ret as a (possible) function-entry.

Changes in v2: None

 arch/arm/cpu/armv7/start.S | 1 +
 1 file changed, 1 insertion(+)

The previous setjmp-implementation (as a static inline function that contained an 'asm volatile' sequence) was extremely fragile: (some versions of) GCC optimised the set of registers. One critical example was the removal of 'r9' from the clobber list, if -ffixed-reg9 was supplied.

To increase robustness and ensure PCS-compliant behaviour, the setjmp and longjmp implementation are now in assembly and closely match what one would expect to find in a libc implementation.

Signed-off-by Philipp Tomsich <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3:
- converted setjmp/longjmp from inline-assembly to separate .S files to improve predicatability if emitted code

Changes in v2: None

 arch/arm/include/asm/setjmp.h | 94 ++++++-------------------------------------
 arch/arm/lib/Makefile         |  6 +++
 arch/arm/lib/setjmp.S         | 37 +++++++++++++++++
 arch/arm/lib/setjmp_aarch64.S | 42 +++++++++++++++++++
 4 files changed, 98 insertions(+), 81 deletions(-)
 create mode 100644 arch/arm/lib/setjmp.S
 create mode 100644 arch/arm/lib/setjmp_aarch64.S

The back-to-bootrom implementation for Rockchip has always relied on the stack-pointer being valid on entry, so there was little reason to have this as an assembly implementation.

This provides a new C-only implementation of save_boot_params and back_to_bootrom (relying on setjmp/longjmp) and removes the older assembly-only implementation.

Signed-off-by Philipp Tomsich <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/arch-rockchip/bootrom.h | 27 ++++++++---
 arch/arm/mach-rockchip/Makefile              |  4 +-
 arch/arm/mach-rockchip/bootrom.c             | 52 ++++++++++++++++++++-
 arch/arm/mach-rockchip/save_boot_param.S     | 69 ----------------------------
 4 files changed, 73 insertions(+), 79 deletions(-)
 delete mode 100644 arch/arm/mach-rockchip/save_boot_param.S

For the RK3188, the BROM will attempt to load up the first stage image (SPL for the RK3188) in two steps: first 1KB to offset 0x800 in the SRAM and then the remainder to offset 0xc00 in the SRAM. It always enters at 0x804, though.

With this changeset, the RK3188 boot removes the TPL (stub) stage and builds a single SPL binary that utilizes the early back-to-bootrom via the boot0-hook.

Consequently, the passing of the saved boot params via pmu->os_reg[2] is also removed.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4:
- after merging the 'back-to-bootrom' series with the 'boot0-hook' series, this drops the TPL stub and builds only a single SPL image that uses the 'early back-to-bootrom' logic originally implemented by Pawel for the RK3066.
- changes the SPL_STACK_BASE to +0x800 (from +0x804), as the boot0 hook already reserves the space for the SPL magic (previously inserted by mkimage)

Changes in v3: None
Changes in v2:
- [added in v2] chain back_to_bootrom calls for SPL, first returning to the TPL (using the same mechanism) and the to the BROM from the TPL

 arch/arm/mach-rockchip/Kconfig            |  2 +-
 arch/arm/mach-rockchip/Makefile           |  1 -
 arch/arm/mach-rockchip/rk3188-board-spl.c | 10 ----
 arch/arm/mach-rockchip/rk3188-board-tpl.c | 86 -------------------------------
 doc/README.rockchip                       | 10 ++--
 include/configs/rk3188_common.h           | 12 ++---
 6 files changed, 9 insertions(+), 112 deletions(-)
 delete mode 100644 arch/arm/mach-rockchip/rk3188-board-tpl.c

The BROM supports forcing it to enter download-mode, if an appropriate result/cmd-word is returned to it. There already is a series to support this in review, so this prepares the (newly C-version) of the back-to-bootrom code to accept a cmd to passed on to the BROM.

All the existing call-sites are adjusted to match the changed function signature.

Signed-off-by Philipp Tomsich <[email protected]>

Tested-by Andy Yan <[email protected]>

---

Changes in v5: None
Changes in v4:
- no longer updates rk3188-board-tpl.c (as we have just removed it in an earlier commit)

Changes in v3: None
Changes in v2:
- also covers the RK3188 (which I had originally missed)

 arch/arm/include/asm/arch-rockchip/bootrom.h | 5 ++++-
 arch/arm/mach-rockchip/bootrom.c             | 4 ++--
 arch/arm/mach-rockchip/rk3036-board-spl.c    | 2 +-
 arch/arm/mach-rockchip/rk3188-board-spl.c    | 4 ++--
 arch/arm/mach-rockchip/rk322x-board-spl.c    | 2 +-
 arch/arm/mach-rockchip/rk3288-board-spl.c    | 4 ++--
 arch/arm/mach-rockchip/rk3288-board-tpl.c    | 2 +-
 arch/arm/mach-rockchip/rk3368-board-tpl.c    | 2 +-
 arch/arm/mach-rockchip/rk3399-board-spl.c    | 2 +-
 9 files changed, 15 insertions(+), 12 deletions(-)

There still are a few CONFIG_SPL_* options selected using defines from rk3188_common.h instead of via Kconfig. This migrates those over to Kconfig.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-rockchip/Kconfig  | 7 ++++++-
 include/configs/rk3188_common.h | 6 ------
 2 files changed, 6 insertions(+), 7 deletions(-)

With all targets converted to generate prepadded images, this removes the spl_boot0 field from our config structure and removes the unused code-path (for images that are not prepadded): i.e. spl_boot0 is now implied as 'true' and the code is specialised by removing the other case.

Signed-off-by Philipp Tomsich <[email protected]>

---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 tools/rkcommon.c | 45 ++++++++++++++-------------------------------
 1 file changed, 14 insertions(+), 31 deletions(-)

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

For v4+: To fix issues with the RK3188 support, this also updates the boot0 hook changes (i.e. allowing the boot0-hook to insert code/data before the ARM vector table) that Kever had submitted this spring and implements a similar "early back-to-bootrom" as suggested by Pawel (for the RK3066) as a generic mechanism.