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

[Rob Clark]

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.

BR,
-R