On Sun, Sep 17, 2017 at 8:50 AM, Rob Clark robdclark@gmail.com wrote:
On Sun, Sep 17, 2017 at 9:42 AM, Adam Ford aford173@gmail.com wrote:
On Sun, Sep 17, 2017 at 7:53 AM, Rob Clark robdclark@gmail.com wrote:
On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford aford173@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