Hi Tom, On Tue, 24 Feb 2026 at 09:13, Tom Rini <[email protected]> wrote: > > On Tue, Feb 24, 2026 at 07:25:42AM -0700, Simon Glass wrote: > > > Each arch does something slightly different before booting the OS. Some > > archs even do different things depending on the CPU type. > > > > It is quite hard to know what actually happens in the final milliseconds > > before the OS boot. > > > > This series attempts to start cleaning up U-Boot in this area. > > > > The basic intent is to create a new bootm_final() function which can be > > called by all archs. It provides some flags for a couple of necessary > > variations but otherwise it is generic. > > > > RISC-V, x86 and ARM are converted over to use this new function. For > > consistency, EFI loader is converted as well. > > Please include all architectures in v3, ARM is still not shown in this > series. > > > A noteable change is that EFI_LOADER now does bootstage processing > > before boot, if enabled, thus producing a report. > > > > There is also a patch to drop EFI_GRUB_ARM32_WORKAROUND, as discussed > > recently on the mailing list. > > > > Future work could take this a little further: > > - Drop board_quiesce_devices() and rely on driver model for that > > Potentially, but there's non-trivial uses that don't fit in driver model > today either. > > > - Similarly with udc_disconnect() > > Please look at mainline code again. > > > - Look at converting EFI to use the same function > > You said a few lines above EFI was converted? Please make sure your > cover letter is consistent and correct in v3. > > > Also, the comment for cleanup_before_linux() could use more details as > > to what it is supposed to do, to reduce the number of arch-specific > > variations. It currently does different things on differents archs and > > is mostly uncommented (apart from an ARM-specific note in a README). > > Ideally it would be commented with exactly what it should do, ideally > > at a high level so it is not just arch-specific. > > > > While some of these arch-specific differences are necessary, some are > > just due to the changes to code over time. > > This is due to the entry requirements for Linux being architecture > specific. This is more consistent than it was 15 years ago (especially > since RISC-V looked at arm64 and copy/pasted as much as they could, > which is a good thing!) but still an inherently architecture-specific > thing, so yes, we may only end up with limited overlap.
Just to pick up on this point, yes different Linux interfaces are needed, but that is not the target of this series. I am more talking about the differences which are either unintended, or just a rusult of there being more development on some archs than others. Regards, Simon
