The common wisdom with OSdev hobbyists is "if you want to write an OS, don't write a bootloader".
Boot protocols are very uninspiring, arcane knowledge and understanding it does not bring any advantages (unless you want to write bootloaders). Especially dealing with legacy BIOS boot sequence, which is essentially a backwards compatibility emulation layer implemented in the firmware.
It's not like home computers of the 1980s where you'd look at the processor data sheet how the CPU actually boots (which address the program counter starts from, what's the initial machine state, etc).
By far the easiest way to get started in x86 bare metal programming is using the Multiboot header, which is supported by bootloaders (like Grub) and emulators (like QEMU). And you can use GDB for debugging.
Using UEFI is more involved to get started. The initial setup is more involved (you need UEFI headers and libs, etc), the build process is more complex (UEFI images are "Windows" PE executables) and attaching a debugger is not as easy as with a Multiboot-ELF image. UEFI "boot services" provide some nice things that may be helpful to get memory maps and CPU hierarchy so you don't need to go through the hassle of parsing EBDA and MP and ACPI tables.
The legacy BIOS boot protocol is "easy" to get started with (nasm -f bin mykernel.asm), but you have to deal with arcane stuff (like floppy drive BIOS routines, A20 lines), you don't get a debugger. This is by far the worst way to get started. It's not really "doing it from scratch", instead of using a proper bootloader you need to deal with a really bad bootloader implemented in your PC firmware.
Have you got any reference material on how to get started using the multiboot/qemu/gdb route? I've started (and failed) the BIOS-bootloader route a fair few times now, But I'm not really interested in the boot process itself in the first place.
Boot protocols are very uninspiring, arcane knowledge and understanding it does not bring any advantages (unless you want to write bootloaders). Especially dealing with legacy BIOS boot sequence, which is essentially a backwards compatibility emulation layer implemented in the firmware.
It's not like home computers of the 1980s where you'd look at the processor data sheet how the CPU actually boots (which address the program counter starts from, what's the initial machine state, etc).
By far the easiest way to get started in x86 bare metal programming is using the Multiboot header, which is supported by bootloaders (like Grub) and emulators (like QEMU). And you can use GDB for debugging.
Using UEFI is more involved to get started. The initial setup is more involved (you need UEFI headers and libs, etc), the build process is more complex (UEFI images are "Windows" PE executables) and attaching a debugger is not as easy as with a Multiboot-ELF image. UEFI "boot services" provide some nice things that may be helpful to get memory maps and CPU hierarchy so you don't need to go through the hassle of parsing EBDA and MP and ACPI tables.
The legacy BIOS boot protocol is "easy" to get started with (nasm -f bin mykernel.asm), but you have to deal with arcane stuff (like floppy drive BIOS routines, A20 lines), you don't get a debugger. This is by far the worst way to get started. It's not really "doing it from scratch", instead of using a proper bootloader you need to deal with a really bad bootloader implemented in your PC firmware.