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)? Regards, Simon
