Hi, On Wed, 23 Apr 2025 at 08:22, Ahmad Fatoum <a.fat...@pengutronix.de> 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.
Yes, FIT is a better route and we can even add an OS type IH_OS_xxx There's also the option of adding a flag to the 'go' command so that it can Regards, Simon
