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@intel.co m wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
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 stefan.ag...@toradex.com Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
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