From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chee, Tien Fong Date: Fri, 22 Feb 2019 03:49:46 +0000 Subject: [U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer In-Reply-To: <20190222032200.GO12379@bill-the-cat> References: <1549868180-21635-1-git-send-email-tien.fong.chee@intel.com> <20190220015744.GN21737@bill-the-cat> <6e8f32fe-f956-3b7a-d492-9f99dc3f41e3@monstr.eu> <20190222032200.GO12379@bill-the-cat> Message-ID: <1550807383.10053.8.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Thu, 2019-02-21 at 22:22 -0500, Tom Rini wrote: > On Thu, Feb 21, 2019 at 08:45:37AM +0100, Michal Simek wrote: > > > > Hi Tom, > > > > On 20. 02. 19 2:58, Tom Rini wrote: > > > > > > On Mon, Feb 11, 2019 at 02:56:19PM +0800, tien.fong.chee at intel.co > > > m wrote: > > > > > > > > > > > From: Tien Fong Chee > > > > > > > > Drop the statically allocated get_contents_vfatname_block and > > > > dynamically allocate a buffer only if required. This saves > > > > 64KiB of memory. > > > > > > > > Signed-off-by: Stefan Agner > > > > Signed-off-by: Tien Fong Chee > > > Applied to u-boot/master, thanks! > > please remove this patch (better both of them because they were in > > series) because they are breaking at least ZynqMP SPL. It is also > > too > > late in cycle to create random fix. > > > > You can't simply move 64KB from code to malloc without reflecting > > this > > by changing MALLOC space size. > > > > Other boards with SPL fat could be also affected by this if they > > don't > > allocate big malloc space. > I see from later in on the thread your specific problem is elsewhere. > But to address the root question, we have fairly large malloc > requirements in SPL when FAT is involved as there's a lot of other > mallocs going on there.  It's indeed not impossible there's a board > that > was on-edge of it's 1MB pool, and now goes over, but that seems > unlikely.  Thanks all! I'm curious what's the actual problems you found? running out of memory, no? Increasing Malloc space size is definitely required for The patch[1/2], but patch[2/2] would maximize the re-usable of memory, so in other words, no change on Malloc space size required. Both patches would share the same memory. You might need to take a look these patches, they are part of vfat optimization. https://patchwork.ozlabs.org/patch/1029679/ https://patchwork.ozlabs.org/patch/1029681/ https://patchwork.ozlabs.org/patch/1029682/ https://patchwork.ozlabs.org/patch/1029683/ > Thanks, TF