Hi Sjoerd, Em seg, 17 de jun de 2019 às 11:26, Sjoerd Simons <sjoerd.sim...@collabora.co.uk> escreveu: > > On Tue, 2019-06-04 at 18:56 -0300, Fabio Estevam wrote: > > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons > > <sjoerd.sim...@collabora.co.uk> wrote: > > > We have been using imx_usb_loader for a long time. After DM / fit > > comvesion the IVT piece is not added into the final .img. > > > > From the main Makefile: > > > > ifdef CONFIG_SPL_LOAD_FIT > > MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O > > u-boot \ > > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ > > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > > else > > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ > > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > > MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O > > u-boot \ > > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > > u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log > > CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u- > > boot.imx.log > > endif > > > > we can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT > > case. > > > > I tried to change this logic, but so far was not able to make it > > work. > > So when looking through how secure boot can work from the SPL i can > accross e246bfcfe. Which explains the u-boot SPL expect a signed fit > image with roughly the following layout: > > -------------------------------------------------- > | | | | | | | | > | FIT | FIT | FIT | | U-BOOT | ATF | U-BOOT | > | FDT | IVT | CSF | | nodtb.bin | | DTB | > | | | | | | | | > -------------------------------------------------- > > The code aligns the IVT at 0x1000 and the standard CSF size is > 0x2000. So one has to set CONFIG_FIT_EXTERNAL_OFFSET=0x3000 (assuming the FIT > FDT <= 0x1000 bytes) to make CONFIG_SECURE_BOOT work in this setup (even if > HAB is off and the image isn't signed). Otherwise the SPL won't pick up the > correct location for all the external data. > > Seems a bit ugly that the start offset of the external data can't be > introspected from the fdt blob, but oh well. > > The way this seems to work for i.mx8 is that the SECOND_LOADER command > sticks in a IVT header into the fit image. I assume some other tooling > can then stick the CSF data in the appropriate place (anyone have a > pointer?). >
Thanks for looking at this issue. We are using similar structure in NXP U-Boot for i.MX8M devices, you can use dd tool as explained in document below: https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/guides/mx8m_mx8mm_secure_boot.txt?h=imx_v2018.03_4.14.98_2.0.0_ga#n301 > Now i guess the first question becomes whether the i.mx6 should follow > the same layout. And if so how to integrate it properly (teach mkimage > about handling firmware_ivt for fit images?). > IMHO we should follow the same layout as in i.MX8M, as far as I know in NXP BSP this is handled by imx-mkimage tool: https://source.codeaurora.org/external/imx/imx-mkimage/?h=imx_4.14.98_2.0.0_ga Perhaps we can try similar with mkimage tool included in upstream U-Boot? > Relatedly i was looking for a good description of using HAB for loading > the OS in FIT images, but failed to find a good document. pointers > welcome. > For HAB API usage you can take a look in HABv4 RVT Guidelines and Recommendations application note: https://www.nxp.com/docs/en/application-note/AN12263.pdf The U-Boot docs in NXP BSP U-Boot also provides an overview: https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4?h=imx_v2018.03_4.14.98_2.0.0_ga Thanks, Breno Lima _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot