Hi, On Mon, 13 Jul 2026, 23:24 Anshul Dalal, <[email protected]> wrote: > > 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.
You should really be using the built-in u-boot-fdt entry type. External blobs are just for blobs built by other projects. > > 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. If you use u-boot-fdt then you should not need to do this. Regards, Simon
