From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chee, Tien Fong Date: Mon, 25 Feb 2019 03:33:27 +0000 Subject: [U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer In-Reply-To: <0d4cbfbf-a65e-b78f-7886-85fe4f0ec8db@monstr.eu> 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> <1550807383.10053.8.camel@intel.com> <0d4cbfbf-a65e-b78f-7886-85fe4f0ec8db@monstr.eu> Message-ID: <1551065606.10305.1.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 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 > > > > > > > > > > > > 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? > 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. > >