Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a BIOS bootloader for 64-bit mode from scratch

thasso.xyz

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#21

Post by jasaldivara »

livrem wrote: post #10
deaddodo wrote: post #3

Earlier quoted context omitted.

BIOS is deprecated. All of its functionality on new motherboards is basically emulated via the UEFI; and it's certainly not being extended upon. Deprecated doesn't mean deleted, it just means "no longer updated/developed with a goal towards removal".

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

> I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

Not sure why would you want a single-process OS on modern hardware, but there are some alternatives that run much less things on the background than regular Linux: Haiku, FreeBSD, NetBSD, OpenBSD, or some lightweight non-glibc, non-systemd Linux-based like Adelie or Alpine.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#22

Post by rwmj »

livrem wrote: post #10
deaddodo wrote: post #3

Earlier quoted context omitted.

BIOS is deprecated. All of its functionality on new motherboards is basically emulated via the UEFI; and it's certainly not being extended upon. Deprecated doesn't mean deleted, it just means "no longer updated/developed with a goal towards removal".

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

What's the reason why FreeDOS can't use the CSM (the BIOS compatibility mode of UEFI)?

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#24

Post by EvanAnderson »

rwmj wrote: post #22
livrem wrote: post #10

Earlier quoted context omitted.

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

What's the reason why FreeDOS can't use the CSM (the BIOS compatibility mode of UEFI)?

AFAIK it can. I believe some UEFI implementations don't have CSM.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#25

Post by surajrmal »

khaledh wrote: post #13
ruslan wrote: post #9

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 ?

No. UEFI firmware creates a completely different environment for a UEFI bootloader than the legacy BIOS environment (real-address mode). The UEFI firmware enters 64-bit long mode directly on modern systems, and sets up a flat memory model GDT, as well as identity-mapped paging. I've written about creating a UEFI bootloader (for my hobby OS) here: https://0xc0ffee.netlify.app/osdev/05-bootloader-p1.html

I thought many UEFI implementations support legacy bios mode as well. Or well they used to.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#26

Post by rcxdude »

hyperman1 wrote: post #18

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 .

Probably for more robust backwards compatibility with software that might assume a given value for or write to the reserved bits. The assignment of bits to registers like this in the hardware is pretty arbitrary, there's not really any cost to using the higher bits

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#28

Post by the_panopticon »

surajrmal wrote: post #25
khaledh wrote: post #13

Earlier quoted context omitted.

No. UEFI firmware creates a completely different environment for a UEFI bootloader than the legacy BIOS environment (real-address mode). The UEFI firmware enters 64-bit long mode directly on modern systems, and sets up a flat memory model GDT, as well as identity-mapped paging. I've written about creating a UEFI bootloader (for my hobby OS) here: https://0xc0ffee.netlify.app/osdev/05-bootloader-p1.html

I thought many UEFI implementations support legacy bios mode as well. Or well they used to.

There is still support for CSM in the open source https://github.com/tianocore/tianocore.github.io/wiki/Compat... and even nice projects like https://github.com/coreboot/seabiosto fabricate the CSM16 binary, but many vendors have stopped validating this path, including production of legacy BIOS option roms for adapters (net, gfx, etc) https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020. I still believe CSP's maintain some of this support in their hypervisors' guest firmware for legacy OS binaries/ISO boot support? Also since Windows requires UEFI Secure boot enabled by default and CSM has to be disabled for the UEFI secure boot path, this is another reason legacy BIOS boot isn't exercised so much these days. We could have added legacy oroms hashes to UEFI Secure boot implementations https://patents.google.com/patent/US8694761B2/en, too, but again folks pushed back in their zeal to remove legacy BIOS overall. We didn't add the CSM spec https://www.intel.com/content/dam/www/public/us/en/documents... to the PI https://uefi.org/specs/PI/1.8A/ since folks were hoping UEFI would remove the need for CSM. I still remember being challenged in the early 2000's by a long-time BIOS mgr at Intel "Is removing legacy a good idea with EFI? You know, we're really at legacy."

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#29

Post by monocasa »

rcxdude wrote: post #26
hyperman1 wrote: post #18

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 .

Probably for more robust backwards compatibility with software that might assume a given value for or write to the reserved bits. The assignment of bits to registers like this in the hardware is pretty arbitrary, there's not really any cost to using the higher bits

Particularly AMD made the 64 bit extension without any real input from Intel and didn't want to use any bits that would later conflict with a bit Intel might use in CR0. So a brand new register was in order.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#30

Post by rep_lodsb »

rcxdude wrote: post #26
hyperman1 wrote: post #18

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 .

Probably for more robust backwards compatibility with software that might assume a given value for or write to the reserved bits. The assignment of bits to registers like this in the hardware is pretty arbitrary, there's not really any cost to using the higher bits

The flag register layout is another case of extreme backwards compatibility - its lower bits have the same definitions they had on the 8-bit 8080, even the same fixed values:

Sign : Zero : always '0' : AuxCarry : always '0' : Parity : always '1' : Carry

(the parity flag came all the way from the 8008 / Datapoint 2200[1], and is the inverted XOR of the result's lower 8 bits; aux carry is the carry out of bit 3, used for BCD arithmetic)

Flag bit 15 has also stayed reserved, except at one time it was used by the NEC Vxx chips for their 8080 compatibility mode. That feature had to be first unlocked by executing a special instruction, because there is code out there that loads the entire (16 bit) flag register with 0000 or FFFF. With the mode bit unlocked, that would inadvertently switch the CPU to running a completely different set of opcodes!

[1] https://www.righto.com/2023/08/datapoint-to-8086.html

Post reply on HN