4 ms·
Nowadays, I would recommend not using BIOS booting. Modern machines with UEFI firmware only emulate BIOS anyway, for backwards compatibility with old bootloader
by a-priori 5y ago
Nowadays, I would recommend not using BIOS booting. Modern machines with UEFI firmware only emulate BIOS anyway, for backwards compatibility with old bootloaders.
UEFI gives you a much nicer initial environment — it's already in 64-bit long mode, for example, unlike BIOS which drops you into 8-bit real mode, with a maximum of one sector in which to perform all the gymnastics you need to do to load the rest of your program and switch to _at least_ 32-bit protected mode (notice how this PDF doesn't even go to 64-bit long mode).
UEFI also gives you better, easier to use boot facilities than BIOS: you can access a memory map, read from the boot file system, switch video modes, and even access network drivers. And you can access all this from long mode, unlike BIOS which only works in real mode. Then once you've booted you can take over the system by exiting the boot services, and have full control over the system just like you want for making an operating system.
- kevin_thibedeau 5y agoBIOS boot is necessary for PCI cards with extension ROMs.
- a-priori 5y agoI suppose it depends what you're going for, but in general I don't think being able to fully support some very old PCI devices should be the determining factor.
- emteycz 5y agoThat depends only on their own project goals. Retro computing is a thing too.
- a-priori 5y agoYes of course. If your goals are retro computing, yes by all means go ahead and use retro technology. That's my point though: today, BIOS is retro technology.
- emteycz 5y agoIt's also good for learning. But I agree that most of today's basic OS dev learning should rather be done with UEFI and/or Virtio.
- convolvatron 5y agois that even still a thing?
- kevin_thibedeau 5y agoI have one in a Ryzen system.
- khaledh 5y agoIf anyone is interested, I have a couple of implementations of booting under UEFI and getting a bunch of info about the system (don't expect a functioning system, they just boot and dump some info): Nim: https://github.com/khaledh/axiom https://github.com/khaledh/axiom Zig: https://github.com/khaledh/axiom-zig https://github.com/khaledh/axiom-zig (this one goes into depth in disassembling ACPI DSDT bytecode)
- javajosh 5y agoYou sound very knowledgable about UEFI - it is intimidating since the spec is so big. It also...concerns me that so much code is running prior to my own, even if it is for a good purpose. I get it that CPU mode selection and boot device intitialization isn't something most programmers want to deal with, but doesn't putting it in UEFI firmware put it out of reach of most programmers? Should we not aim to put as little as possible into firmware?
- a-priori 5y agoFirst off I don't recommend implementing the specification from scratch. It is big, and there are implementations already in various languages: for C you can use GNU-UEFI, for example, Rust has uefi-rs, and Zig has support in its standard library. These take care of the fiddly details of interacting with the UEFI firmware's services. There's tutorial type articles for these around: for C there's https://wiki.osdev.org/UEFI_App_Bare_Bones https://wiki.osdev.org/UEFI_App_Bare_Bones, for Rust there's this template https://github.com/rust-osdev/uefi-rs/tree/main/template https://github.com/rust-osdev/uefi-rs/tree/main/template and the crate's documentation. I don't think the role of firmware requires it to be minimal. It's to provide a consistent boot environment on different hardware, and to provide useful services to the program. Even BIOS-based machines have significant amounts of code that run before they jump to the boot sector, so while UEFI is definitely more sophisticated I don't really see this as a drawback to it.
- glouwbug 5y agoIf you're worried about pre-OS code you will not believe what is running when your OS is running