[U-Boot] [U-Boot, v3, 3/9] fat/fs: convert to directory iterators

[Tom Rini]

On Sun, Sep 17, 2017 at 08:53:23AM -0400, Rob Clark wrote:
> On Sun, Sep 17, 2017 at 7:08 AM, Adam Ford <aford173 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170917/d0f21981/attachment.sig>