When I was trying to run mainline U-Boot on my new Rockchip RK3568 board I discovered that one segment of vendor TF-A could not successfully be loaded into SRAM, validation of the image sha256 hash failed.
The issue with loading the data turned out to be because of how SPL load FIT images. It reads data aligned to block length. Aligned image data is read directly to the load address. Unaligned image data is written to an offset of the load address and then memcpy to the load address. The segment of the TF-A that failed to load is a 8KiB segment that should be loaded into the 8KiB PMU SRAM. Because this segment was unaligned to the SD/MMC block length the segment was written to and memcpy from beyond the SRAM boundary, in the end this results in invalid data in SRAM. Vendor u-boot has worked around this issue by using a bounce buffer for any load address that is not in the gd->ram_base - gd->ram_top range. However, by passing -B 200 to mkimage we can work around this issue becuase the FIT and its external data ends up being aligned to SD/MMC block length. This series adds support for a fit,align property in binman and makes use of this new property in rockchip-u-boot.dtsi. It also adds image hash to the FIT images when configured with CONFIG_SPL_FIT_SIGNATURE=y. This series builds on top of Simon Glass "binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script" v9 series at [1]. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=335487 Jonas Karlman (4): binman: Add support for align argument to mkimage tool rockchip: Align FIT image data to SD/MMC block length binman: Add subnodes to the nodes generated by split-elf rockchip: Add sha256 hash to FIT images arch/arm/dts/rockchip-u-boot.dtsi | 21 +++++++++++++++++++++ tools/binman/btool/mkimage.py | 5 ++++- tools/binman/etype/fit.py | 17 +++++++++++++++-- 3 files changed, 40 insertions(+), 3 deletions(-) -- 2.39.0