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
---
Changes in v3: - added in v3
Changes in v2: None
tools/rkcommon.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/rkcommon.c b/tools/rkcommon.c index f9d9421..014cceb 100644 --- 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); }