[U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer

Tom Rini trini at konsulko.com
Fri Feb 22 03:22:00 UTC 2019

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.com wrote:
> > 
> >> From: Tien Fong Chee <tien.fong.chee at 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... at toradex.com>
> >> Signed-off-by: Tien Fong Chee <tien.fong.chee at 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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190221/4a914ae2/attachment.sig>

More information about the U-Boot mailing list