[RFC] Expected behavior of the go command

[Kumar, Udit]

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
>>>>
>