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. Cheers, Ahmad > > Regards, > Simon > -- 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 |
