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>
This commit is contained in:
Philipp Tomsich 2017-05-30 23:32:10 +02:00 committed by Simon Glass
parent ad972ac3d9
commit a1c29d4b43

View file

@ -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);
}