On Fri, Feb 10, 2017 at 01:07:40PM +0100, Emmanuel Vadot wrote:
On Wed, 8 Feb 2017 10:00:54 -0500 Tom Rini trini@konsulko.com wrote:
On Tue, Jan 31, 2017 at 12:17:06PM +0100, Emmanuel Vadot wrote:
From: Warner Losh imp@freebsd.org
Some application might load some code at location that contain stale cache entries. Before running a elf or raw binary, flush the caches if they are enabled.
Reviewed-by: Tom Rini trini@konsulko.com Signed-off-by: Emmanuel Vadot manu@bidouilliste.com Reviewed-by: Simon Glass sjg@chromium.org
api/api.c | 5 +++++ cmd/boot.c | 4 ++++ cmd/elf.c | 5 +++++ 3 files changed, 14 insertions(+)
diff --git a/api/api.c b/api/api.c index c368511704..88b5df77c0 100644 --- a/api/api.c +++ b/api/api.c @@ -290,6 +290,11 @@ static int API_dev_close(va_list ap) if (!err) di->state = DEV_STA_CLOSED;
- if (dcache_status())
flush_dcache_all();- if (icache_status())
invalidate_icache_all();So this runs into a problem. Building for sandbox, or many many other platforms gives us: undefined reference to `dcache_status' undefined reference to `flush_dcache_all' undefined reference to `icache_status' undefined reference to `invalidate_icache_all'
At the high level, we have a few problems. We don't have a global "has icache" and "has dcache" support CONFIG symbol. We also have a few instances of weak functions that end up being no-ops in these cases, but it's not quite correct to use them in this case, possibly. For example, PowerPC does have dcache support and functions but no flush_dcache_all (and only sometimes a flush_dcache() that looks like it would be _all()), and same for icache.
Hi Tom,
Will depending on CONFIG_CMD_CACHE will be acceptable ? This is the easiest fix that I can think of.
That will continue to bring in the PowerPC side of the problem. I'll see about doing a little research to confirm what I said about the cache functions on PowerPC and we can move from there.