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 <i...@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 <tr...@konsulko.com>
Signed-off-by: Emmanuel Vadot <m...@bidouilliste.com>
Reviewed-by: Simon Glass <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
