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 <he...@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.y...@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(-) >>>> >>> >>> >> >> >> > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot