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. BR, -R _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
