On Wed, Apr 30, 2025 at 10:56:27PM +0530, Raghavendra, Vignesh wrote: > > > On 4/30/2025 10:01 PM, Tom Rini wrote: > > On Wed, Apr 30, 2025 at 11:29:04AM -0500, Bryan Brattlof wrote: > >> On April 30, 2025 thus sayeth Anshul Dalal: > >>> As discussed here[1], the go command causes undefined behavior when used > >>> for running custom OSes since the icache might hold outdated data. OSes > >>> usually also expect the MMU to be disabled upon execution. > >>> > >>> Therefore this patch adds a call to cleanup_before_linux before we jump > >>> to the loaded program/os which disables both the caches and the MMU. > >>> This makes the go command's behavior consistent with riscv platforms. > >>> > >> > >> I know quite a few other OSes are beginning to use U-Boot (QNX, > >> GreenHills or all the other RTOSes) each with their own requirements > >> from the bootloader. I'm curious if we should make boot* a little more > >> generic rather than abuse the 'go' command. > > VXworks has its own: > https://docs.u-boot.org/en/stable/usage/os/vxworks.html > > I suppose QNX and others should ideally have their own cmds as needed.
Well, what's the QNX output file format (options?) again? > > Well, that's what bootelf is for :) > > > > And if its not an elf but some .bin file "go" cmd should be used in > conjunction with "cache" cmd here to flush/disable cache, I guess? Well, what exactly are we talking about? Is this an "in theory" or some project(s) which exist today? There's a whole lot of reasons for either a legacy header and bootm or a not-legacy FIT image. The "go" command is for the "U-Boot is a debugger" side of the world, not how you should kick off some OS/application in production. It is all of the "this is dangerous" idioms. > If so, we should probably update the docs for this cmd appropriately so > as to avoid end users overloading like what RISC-V did? Yes, we should clarify things as needed and unwind, most likely, what RISC-V is doing. But not blindly so as perhaps there's now, sigh, a production / in-the-wild case here and we're now in a sticky spot. -- Tom
signature.asc
Description: PGP signature
