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