| Message ID | 1496179930-41173-4-git-send-email-philipp.tomsich@theobroma-systems.com |
|---|---|
| State | Accepted |
| Commit | a1c29d4b43dc1bdc57878204bf3e4316fdb1b8b0 |
| Delegated to: | Simon Glass |
| Headers | show |
On 30 May 2017 at 15:32, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > 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(-) Reviewed-by: Simon Glass <sjg@chromium.org>
On 30 May 2017 at 15:32, Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > 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(-) Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot-rockchip, thanks!
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); }
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(-)