On Sun, Sep 17, 2017 at 8:50 AM, Rob Clark <robdcl...@gmail.com> wrote: > On Sun, Sep 17, 2017 at 9:42 AM, Adam Ford <aford...@gmail.com> wrote: >> On Sun, Sep 17, 2017 at 7:53 AM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford <aford...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
