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