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. -- Tom
signature.asc
Description: PGP signature
