-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/22/2013 12:48 PM, Scott Wood wrote: > On 03/22/2013 09:29:04 AM, Tom Rini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 03/22/2013 10:03 AM, Wolfgang Denk wrote: >>> Dear Tom, >>> >>> In message <514c4be8.10...@ti.com> you wrote: >>>> >>>> It seems like we're going around and around with one point >>>> not being addressed. When using 'go', how do you know the >>>> size to flush? And since Scott is talking about performance >>>> testing apps, the cache should not be disabled (unless we >>>> expect all standalone apps to enable the cache, in which case >>>> we need to provide something in the jump table to make that >>>> easy and document this change). >>> >>> I also wonder about this. To me it appears much easier to use >>> a IH_TYPE_STANDALONE image, which 1) provides the needed size >>> information and 2) can be used with bootm, so the required >>> additional steps (flush caches, release CPU) can be handled in >>> bootm subcommands. >> >> But that then circles us back to Scott's other point of "go" is >> broken then and it is the recommended way to start standalone >> applications. >> >> Now, if we want to change things and say that no, you can't just >> run totally raw binaries reliably with "go" but instead need to >> throw some form of header on top of them, how portable, really, >> is mkimage? We've just made that a required part of the >> work-flow for anyone doing development that's not producing ELF >> or something else already boot*'able. That might be a rather >> large pool I suspect. >> >> Scott, part of the problem here is that we have multiple cores, >> yes? Say core0 is the one that read things in from NOR to DDR, >> core1 is the one that will be running things. How about we make >> flush_cache depend on CONFIG_MP || CONFIG_CMD_CACHE_FLUSH ? It's >> a likely required often thing for CONFIG_MP systems and anyone >> else that needs it can opt-in. > > Multiple CPUs may make it more likely to see problems on some > hardware, but architecturally on PPC the flush is required even > with a single CPU. Icache fetches won't snoop the dcache. > > Can we have it depend on a new config symbol, so it's not bloating > anyone's U-Boot who doesn't want it, and deal with improvements to > recommended standalone app workflow as a separate issue? We're not > talking about a huge amount of code here, just exposing > functionality that U-Boot already has internally.
Works for me. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRTJK8AAoJENk4IS6UOR1W27sP/0pS2QGy0qzfgKrRyuIDbgRG harO37ddiKNy5NTKFP8kXEFz1mIFgYk8Lu6SE30hu5kDje4t4bWK9S2F1NPcU8tr r5zM+ekR8y3q29P4Upk98YPMEkgV6L0FmnyQOkcQi3Kdg6Lx+S5GHikUQ6uvPJlh EBir2XQEZWxVWrL5KTdJV3TZ34NfLPh/gkXSpQTlvfFgGhsbskypt4DOgxz5Vl9d khOGMk9nX8o3iMaO/gf9F1d5wIoCAt4rzrBaPc/lu/KCMfC6JVmsJP21BCEOVols NgykmYxm+E8M5/vItCBzWrbGgkmeUfHbnhxGZXYHFPgPkPlz4s8CJZgKblwk4RkN BVEgfAnJblgPut5vV4Mz+x1D9Z0EQ12ZC3yTJlO2BssfbBK+oVr3r6e2S4HLp08o VV0wEF5E6fdc2M0gUUJFIMsX/vxjz7fB2y7dYKZmYk08IZvmL5Ddr31E0t/o6IvG Kp4lymSEEe20IdNuUxp0km4evild4NrcefCNsB/41F5poIdoJ9XudIK9aSFVHAah IB0nNiszLSgO4fUz3i7XUo8cW/jUzlS2vZe4RBXo8BqYR9GLo9wAhICFibIFVP4i JK7WA01Vjaqax6zn66L2ngdd/moA/jKalIMchxJehy2v4/Manvh1tno4OQJQ5BKJ cfCkfeurwOY6BgCef7mz =OaP1 -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
