[RFC] Expected behavior of the go command

[Kumar, Udit]

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
>