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

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).
[...]