[RFC] Expected behavior of the go command

[Kumar, Udit]

On 4/23/2025 7:52 PM, Ahmad Fatoum wrote:
> Hi,
>
> On 4/23/25 14:28, Simon Glass wrote:
>> Hi Anshul,
>>
>> On Wed, 23 Apr 2025 at 04:04, Anshul Dalal <anshuld at ti.com> wrote:
>>> Hi all,
>>>
>>> I was trying to understand how the go command is expected to work when
>>> used to load custom OSes. My use case requires getting a proprietary OS
>>> to boot using the go command on a TI K3 platform. The OS expects caches
>>> to be flushed and the mmu to be disabled before we jump to it.
>>>
>>> The go command (do_go func in cmd/boot.c) calls the do_go_exec function
>>> underneath which does not seem to have a consistent implementation
>>> across various architectures.
>>>
>>> In RISC-V the implementation (arch/riscv/lib/boot.c:10) calls
>>> cleanup_before_linux before jumping to the loaded binary. This behaviour
>>> would enable the direct use of the go command for booting a custom OS
>>> (like in my use case). Though no such generic implementation exists for
>>> ARM64.
>>>
>>> I was wondering why we have the call to cleanup_before_linux for RISCV
>>> and not ARM64?
>>>
>>> Also, is booting a custom OS using the go command a supported use-case?
>>> If yes, it might be better to rename the function to be more generic
>>> like cleanup_before_os from *_linux and call it for each invocation of
>>> the go command.
>> Yes it is supposed to do what you say. You could rationalise the code
>> a bit, so that all archs do a similar thing, or perhaps just RISC-V
>> and ARM for now.
> I ran into issues with go too trying to start barebox and I always
> assumed that go is rather meant to start programs that call back into
> U-Boot using the jump table mechanism. In that case, you likely don't
> want to turn off caches.
>
> What I settled on is having the barebox build generate a FIT image that
> can be used from U-Boot, barebox, coreboot ...etc.
>
> Maybe the same would be also suitable for you? Alternatively, you could
> compile your custom OS as an ELF image and boot that properly as if it
> were a kernel. Both ways would also allow you to specify a load address
> if your OS is not relocatable and pass along arguments.
>
> 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.


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]


[0] : 
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L105


>
> Cheers,
> Ahmad
>
>> Regards,
>> Simon
>>