On Tue, May 13, 2025 at 07:25:53PM +0800, Zixian Zeng wrote: > On 25/04/30 01:32PM, Tom Rini wrote: > > 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. > > > It might be a novice question, sorry.. > > I'm using uboot on riscv, and noticed that the "bootelf" command just > jumps to the entry point of the ELF file. What if I want to boot > multiple harts? > > bootm command calls "smp_call_functions" to change global variables > `gd->arch.ipi` which restores function addr and arguments > and sends IPI to each hart, but "bootelf" does not. > > It might not be a problem on other arches such as x86, if I recall > correctly, x86 can specify the function address when sending IPI. > > Thanks for your time.
It is quite likely that yes, we need a little more work on "bootelf" to handle the standard way, if there is one, of passing this information to an ELF application. I would have assumed that we would put any other processors in to the (I assume exists) OS-agnostic parking spot and they can be discovered and handled by the OS as needed. -- Tom
signature.asc
Description: PGP signature
