
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@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?
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.
Thanks, Michal