Thanks Ahmad
On 4/25/2025 11:09 AM, Ahmad Fatoum wrote:
Hi Udit,
On 25.04.25 06:35, Kumar, Udit wrote:
On 4/23/2025 7:52 PM, Ahmad Fatoum wrote:
I went with the FIT route for barebox, because we can now ship device
trees for all enabled boards in the same FIT image alongside one generic
second stage barebox with DT support. If you want to support different
boards with your OS image that might be of interest to you as well.
Sorry for novice question.
But trying to understand how FIT fixes problem for you .
at the end, its a jump command to OS/other code be it through u-boot go or fit
way.
The difference is whether, prior to the jump, the caches are flushed and the MMU
is disabled and U-Boot's go does neither.
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(...)
return entry (argc, argv);
}
I see even ARM64, few board choose to over-ride default option
(board/xilinx/versal/board.c)
do_go_exec does dcache_disable()
Because go doesn't do any cache maintenance, what guarantee do we have
that the I-Cache actually reflects the data that was freshly loaded?
correct , depends upon address etc , it may or may not work
It might only work because the region you go to happens to not be resident
in the I-Cache yet...
FWIW, barebox go does cache maintenance and disables the MMU, which
is why I mistakenly thought U-Boot's go would behave similarly.
barebox didn't inherit the jump table mechanism.
In case OS/other code handles caches, then should not be an issue.
But this put requirement on next stage to take care of caches [0]
In the fit case, MMU is disabled and so the next stage is free to
not do any cache maintenance if it doesn't need to enable the MMU.
Linux and barebox want to use the MMU/caches by default, so that's
why they have to do cache maintenance.
Sorry I was not clear in previous message,
Here OS take care of caching , irrespective of how boot is done through fit
or kind of efi or other method.
If they assume MMU is disabled on startup, it follows the lines in
the cache are stale and unimportant and then memory corruption
occurs once they are discarded.
Cheers,
Ahmad
[0] :
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L105
Cheers,
Ahmad
Regards,
Simon
