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 <ansh...@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
