[U-Boot] [PATCH 1/2] bouncebuf: Add static buffer allocation method for SPL.

[Christoph Müllner]

On 07.05.19 15:55, Marek Vasut wrote:
> On 5/7/19 3:55 PM, Christoph Müllner wrote:
>>
>>
>> On 07.05.19 15:52, Marek Vasut wrote:
>>> On 5/7/19 3:45 PM, Christoph Müllner wrote:
>>>>
>>>>
>>>> On 07.05.19 15:06, Marek Vasut wrote:
>>>>> On 5/7/19 11:09 AM, Christoph Muellner wrote:
>>>>>> If we are using malloc-simple, we get into the problem, that
>>>>>> calls to free() won't free any memory. When using bouncebuf
>>>>>> in SPL with malloc-simple this means, that every allocated buffer
>>>>>> is lost. This can quickly consume the whole heap.
>>>>>
>>>>> When does such a scenario happen ?
>>>>
>>>> RK3399 with mainline U-Boot and mainline ATF.
>>>> We have 0x4000 bytes heap in SPL.
>>>> For the SRAM part of ATF we need to allocate 0x2000-0x2200 bytes.
>>>> For the PMUSRAM part about the same again.
>>>>
>>>> I tried to increase the heap size to 0x10000, but that seems
>>>> to break some unchecked assumptions about the memory layout,
>>>> because then SPL resets very early.
>>>
>>> So what calls this malloc-free pair so often to spend all the simple
>>> malloc area ?
>>
>> The bouncebuf code (bounce_buffer_start(), which does memalign().
>> It is called twice (once for SRAM and once for PMUSRAM) as mentioned above.
>>
>> That's all part of loading the ATF parts (on RK3399 we have normal ATF code,
>> SRAM code and PMUSRAM code).
> 
> Can you switch to full malloc ?

Tested that as well, but that did not work either (again SPL crashes quite early).

I think the reason is the following:
Full malloc needs the data section to be working for the global variables
(besides gd fields). I think that's not possible in very early SPL stages,
where the first pages are going to be mapped (and malloc is used for allocating
the page table entries).