On 02/08/2017 04:00 PM, Tom Rini 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.
Well, if we want to keep the API consistent (which I think we do) we should probably fix that :). It's quite a good chunk of unpleasant work though...
Alex