From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christoph_M=c3=bcllner?= Date: Tue, 7 May 2019 15:55:06 +0200 Subject: [U-Boot] [PATCH 1/2] bouncebuf: Add static buffer allocation method for SPL. In-Reply-To: <0c05d8f0-0833-7aa4-51e0-2d03031d4833@denx.de> References: <20190507090936.51687-1-christoph.muellner@theobroma-systems.com> <22733bba-07dd-4ad6-be64-da2f34b89f75@denx.de> <70807b94-3a09-80d4-0dd8-d79dc76af6a0@theobroma-systems.com> <0c05d8f0-0833-7aa4-51e0-2d03031d4833@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de On 07.05.19 15:52, Marek Vasut wrote: > On 5/7/19 3:45 PM, Christoph M=C3=BCllner 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. >=20 > 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).