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). _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
