v2023.07-rc5 regression: Image overlaps SPL

[Tom Rini]

On Tue, Jul 04, 2023 at 05:23:03PM +0200, Francesco Dolcini wrote:
> On Tue, Jul 04, 2023 at 11:14:57AM -0400, Tom Rini wrote:
> > On Tue, Jul 04, 2023 at 05:12:42PM +0200, Francesco Dolcini wrote:
> > > On Tue, Jul 04, 2023 at 11:39:59AM -0300, Fabio Estevam wrote:
> > > > Then for the next cycle, we should plan on adding this
> > > > fdt_increase_size() into the common fdt_status_disabled().
> > > > 
> > > > Does it work?
> > > 
> > > Now that the situation is pretty much clear I am not overly concerned for
> > > colibri-imx7s.
> > > 
> > > Do we consider this something to be worried about for other boards?
> > 
> > The cases calling fdt_status_disabled itself are small enough that I
> > think a quick audit isn't unreasonable (and PowerPC should probably
> > mirror the kernel and pass -p 0x1000 in DTC_FLAGS so it becomes a
> > non-issue).
> 
> Do we expect this to not affect fdt_setprop() or other fdt_*() APIs?
> fdt_increase_size() seems not to be used most of the time, unless I am
> missing something here.

It depends on the case. For example, fdt_node_set_part_info is
big/complex enough that it does call fdt_increase_size (which is not
cheap) when there's no space.  Other cases already do check for no space
and grow+retry.  And then the general answer is that if you're expecting
needing to make "big" changes to the dtb you should pad it to start with
as that's a free operation at run time.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230704/1027a1ab/attachment.sig>