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

[Neha Malcom Francis]

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).
> 
> 
>>>
>>>
>>> To confirm it, apply the following hack.
>>>
>>> Since u-boot.img is overwritten by binman,
>>> copy it to u-boot.img.backup.
>>>
>>>
>>>
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 87f9fc786e..4cffa8a061 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1112,6 +1112,7 @@ endef
>>>    # Timestamp file to make sure that binman always runs
>>>    .binman_stamp: $(INPUTS-y) FORCE
>>>    ifeq ($(CONFIG_BINMAN),y)
>>> +       cp u-boot.img u-boot.img.backup
>>>           $(call if_changed,binman)
>>>    endif
>>>           @touch $@
>>>
>>>
>>>
>>> Then, build it for the main core.
>>>
>>>
>>> make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu-
>>>      am64x_evm_a53_defconfig all
>>>      TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin
>>>      BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin
>>>      BINMAN_INDIRS=~/ref/ti-linux-firmware
>>>
>>>
>>>
>>>
>>> Compare the two files.
>>> Run fdtdump to see what happened to them.
>>>
>>>
>>> $ diff -u u-boot.img  u-boot.img.backup
>>> Binary files u-boot.img and u-boot.img.backup differ
>>>
>>>
>>> $ fdtdump u-boot.img
>>>       => u-boot and dt are embedded.
>>>
>>> $ fdtdump u-boot.img.backup
>>>       => u-boot and dt are appended after the
>>>          FIT structure
>>>
>>>
>>>
>>
>> --
>> Thanking You
>> Neha Malcom Francis
> 
> 
> 

-- 
Thanking You
Neha Malcom Francis