July 14th, 2024

Writing a BIOS bootloader for 64-bit mode from scratch

Setting up an x86_64 CPU involves BIOS loading a boot sector, assembler like nasm, and QEMU emulation. Assembly code and GDT creation are crucial for transitioning to protected mode and reaching 64-bit long mode.

Read original articleLink Icon
Writing a BIOS bootloader for 64-bit mode from scratch

The process of setting up an x86_64 CPU from a boot sector loaded in 16-bit real mode to 64-bit long mode involves using Intel manuals, an assembler like nasm, and QEMU for emulation. The BIOS loads the boot sector to memory at address 0x7c00, providing 512 bytes to bootstrap the bootloader. By following specific assembly code and a Makefile, one can set up a simple boot sector to display a message. The bootloader can be split into two stages, with stage 1 loading stage 2 into memory. Stage 2 transitions to 32-bit protected mode, requiring the creation of a Global Descriptor Table (GDT) for memory protection. After switching to protected mode, BIOS routines are no longer usable, and direct writing to the VGA buffer is necessary for text display. The process involves careful setup and understanding of x86 assembly language. The ultimate goal is to reach 64-bit long mode, which requires further steps detailed in the Intel manual.

Link Icon 10 comments
By @5- - 3 months
note that you can switch to long mode directly, without going into protected mode first, with way less code:

https://wiki.osdev.org/Entering_Long_Mode_Directly

i've had a bootloader for a small 64-bit kernel based on this that fit comfortably into the bootsector, including loading the kernel from disk and setting up vesa modes, no stage2 required.

By @hyperman1 - 3 months
The 80286 has the Machine Status Word (MSW), a 16 bit register. The 80386 expands this to CR0, a 32 bits register. Then 64 bit long mode adds the EFER MSR and expands CR0 to 64 bits. But even today only 11 bits of CR0 are in use and EFER has 8 active bits. I wonder why intel/AMD did not simply use the free bits of the existing register, and made that decision twice?

https://wiki.osdev.org/CPU_Registers_x86-64#CR0.

By @rep_lodsb - 3 months
The most unnecessarily complicated thing in this article to me is the Makefile and linker script. NASM supports generating flat binary output, but apparently using it would be too "hacky"?
By @ForOldHack - 3 months
This seems both cool, and a good exercise, but is it useful? Does it have a UX like a fisher/price toy that you can verify/change your settings on the fly?

Booting is the process of going from mini-me mode/single user/recovery mode to flying.

I have been running Unix along side a Microsoft product since Xenix/dos. ( Looks like 40 years...) How much have we advanced?

I also have been using Linux since the swedish version came out ( first release ) and GNU 0.1.

My apologies about calling Xenix, Unix, It is a has-been wanna-be me-too square-excrament from shortly after release until it's languishing demise.

Microsoft does not release products, they empty their cat boxes onto customers. ( The most recent example is both co-pilot And 22H2. )

If you look at how F1 cars have evolved, and pencils as well as pocket calculators - how close are we to the usable ideal?

Why isn't the bootloader a static kernel mode? It used to be. Someone recently suggested it should be, and I agreed.

By @blankx32 - 3 months
By @ThinkBeat - 3 months
All to me entirely unnecessary steps required to get the CPU into the correct mode is astounding.

They all seem to be steps needed for backwards compatibility.

Could Intel just provide a flag, command, to start in the right mode from the beginning.

Or just remove all the backwards compatibility.

I think I remember doing some research and ARM64 has some of the same issues.

Are there any CPUs that are designed from scratch as 64 bit it will not have any need for backwards compatibility and would enter the required state by default?

I guess sthat was the goal / design of Itanium?

are made to start in the desired 64 bit state from th

By @cf100clunk - 3 months
A laudable project. UEFI proponents here wondering why the person bothered to create a new bootloader approach might be missing the point of why people undertake such tasks as this. As the writer ends:

> Cool if you actually came along this far.

Cool indeed.

By @AstralStorm - 3 months
How old is UEFI now? Pity nobody deprecated BIOS alongside long mode.
By @ruslan - 3 months
Does this boot procedure work with EFI/UEFI ? If so, does UEFI supervisor emulate swithing real/protected/long modes or does it go in real hardware ?
By @amelius - 3 months
Is this any simpler on ARM?