[PATCH v2 0/7] mkimage: Detect FIT image load address overlaps and fix related test/DTS issues

[Aristo Chen]

Hi Simon

Simon Glass <sjg at chromium.org> 於 2025年9月26日 週五 下午10:49寫道：
>
> Hi Aristo,
>
> On Thu, 25 Sept 2025 at 07:50, Aristo Chen <jj251510319013 at gmail.com> wrote:
> >
> > Aristo Chen <jj251510319013 at gmail.com> 於 2025年9月24日 週三 下午10:33寫道：
> > >
> > > Nishanth Menon <nm at ti.com> 於 2025年9月24日 週三 下午10:05寫道：
> > > >
> > > > On 07:51-20250924, Tom Rini wrote:
> > > > > On Wed, Sep 24, 2025 at 06:31:23AM -0700, E Shattow wrote:
> > > > > > Hi Aristo,
> > > > > >
> > > > > > On 9/24/25 04:43, Nishanth Menon wrote:
> > > > > > > On 06:37-20250924, Nishanth Menon wrote:
> > > > > > >> On 10:59-20250914, Aristo Chen wrote:
> > > > > > >>> This patch series enhances FIT image robustness by adding **memory
> > > > > > >>> region overlap detection** to `mkimage` and fixing existing overlaps
> > > > > > >>> in DTS files and `binman` tests.
> > > > > > >
> > > > > > > [...]
> > > > > > >>>
> > > > > > >>
> > > > > > >> Looks like i see a build regression in linux-next after this series.
> > > > > > >
> > > > > > > I fat fingered that one.. sorry, I meant u-boot next.
> > > > > > >
> > > > > > >
> > > > > > > Fails at commit 4d84fa1261eb, last pass was on commit d81c1118580f
> > > > > > >
> > > > > > >>
> > > > > > >> https://gist.github.com/nmenon/b2fc9e7680cc296062c7dced94105f76
> > > > > > >
> > > > > > > I  believe there are outstanding comments on V1 that have'nt been
> > > > > > > addressed either. Can we revert/drop this series for now while the
> > > > > > > comments are addressed?
> > > > > > >
> > > > > >
> > > > > > Similar to Nishanth, I am seeing a build regression, itb.map:
> > > > >
> > > > > Sorry for the noise all, I've reverted this in next now.
> > > > >
> > > >
> > > > Thanks Tom.
> > > > --
> > > > Regards,
> > > > Nishanth Menon
> > > > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
> > > > https://ti.com/opensource
> > >
> > > Apology for introducing the regression, I will find time to fix them,
> > > and thanks Tom for reverting my patch set to unblock others
> > >
> > > For TIFS stub entries on AM6x platforms and the starfive visionfive2,
> > > sounds like the image in the FIT will be selected during the runtime,
> > > so they are not really overlapping each other. I will need to figure
> > > out other way instead
> >
> >
> > Thank you all for the feedback on my FIT image overlap detection patch
> > series, and apology again for the issues that I introduced
> >
> > Currently what I have in my mind is to have the following 2 changes in
> > my patch set
> > ### 1. Add support for mutually exclusive image groups
> > Some platforms load only one image from a group at runtime. In the
> > device tree, we may have something like this
> > ```
> > tifsstub-hs {
> >     // ... existing properties ...
> >     mutually-exclusive-group = "tifsstub";
> > };
> > tifsstub-fs {
> >     // ... existing properties ...
> >     mutually-exclusive-group = "tifsstub";
> > };
> > ```
> > The overlap checker would then skip validation between images in the
> > same mutually-exclusive-group, while still catching genuine
> > overlaps
> >
> > ### 2.  Change from build error to warning
> > Given that there may be edge cases(such as
> > starfive_visionfive2_defconfig) not covered by current CI pipelines,
> > changing overlap
> > detection from a build-stopping error to a warning initially. This would:
> > - Alert developers to potential memory layout issues
> > - Avoid breaking existing working configurations
> > - Allow time to refine the detection logic based on community feedback
> > - Enable a gradual transition to stricter validation once the approach is proven
> > The warning could later become an error once we have confidence in the
> > detection accuracy across all supported platforms.
> >
> > Feel free to let me know if you have any concerns or suggestions
>
> We should try to have discussions on FIT on the spec github as well,
> e.g. filing an issue at [1] and referring to it here. I'm not sure how
> to link github discussions to a mailing list, so that perhaps just
> create an issue?. FIT is used by most firmware projects at this point,
> many of which don't follow this mailing list.
>
> Regards,
> Simon

I just opend an issue[1] in the github repo, I don't know if we should
continue the discussion there or should
we continue the discussion here in parallel?

Best Regards,
Aristo

[1] https://github.com/open-source-firmware/flat-image-tree/issues/32

>
> >
> > Thanks for your time and guidance!
> > Aristo
>
> [1] https://github.com/open-source-firmware/flat-image-tree/issues