On Fri, Sep 22, 2023 at 5:04 PM Neha Malcom Francis <n-fran...@ti.com> wrote: > > Hi Masahiro > > On 22/09/23 12:48, Masahiro Yamada wrote: > > On Fri, Sep 22, 2023 at 2:27 PM Neha Malcom Francis <n-fran...@ti.com> > > wrote: > >> > >> Hi Masahiro > >> > >> On 21/09/23 21:06, Masahiro Yamada wrote: > >>> Hi. > >>> > >>> Since the TI platform migrated to binman, > >>> u-boot.img is built twice. > >>> > >>> It is created by "mkimage -E", > >>> then overwritten by binman. > >>> > >>> > >>> So, the data are embedded in the FIT structure > >>> instead of being appended. > >>> > >>> Is this intentional? > >>> > >>> To me, it looks weird. > >>> > >>> > >> > >> I haven't added the fit,external-offset property in the binman.dtsi so it > >> was > >> not appended as external data and I did not find reason to. Is there any > >> benefit > >> in having the data appended than embedded? > > > > > > > > Placing payload data outside the FIT structure is a U-Boot hack. > > > > > > The motivation was explained in the commit log of > > 722ebc8f84d5bccd2e70fad1079a0dd40cceddec > > > > > > Thanks for this! Makes sense, I think we should make it appended again in > binman. Can reduce boot time. > > > > Before TI migrated to binman, > > u-boot.img was the "payload outside" structure > > but it is not any more. > > > > I do not mind the implementation details as long as > > U-Boot is able to boot the Linux kernel. > > > > > > I was just suffering from the AM64-SK boot failure > > (as I asked in another thread) and just noticed > > something odd when I was poking the SPL code. > > > > > > At least, .u-boot.img.cmd is not telling the truth. > > > > Usually, the build command is saved in a *.cmd file > > but this does not reflect the reality, because > > it is binman that created the final u-boot.img > > > > > > $ cat .u-boot.img.cmd > > cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none > > -O u-boot -a 0x80800000 -e 0x80800000 -p 0x0 -n "U-Boot > > 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b > > arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d > > u-boot-nodtb.bin u-boot.img >/dev/null > > > > > > I will not track it down any further, though. > > It is too complicated. > > > > > > > > I am not too sure about the .cmd files but looks like its misleading probably > because the replacing of the binman generated image takes under cmd_binman and > not directly from the Makefile (just a guess).
>From my view as a user, building images without k3-image-gen seems like a benefit, but binman is not mandatory for u-boot.img. With line 255-339 of arch/arm/dts/k3-am64x-binman.dtsi deleted, u-boot.img was still generated in the same structure as before. (payload appended) The confusion came from u-boot.img being first created by line 1439 of the top Makefile (mkimage), then overwritten by line 1113 (binman). If you use binman for u-boot.img, the line 1439 does not need to run, but it runs because u-boot.img is added to INPUTS-y. Perhaps, you may want to hack line 978 because IMX is doing something there. ifeq ($(CONFIG_MX7)$(CONFIG_IMX_HAB), yy) INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img else INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.img endif For the *.cmd files, the mkimage command is saved in .u-boot.img.cmd and the binman command is saved in ..binman_stamp.cmd $ cat .u-boot.img.cmd cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none -O u-boot -a 0x80800000 -e 0x80800000 -p 0x0 -n "U-Boot 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d u-boot-nodtb.bin u-boot.img >/dev/null $ cat ..binman_stamp.cmd cmd_.binman_stamp := ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O . -m --allow-missing -I . -I . -I ./board/ti/am64x -I arch/arm/dts -a of-list="k3-am642-evm k3-am642-sk" -I /home/masahiro/ref/ti-linux-firmware -a atf-bl31-path=/home/masahiro/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin -a tee-os-path=/home/masahiro/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin -a opensbi-path= -a default-dt="k3-am642-evm" -a scp-path= -a rockchip-tpl-path= -a spl-bss-pad= -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb= -a pre-load-key-path= -- Best Regards Masahiro Yamada