[U-Boot] [U-Boot, v3, 3/9] fat/fs: convert to directory iterators

[Adam Ford]

On Sun, Sep 17, 2017 at 8:50 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Sun, Sep 17, 2017 at 9:42 AM, Adam Ford <aford173 at gmail.com> wrote:
>> On Sun, Sep 17, 2017 at 7:53 AM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford <aford173 at gmail.com> wrote:
>>>>
>>>> Adding the debug to master made no difference.  No debug messages appeared.
>>>> Interestingly enough, some junk appeard, and the name of U-Boot name
>>>> wasn't correctly displayed:
>>>>
>>>> **Sș017.09-00178-g08cebee-dirty (Sep 17 2017 - 06:01:07)
>>>> Trying to boot from MMC1
>>>>
>>>> (hang)
>>>>
>>>
>>
>> With the TINY_PRINTF disabled (except in SPL),  the log looks better:
>>
>> Trying to boot from MMC1
>> reading u-boot.img
>> VFAT Support enabled
>> FAT16, fat_sect: 1, fatlength: 200
>> Rootdir begins at cluster: 536870910, sector: 401, offset: 32200
>> Data begins at: 417
>> Sector size: 512, cluster size: 8
>> FAT read(sect=401, cnt:2), clust_size=8, DIRENTSPERBLOCK=16
>> RootMismatch: |mlo||
>> Rootvfatname: |u-boot.img|
>> RootName: u-boot.img, start: 0x12, size:  0x83708
>> Filesize: 538376 bytes
>> 64 bytes
>> gc - clustnum: 18, startsect: 561
>> Size: 538376, got: 64
>> reading u-boot.img
>> VFAT Support enabled
>> FAT16, fat_sect: 1, fatlength: 200
>> Rootdir begins at cluster: 536870910, sector: 401, offset: 32200
>> Data begins at: 417
>> Sector size: 512, cluster size: 8
>> FAT read(sect=401, cnt:2), clust_size=8, DIRENTSPERBLOCK=16
>> RootMismatch: |mlo||
>> Rootvfatname: |u-boot.img|
>> RootName: u-boot.img, start: 0x12, size:  0x83708
>> Filesize: 538376 bytes
>>
>>
>>
>>> hmm, one thing I noticed in doc/README.SPL:
>>>
>>> "When building SPL with DEBUG set you may also need to set CONFIG_PANIC_HANG
>>> as in most cases do_reset is not defined within SPL."
>>>
>>> not sure if that would help.
>>>
>>
>> I did try your experiment with keeping the working SPL and using the
>> newer u-boot.img file and that worked, so I am guessing it's probably
>> related to tight memory in SPL.
>> I looked up the mapping in doc/SPL/README.omap3 and it shows:
>>
>> 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
>> 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
>> 0x80000000 - 0x8007FFFF: Area for the SPL BSS.
>> 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
>> 0x80208000 - 0x80307FFF: malloc() pool available to SPL.
>>
>> For this board, CONFIG_SYS_SPL_MALLOC_SIZE is set to 0x100000
>>
>> I don't know if any of this is helpful information to you or not.
>
> I think we narrowed it down to stack usage.. Tom tested the "please
> test" patch I just sent and it works for him.
>
> If reducing SPL_MALLOC_SIZE increases available stack size, that might
> also work.  But I think for next release we can just go with my patch
> that moves itrblock off the stack.
>
>>> Also, it has a section about estimating stack usage.. not sure if this
>>> implies that stack size is constrained in spl?  If so, maybe that is
>>> related.  The new directory iterators do move the buffer for current
>>> block of dir_entry's to the stack.  Reducing
>>> CONFIG_FS_FAT_MAX_CLUSTSIZE might help.
>>
>> Any recommendations on how small this can go and still operate
>> reliably?  I don't want to just arbitrarily choose something.
>
>
> Sector size: 512, cluster size: 8
> FAT read(sect=401, cnt:2), clust_size=8, DIRENTSPERBLOCK=16
>
> So I think 512 * 8 = 4096 would work for your filesys.. what I'm not
> entirely sure is what range of sector sizes and cluster sizes are
> possible.  64k seems *way* too much.  Maybe in the end I should switch
> to malloc() so we can allocate just what is needed.
>
> I'll give it some thought for my next batch of fs/fat work.. but
> suggestions welcome.
>

When I wrote that, I didn't see either Tom's comments or you updated
patch yet, but you can go ahead and add my tested-by because I'm
satisfied with that.

adam
> BR,
> -R