On Fri, Sep 22, 2023 at 5:04 PM Neha Malcom Francis n-francis@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-francis@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