[U-Boot] [PATCH v1 0/8] rockchip: mkimage: refactor rksd/rkspi padding calculation and add dumpimage support

[Dr. Philipp Tomsich]

Heiko,

thanks for the insight into the BROM.
I’ll respin this with part of the change reverted and have Kever test.

Regards,
Philipp.

> On 19 May 2017, at 20:39, Heiko Stuebner <heiko at sntech.de> wrote:
> 
> Hi Philipp,
> 
> Am Mittwoch, 17. Mai 2017, 12:12:51 CEST schrieb Dr. Philipp Tomsich:
>> What are the requirements for BACK_TO_BROM?
>> All I can see about how BACK_TO_BROM works is that it needs to save the register
>> context on the stack for returning to the ROM, but that seems to be only half the story.
>> 
>> Assuming that the header0 structure plays into this, the only significant change there
>> is that I don’t set the 'hdr->init_boot_size’ to the maximum SPL size any longer...
> 
> Which is most likely the problem. back_to_bootrom-images are concatenated
> with the spl in front (init_size) and when returned to the bootrom it
> reads the rest up to init_boot_size into the sdram.
> 
> So ideally we would return that line back to RK_MAX_BOOT_SIZE (512KB).
> Somewhat safe value and boards not using back_to_bootrom, as this value
> really only affects that second stage and not the actual spl loading.
> 
> I'm sadly away from my boardfarm this and next week, so testing bootloader
> on my rk3188 board can only happend after that, but I'm somewhat
> confident that this would solve the problem. Maybe Kever can test that
> meanwhile.
> 
> 
> Heiko
> 
> 
>> 
>> Regards,
>> Philipp.
>> 
>>> On 17 May 2017, at 11:50, Kever Yang <kever.yang at rock-chips.com> wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> This patch makes all the Rockchip SoCs with BACK_TO_BROM enabled can not work,
>>> 
>>> does the size correct for the SPL correct?
>>> 
>>> Thanks,
>>> - Kever
>>> On 04/17/2017 11:47 PM, Philipp Tomsich wrote:
>>>> We support booting both from SD/MMC images and SPI images on the
>>>> RK3399-Q7 for different use-cases (e.g. external boot in development
>>>> from the SD card, internal boot from MMC or SPI depending on whether
>>>> the SPI flash is populated on any given configuration option).
>>>> 
>>>> In getting the SPI image support ready for production, we found a
>>>> few areas that warranted improvements:
>>>> - we had broken SPI bootstrap earlier in the changes introducting
>>>>  boot0-style images for the RK3399 (this needed fixing)
>>>> - in fixing the broken SPI padding calculation, it became apparent
>>>>  that it's best to refactor and document things before we make
>>>>  the same mistake again in the future
>>>> - with both SD/MMC and SPI images being used for various purposes
>>>>  by various people, the wrong image style was inadvertendly used
>>>>  in some tests... so we support for 'dumpimage' (i.e. verify_header
>>>>  and print_header) had to be added to quickly check the image
>>>>  type being handled
>>>> 
>>>> Note that with the refactored calculation of the image-size, we
>>>> don't pad the image to the maximum SPL size any longer, but pad
>>>> SD/MMC to the next 512 byte block (RK_BLK_SIZE) and SPI to the
>>>> next 2K boundary.
>>>> 
>>>> 
>>>> Philipp Tomsich (8):
>>>>  rockchip: mkimage: rkspi: include the header sector in the SPI size
>>>>    calculation
>>>>  rockchip: mkimage: rewrite padding calculation for SD/MMC and SPI
>>>>    images
>>>>  rockchip: mkimage: Update comments for header size
>>>>  rockchip: mkimage: rksd: pad SD/MMC images to a full blocksize
>>>>  rockchip: mkimage: clarify header0 initialisation
>>>>  rockchip: mkimage: play nice with dumpimage
>>>>  rockchip: mkimage: remove placeholder functions from rkimage
>>>>  rockchip: mkimage: add support for verify_header/print_header
>>>> 
>>>> tools/rkcommon.c | 195 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>>> tools/rkcommon.h |  29 ++++++++-
>>>> tools/rkimage.c  |  21 +-----
>>>> tools/rksd.c     |  47 +++++---------
>>>> tools/rkspi.c    |  62 +++++++++---------
>>>> 5 files changed, 255 insertions(+), 99 deletions(-)
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>