On Sun, Sep 17, 2017 at 08:53:23AM -0400, Rob Clark 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) > > > > 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. > > 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.
Yes, in SPL we don't require stack being in SDRAM and unless SPL_STACK_R is set we have a very limited stack available. And that looks to be the common thread between functional and non-functional platforms. In the case of what Adam and I both have, we could move to SPL_STACK_R easily enough. What needs to be done next 'tho would be to see if making SPL_FAT_SUPPORT depend on SPL_STACK_R, migrating the various TI platforms (and possibly others) that could butdon't use SPL_STACK_R, and seeing if we have platforms that have now lost FAT support. Or, how hard would it be to make that code not use the stack so much? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
