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.toms...@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); } -- 1.9.1 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
