I do a lot with assembly. most of the code that launches long mode is easier / essential to be in assembly. I personally opted for using GRUB, but now i have a

I do a lot with assembly. most of the code that launches long mode is easier / essential to be in assembly. I personally opted for using GRUB, but now i have a good idea on what that does for me i want to go back to writing a bootloader for my OS too. (done some basic ones, but didn't really know what information i had to pass. multiboot info from grub contains this). I dont use UEFI, but i think there you will need to consult the EFI manuals and use the SDK for EFI to build a module. This module then takes over from the boot loader, so in essence you will need code in there that gathers a memory map/info, vbe and apm informations, ACPI pointer (rsdp) and some more informations. efi is a firmware framework, so using an sdk here makes sense. otherwise you need to find out the offsets to the firmware functions yourself. BIOS uses interrupts for this but not sure how uefi does it sorry, i never tried! I will say that once you land in kernel land C is really nice. it saves a lot of typing. But i started out using pure assembly as it made more sense typing these instructions based on the manuals, c can be a bit too obscure to translate too if you're starting out. (still have trouble :') sometimes ...) Also stuff like loading CR3 with new page table pointer etc. just isn't possible atall in C. (you can inline it with asm volatile (); but inline asm is tedious in itself...) i'd reccomend using GRUB bootloader, then you can write a loader stub in there which moves the CPU into 64 bit mode and is in ELF format, so you can also compile the os itself in ELF format. I used to use binary blobs from nasm, but i had a world of trouble generating C code into binary blobs. The linking procedure to link a 32 bit loader into a 64 bit kernel is a bit tedious but once it's working you can have 1 script which only does some generation of .o files and links it all together instead of catting binary blobs together and using hardcoded offsets to load them into memory etc. (that was a fun adventure, but really caused me a lot of headache more than anything :D) if you want to do your own bootloader, consider that you should really write an ELF parser. i dont like the idea of sticking with some file format that's made by other people, but if you want to do it in your own executable format then you need to figure out to write a compiler / assembler for that format which is a lot of work. hence the choice to make an elf parser will get you started easier. if you want to just use nasm -fbin to make everything binary blobs you need to figure out how you will load everything and create mappings in pages to contain data. hardcode a lot of things which the linker/loader usually does for you. i think this will be the next level :D i can't imagine a better project for learning about how computers really works :D reccomened for anyone interested in computers!