rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM

This change restores the earlier setting of init_boot_size to include
the maximum area covered by the the boot ROM of each chip for resolve
issues with back-to-bootrom functionality reported by Kever and Heiko.

To ensure that we don't run into the same issue again in the future,
I have updated the comments accordingly and added a reference to the
mailing list archive (there's some very helpful info from Andy Yan
that provides background on the BootROM requirements regarding these
fields).

See https://lists.denx.de/pipermail/u-boot/2017-May/293267.html for
some background (by Andy Yan) of how the BootROM processes this field.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 92c2ff48cec096eb21c6cce80c3625869e08a486..42547aa9d18e020fa9605736d5821c62ebacc159 100644 (file)
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -184,11 +184,14 @@ static void rkcommon_set_header0(void *buf, uint file_size,
         */
        hdr->init_size = ROUND(hdr->init_size, 4);
        /*
-        * The images we create do not contain the stage following the SPL as
-        * part of the SPL image, so the init_boot_size (which might have been
-        * read by Rockchip's miniloder) should be the same as the init_size.
+        * init_boot_size needs to be set, as it is read by the BootROM
+        * to determine the size of the next-stage bootloader (e.g. U-Boot
+        * proper), when used with the back-to-bootrom functionality.
+        *
+        * see https://lists.denx.de/pipermail/u-boot/2017-May/293267.html
+        * for a more detailed explanation by Andy Yan
         */
-       hdr->init_boot_size = hdr->init_size;
+       hdr->init_boot_size = hdr->init_size + RK_MAX_BOOT_SIZE / RK_BLK_SIZE;
 
        rc4_encode(buf, RK_BLK_SIZE, rc4_key);
 }