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.
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.
BR, -R
adam