On Fri, Jun 8, 2018 at 3:20 PM Adam Ford <aford...@gmail.com> wrote: > > On Fri, Jun 8, 2018 at 2:15 PM Tom Rini <tr...@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 <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot