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

[Simon Goldschmidt]

On Tue, May 7, 2019 at 4:20 PM Christoph Müllner
<christoph.muellner at theobroma-systems.com> wrote:
>
>
>
> 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 should have expressed myself clearer. I meant the fact that full malloc
cannot be used in early SPL stages :)

I bumped into that on socfgpa_a10, too. And I still think it's a rather
random limitation that should be overcome.

Regards,
Simon

>
> 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