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

[Michal Simek]

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 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
>> 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


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs