[RFC] Expected behavior of the go command

[Ahmad Fatoum]

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

> 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

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |