Hi Ahmad
On 4/25/2025 4:28 PM, Ahmad Fatoum wrote:
Hi Udit,
On 4/25/25 12:35, Kumar, Udit wrote:
On 4/25/2025 11:09 AM, Ahmad Fatoum wrote:
Thinking about it, I am wondering whether U-Boot go is inherently broken,
even for the jump-table use case, if caches are enabled:
Correct, this is what I think . Before jumping to new program go command
should make sure
things are in correct order by cache flush. Kind of below
diff --git a/cmd/boot.c b/cmd/boot.c
index 23496cafdf5..e6bb1d94a1c 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -18,6 +18,7 @@ __attribute__((weak))
unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
char *const argv[])
{
+ flush_cache(...)
yes, even with MMU left enabled, it looks like there should be an
I-Cache invalidate and D-Cache flush/clean here[1].
Yes, correct . This should be extended with above
I see even ARM64, few board choose to over-ride default option (board/
xilinx/versal/board.c)
do_go_exec does dcache_disable()
I think __weak is a fundamental mistake and upstream boards abusing it
to not have to fix things generally shows that.
Sorry I was not clear in previous message,
Here OS take care of caching , irrespective of how boot is done through fit
Yes, but with the assumption that MMU was disabled at start.
or kind of efi or other method.
Interestingly, with EFI MMU should be left enabled. Linux even
warns about the case that MMU was disabled when entering the stub.
Cheers,
Ahmad
