Skip to content

rockchip: mkimage: refactor rksd/rkspi padding calculation and add dumpimage support

Heiko Stuebner u-boot 1 version New

Get series with b4
b4 am 1828214.9pp2RnOGsf@phil

Versions newest first

  1. v1 Latest0 of 8 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 8 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

Hi Philipp,

Am Mittwoch, 17. Mai 2017, 12:12:51 CEST schrieb Dr. Philipp Tomsich:

Quoted 6 lines

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

Quoted 63 lines

Regards,
Philipp.

Quoted 56 lines · Kever Yang

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

Quoted 43 lines · Philipp Tomsich

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(-)

Read the cover letter in its thread