[Question] TI's u-boot.img is built twice

[Masahiro Yamada]

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