[U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer
Chee, Tien Fong
tien.fong.chee at intel.com
Fri Feb 22 03:49:46 UTC 2019
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 <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
> 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
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
More information about the U-Boot