Hi everyone,
Thanks for the earlier explanations about how Haiku’s kernel relies on the bootloader for hardware setup (MMU already enabled, a specific memory layout, framebuffer/debug UART availability, etc.). That clarified an important difference from how Linux handles early initialization.
Based on that, I hv refined approach. Instead of trying to recreate the entire bootloader environment from scratch, my idea is to reuse the boot environment that the running kernel already has.
The rough flow I’m considering now is:
1. The running kernel loads the new haiku kernel ELF into a reserved region of physical memory (similar to how segments are handled in FreeBSD’s kexec implementation).
2. Rather than rebuilding everything, the new kernel would reuse the existing “kernel_args” and memory layout from the current kernel, adjusting only what is necessary (eg, kernel image location and entry point).
3. Once the new kernel image and arguments are prepared, the system would stop secondary cpus, disable interrupts, and perform an architecture specific jump to the new kernel entry point.
4. Since the MMU and memory layout are already established, the new kernel would start in an environment similar to what it normally expects after the bootloader stage.
Does this direct jump approach make sense for haiku’s architecture, or are there additional bootloader responsibilities (such as module loading or device state teardown) that would need to be replicated before the jump?
Also, regarding @waddlesplash’s point about EFI in some kexec implementation chat : I’m open to exploring that route as well. Would adapting the standard EFI loader to start the new kernel be considered a cleaner or preferred approach compared to the state reuse method described above?