-----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. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRTGqwAAoJENk4IS6UOR1WaLsP/0exKAgPt0pOskKewNCNP2C5 RlaZ55mG+ueWtYCXDhosNTD8H5AgPmOzA+zblUPOzUpX4+EASoaAoq4LNNnaKGJf a9lPS+rsnSoefrM4qCzcDx6Iq8AIY6Vaj9I9VaaDtCDgT9wMILNpkHobalujC7hl PoCW0niIJZl05mRI6YaMP32zrtHxnZAJHRGPIX1/f7PMAg7WwoJXZc14snMaaFGT Bi2JXFswT07Vjttmk14qnaYt1zApHY2vmTn+kAnncokl9vu7Go5pcwOmrnNCONcY qeHkYSed+y+q/5fczxFYMncxbeBNC1l3RpkOX5j05Sa9DEylyNxPlQAfFZ7klt2s Fy+5C4s08q/vNFsL/b/Ic7xl80bfTWIu0BAY3OFKBJl7OnKyIdEtri7LCYEYrkZI 0UvDu6TZVc37WG5CcrqM0DcRr7YCZ6Ak6N3qMYwcWKKarW9T9dhC/pyQ9m591Abr NTjsRyRdDYhFNs3a/25SNazvqDlI1cF/BwUGUsLdZJ9tdG9mS5mLNU7okP+KtP7K cfJGb0Ln+AB1TPZRXFuEM4gEJIYhoDbOmJenjEKWDxWbV2cLAqX/Lk3dBTO+RnMS XHYBS2cSG46gkgXf3rqvhd4md93HoYRD6h2MBzxLyKhyjOicHk5zfeFMYmYrZCEO /uyGAvA+hkIyJXmVzNbb =Hn61 -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
