On 07.05.19 16:16, Simon Goldschmidt wrote: > On Tue, May 7, 2019 at 4:11 PM Christoph Müllner > <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
