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