On Wed, Apr 30, 2025 at 02:26:04PM -0500, Bryan Brattlof wrote: > On April 30, 2025 thus sayeth Tom Rini: > > 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? > > I've only ever seen outputs in compressed binary formats but I've been > told there are tools to produce an ELF for the simulators > > > > > > > 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? > > > > I noticed this thread mainly because of the number of RTOS people asking > me about low level stuff U-Boot and TF-A is doing. I haven't seen any > 'In-Production' type bugs but I wouldn't be surprised if U-Boot is being > used in their CI environments today.
A number of RTOSes are already supported via "bootm". If they've stopped
working (as we don't have tests in CI for them) I'd love patches to fix
and at least instructions on how to make it fail somewhere, ideally
QEMU.
> > 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.
>
> I like the idea of boot${OS} flags if only to standardize the interface
> of how each OS should boot. I worry about situation where custom
> scripting is being used to boot in production rather than stdboot
Right. And that's part of why in this day and age, regular uses should
not be using "go". We've had and supported RTOSes via "bootm" for what
amounts to forever. We've had "bootelf" for arbitrary things for ages
too (and in turn, your custom app/RTOS/whatever using the normal bare
metal ELF linker script, target, etc makes it easier on that side too).
In more recent times, having a whatever project spit out an EFI binary
instead is also possible and done sometimes.
--
Tom
signature.asc
Description: PGP signature
