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

[Chee, Tien Fong]

On Fri, 2019-02-22 at 10:16 +0100, Michal Simek wrote:
> On 22. 02. 19 4:49, Chee, Tien Fong wrote:
> > 
> > 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 inte
> > > > > l.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
> > > 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?
> TBH I don't know now. I tried to debug that. I want to support option
> to
> use DT from fixed location to support qemu DT generation which we
> have
> enabled for next generation. And I use 0x1000 location which is in
> conflict with bss section. That's why I have moved BSS section out of
> this space to make sure that I am not breaking dtb out there.
> And it is working quite well but when this patch is applied DTB is
> being
> corrupted by SPL(don't know which code) and on reboot dtb magic is
> correct but content is broken.
> I don't know the first address and I need to find some time to run
> this
> on Qemu and see activities in that area to find out which code is
> breaking this.
> Anyway I don't have a time for debugging this more now but bisect
> pointed to this patch but as I said it just exposed likely problem
> somewhere else.
> 
Okay. You might need to consider Tom's suggestion, 1MB is too large for
SPL malloc pool, some other places might overflow and corruption.
> 
>