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

[Christoph Müllner]

On 07.05.19 16:16, Simon Goldschmidt wrote:
> On Tue, May 7, 2019 at 4:11 PM Christoph Müllner
> <christoph.muellner at theobroma-systems.com> wrote:
>>
>>
>>
>> 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).
> 
> Exactly. I think you're at least the third person on this list stumbling
> accross this in the last weeks :(

I was "lucky" enough to get bad weather this weekend, so I could debug
each and every ATF loader issue for the SD card boot case.

The tree I was testing with (on RK3399-Q7/Puma with Haikou) can be found here:

https://git.theobroma-systems.com/puma-u-boot.git/log/?h=puma-v2019.04-atf