Re: [PATCH] board_f: Call initf_malloc() before fdtdec_setup()

On Sun, Aug 09, 2026 at 10:33:16AM -0600, Simon Glass wrote:
> Hi Marek,
> 
> On Sat, 8 Aug 2026 at 19:14, Marek Vasut <[email protected]> wrote:
> >
> > On 8/8/26 8:17 PM, Simon Glass wrote:
> >
> > Hello Simon,
> >
> > > On Tue, 21 Jul 2026 at 13:48, Marek Vasut
> > > <[email protected]> wrote:
> > >>
> > >> In case MULTI_DTB_FIT_GZIP is enabled, fdtdec_setup() does uncompress
> > >> the compressed DTs in uncompress_blob() using gunzip(), which invokes
> > >> malloc() internally. The early simple malloc is initialized in board_f
> > >> initf_malloc() call, which sets up the early simple malloc limit and
> > >> offset pointer in global data. Currently, the initf_malloc() is called
> > >> after fdtdec_setup(), which leads to malloc failure in fdtdec_setup()
> > >> during the gzip decompression, because the early simple malloc is not
> > >> initialized yet.
> > >>
> > >> Call initf_malloc() before fdtdec_setup() to assure fdtdec_setup() can
> > >> use malloc() during gzip decompression of the DTs.
> > >>
> > >> The impact of this change on boot time is negligible, because the
> > >> initf_malloc() only assigns two fields in global data.
> > >>
> > >> Signed-off-by: Marek Vasut <[email protected]>
> > >> ---
> > >> Cc: Ilias Apalodimas <[email protected]>
> > >> Cc: Simon Glass <[email protected]>
> > >> Cc: Tom Rini <[email protected]>
> > >> Cc: [email protected]
> > >> ---
> > >>   common/board_f.c | 2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > I'm not keen on reordering this list...
> > >
> > > The offending call is inside uncompress_blob(), which already has a
> > > non-malloc path - MULTI_DTB_FIT_USER_DEFINED_AREA with
> > > MULTI_DTB_FIT_USER_DEF_ADDR.
> >
> > It isn't the allocation of the decompress target that is the problem, it
> > is the gunzip() call which internally calls malloc(), cf. commit message
> > and lib/gunzip.c gzalloc() usage.
> >
> > > That is the pattern most boards using
> > > compressed multi-DTB FIT already use, and it avoids early malloc
> > > altogether. Could the BTT config not just switch to that and drop the
> > > board-local initf_malloc() workaround at the same time?
> >
> > This is unrelated to BTT config.
> >
> > > Failing that, the per-board workaround in board/liebherr/btt/btt.c is
> > > ugly but localised. If we really want a generic fix, I would rather
> > > see uncompress_blob() call initf_malloc() itself when it needs the
> > > heap, so the ordering constraint stays local to the code that needs
> > > it. We would need to ensure that malloc() isn't then inited a second
> > > time. We could always add a flag to gd->boardf, I suppose.
> > >
> > > The reordering also means that malloc cannot be traced - the idea with
> > > trace is that it is enabled as early as possible. Finally (that I can
> > > think of), it means that early malloc can never be configured by the
> > > devicetree (although that is not something we have needed yet).
> > [...]
> 
> Ah OK, I see. So in U-Boot proper, before relocation, you have a FIT
> containing multiple gzip-compressed DTBs and you want to select the
> correct one (presumably with a compatible string), then decompress and
> use it.
> 
> Is it possible to do this in SPL instead?
> 
> If not, it looks like there are two allocations in gzip. One is just
> its state (fixed size so we could pass it in or pass a pointer to a
> local var). The other is its context buffer, which might be 64K or
> more. Did you see my suggested workaround above (call initf_malloc()
> itself)?

The work-arounds you're suggesting seem much more cumbersome than
Marek's change, and I don't follow what you mean by malloc not being
traceable? Shouldn't it just be that whatever early calls happen before
trace_early_init is called, wouldn't be traceable, and that in turn
sounds like a reasonable tradeoff (and obvious enough if someone is
using the facility to debug an issue, that early).

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCanitRgAKCRAr4qD1Cr/k
CpeFAQDE4xhtwAcLvXVgeqwngp2NB48r+GH44DH1gmnZPiz0ngEA6u1N5JDz0cUL
ilkmcHeTkG1RTRpVZhCJLb36kggDhAI=
=i4h5
-----END PGP SIGNATURE-----