On Wed, Apr 23, 2025 at 04:22:51PM +0200, 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.
Exactly. "go" is really just "go $addr now", and so if things like caches need to be flushed / disabled, that needs to happen via a command first. RISC-V being helpful here is an unfortunate mis-implementation. > 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. A FIT image is a good idea. It's also possible and I think more commonly how custom OSes are done, to use "bootelf" instead. -- Tom
signature.asc
Description: PGP signature
