Hi Simon, On Mon Jul 13, 2026 at 7:43 PM IST, Simon Glass wrote: > On Mon, 13 Jul 2026 at 05:34, Anshul Dalal <[email protected]> wrote: >> >> On Fri Jul 10, 2026 at 12:44 AM IST, Simon Glass wrote: >> > Hi Anshul, >> > >> > On 2026-07-07T10:44:09, Anshul Dalal <[email protected]> wrote: >> >> tools: binman: fix changes not being written to source.dtb >> >> >> >> In the current setup the changes done to the dtb by binman such as >> >> bootph propagation are only made to the intermediary *.dtb.out but not >> >> the final dtb. >> >> >> >> This means the final dtb that's in *-binman.dtsi never gets the required >> >> changes applied. Therefore this patch fixes the behaviour by writing to >> >> the supplied dtb before exiting with a modified test to catch any future >> >> regressions. >> >> >> >> Signed-off-by: Anshul Dalal <[email protected]> >> >> >> >> tools/binman/control.py | 3 +++ >> >> tools/binman/ftest.py | 41 ++++++++++++++++++++++------------------- >> >> 2 files changed, 25 insertions(+), 19 deletions(-) >> > >> > Please can you spell out the concrete symptom? What breaks in a real >> > build when u-boot.dtb doesn't carry the bootph propagation - which >> > stage reads it, what does it expect to find, and what goes wrong when >> > it isn't there? The *-binman.dtsi reference is confusing since a .dtsi >> > is a source file, not something written to. >> >> The actual issue was observed while we were adding support for our a new >> platform 'AM62l EVM' to U-Boot where the missing bootph properties meant >> that the parent drivers were not being probed leading to boot failure. >> >> > >> > Also please rewrite in imperative present tense: 'Write the modified >> > dtb back to dtb_fname so that ...' rather than 'this patch fixes the >> > behaviour by ...' >> >> Yeah, the former is more clear. Will fix in the next revision. >> >> > >> >> diff --git a/tools/binman/control.py b/tools/binman/control.py >> >> @@ -677,6 +677,9 @@ def PrepareImagesAndDtbs(dtb_fname, select_images, >> >> update_fdt, use_expanded, ind >> >> dtb_item.Sync(auto_resize=True) >> >> dtb_item.Pack() >> >> dtb_item.Flush() >> >> + >> >> + # Copy the intermediary dtb ('u-boot.dtb.out') to the dtb supplied >> >> to binman >> >> + tools.write_file(dtb_fname, dtb.GetContents()) >> > >> > This is updating an input file...really not keen on that! The updated >> > dtb should already be written into the final image created by Binman. >> >> Perhaps it's an issue with how we're using 'u-boot.dtb'. As I see now, a >> lot of platforms (including TI's) are using 'u-boot.dtb' as the fdt for >> U-Boot FIT. Do we not expect the final U-Boot FIT produced in those >> builds to have this propagation logic applied? >> >> To test things out, I built the am62x_evm_a53 platform and the fdt >> extracted out of the built u-boot.img lacks proper bootph propagation >> without this patch applied: >> >> fdtget -t r build/u-boot.img_unsigned /images/fdt-0/ data > >> extracted.dtb >> >> It makes sense to not modify the input files so then should we change >> the DTB we use in the u-boot's FIT to 'u-boot.dtb.out' instead of >> 'u-boot.dtb'? > > Possibly, but are you using Binman to create the FIT? If so it should > use the updated FDT. This might be a hole in how Binman works? >
Yes, we are using binman for FIT creation here. I'm not sure what's the correct behaviour here either, in our binman DTSI for the platform (k3-am625-sk-binman.dtsi) we explicitly set the fdt-0 for the u-boot node as a blob-ext with "u-boot.dtb" as the filename. Since the same file is given as an input to binman and we don't want to modify the input files we have two options here: 1. If 'u-boot.dtb.out' is known to be the fdt outputted by binman with all the fixes applied, we could just use that instead as the external blob in fdt-0. 2. We could have binman detect a node as 'fdt' and apply the required fixes in-place before spitting out the final 'u-boot.img' FIT. Regards, Anshul
