[U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases

Adam Ford aford173 at gmail.com
Fri Jun 8 20:49:28 UTC 2018


On Fri, Jun 8, 2018 at 3:20 PM Adam Ford <aford173 at gmail.com> wrote:
>
> On Fri, Jun 8, 2018 at 2:15 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Jun 08, 2018 at 10:30:36AM -0500, Adam Ford wrote:
> > > On Tue, May 22, 2018 at 11:24 AM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > When dealing with filesystems that come from block devices we can get a
> > > > noticeable performance gain in some use cases from having the block
> > > > cache enabled.  The code paths are valid in other cases when we have BLK
> > > > set and may provide wins in raw reads in some use cases, so have this be
> > > > default when BLK is enabled.
> > > >
> > > Tony,
> > >
> > > This breaks the AM3517 EVM. It appears to cause issues in MLO which
> > > may not have enough RAM to cache, but I can fix it by disabling
> > > BLOCK_CACHE.
> > > I can submit a patch to disable it on the AM3517, but I am wondering
> > > if something can/should be done to disable it or optionally disable it
> > > in SPL so it's still
> > > available in U-Boot.  I can confirm that when disabled in SPL only, it works.
> > >
> > > Any opinions on this?
> >
> > So, we had talked before about bumping SYS_MALLOC_F_LEN to 0x2000 for
> > ARCH_OMAP2PLUS, but I see am3517 is already doing that.  Can you see if
> > there's enough room to go to say 0x4000 and it works?  Otherwise, we
>
> I tried setting it to 0x4000, but it just hangs:
>
> U-Boot SPL 2018.07-rc1-00040-g71002b508a (Jun 08 2018 - 15:16:44 -0500)
> Trying to boot from MMC1
>
> > need to (and I was worried we might) need to add SPL_BLOCK_CACHE and
> > have that default off.  Thanks!
>
> Do you want me to work on that patch or did you want to do it?

I just submitted a patch to the mailing list which fixes the AM3517.
I figured I was 1/2 way there, so I just finished it.

adam

>
> adam
> >
> > --
> > Tom


More information about the U-Boot mailing list