Hacker News Reader

Comment by teach | Hacker News Reader

Honest question: who is still using BIOS (or I guess CSM mode) and why?

I was a BIOS holdout, and even I switched to pure-UEFI _years_ ago.

I used to use CSM mode because I didn't understand how UEFI worked, specifically the Boot Manager.

My Boot Manager always ended up full of old entries of OSes that I had already deleted, and it caused some issues. This was not a problem in compatibility mode.

But then I read an article [1] and learned how to manage the Boot Manager.

Then I made a video [2] summarizing what I learned from the article.

But to this day, I defend the point that UEFI is not a drop-in replacement for BIOS, because if you install and delete OSs frequently, you need to know how to manage the Boot Manager to avoid ending up with a mess.

[1] https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...

[2] https://www.youtube.com/watch?v=-V3VhP-MUwE

Nice, thank you! I stopped experimenting with OSes right around the time UEFI took over so I never would've known.

Laptops that use Coreboot with the SeaBIOS payload to load Linux are being produced today by privacy/security oriented vendors. Most of them have integrated graphics, but BIOS is certainly not dead yet.

Edit: Also Heads [1] secure boot firmware can use Linux in firmware to load the OS and does not need any UEFI services.

1. https://osresearch.net/

Coreboot can run tianocore just fine. I don't think my corebooted Chromebook even has BIOS.

Heads isn't BIOS or UEFI.

CSM is required for tools that aren't UEFI enabled. memtest86+ for example can't use a UEFI GOP and requires a BIOS capable VGA. Can't be used with a UEFI-only video card (e.g. recent ryzen igpu).

Also, there is still plenty of hardware out there that only comes with BIOS-capable option roms. These still require CSM if you want them to be be visible at boot.

My hobby OS runs in BIOS because I want to use VGA text mode. Some of my computers around the house boot in BIOS because it was easier at the time, and there's no benefit to UEFI for them (afaik), so why bother; especially if I've moved the disks around from machine to machine.

It's even easier to produce a hobby OS targeting UEFI these days; less direct ASM required (maybe not any?), and the firmware can provide lots of things for you, assuming you're willing to stay in boot services mode. Browsing https://uefi.org/specs/UEFI/2.10/index.html, I see console text mode, loadable modules, compression, networking... the list goes on.

Yeah, but most of those cool things go away when you leave boot services mode, and I think boot services also limits you to single core?

My hobby OS doesn't have that much assembly. My one asm file [1] is 888 lines, but there's a lot of lazy repetion for my interrupt and error handlers, so I can get the interrupt/error number as a parameter in the C function. If I was lazier and had interrupts go directly to c functions, there wouldn't be that much left in assembly: setting up the stack and stuff for C which isn't that much code, really, task switching bits that were too weird to write in C, stack setup for new threads, trampolines for starting the non-boot processors.

There's some inline assembly in the kernel too, but I don't think you'd be able to get rid of that.

[1] https://github.com/russor/crazierl/blob/main/kernel_src/star...

I don't think there's any particular reason for you to jump out of boot services mode if you're just having fun. Runtime mode means the firmware gives up control of devices etc, because you're meant to take over them.

As far as the rest of the cores go, I don't think UEFI has much to say about them; you're expected to start them yourself once you've switched to runtime mode, so I expect that means they're just hanging out before then, e.g. during boot services time... you could just start them then.

All of my PCs except an old MacBook Pro have a BIOS, not UEFI.

Two are from 2010, one from 2008, one from 1996.

Do you use a modern graphics card in any of them?

The main one, and the one I'm using now, has a Radeon Pro WX 5100 which is a Polaris card from about 8 years ago.

I have a 4070 plugged into an intel haswell era (2013?) as my personal desktop machine. it runs most midrange games pretty ok, although helldivers 2 (AAA title) is a bit of a dog even at low resolutions. For personal desktop tasks I haven't had much need to upgrade past that. Probably just about ready to buy a new motherboard/cpu combo for it for another dozen years or so.

Pretty sure most has well boards come with UEFI. At least my ivy ridge Z77 board at the time did. God, those were the days, one could buy a proper motherboard for like 80$.

They did use UEFI back then, but the BIOS CSM was on by default so it was pretty easy to accidentally end up taking the legacy boot path.

I dislike uefi because I have to install and update the boot loader into the motherboard instead of the motherboard/cpu just running what's on disk. Not portable in the slightest. Some hardware failure preventing boot? You need another system and OS ready to go or download and burn a usb boot disk. Somehow that works but I can't just do that for my m.2 disk.

What does it get me? A fancier "bios" menu that supports a mouse. Big whoop.

> I dislike uefi because I have to install and update the boot loader into the motherboard instead of the motherboard/cpu just running what's on disk. Not portable in the slightest.

UEFI by default also looks in the ESP (EFI System Partition) under /EFI/BOOT/BOOTX64.EFI for any PE binary (usually the bootloader). systemd-boot for example installs itself there when you ask it to and you don't have to register anything.

> What does it get me? A fancier "bios" menu that supports a mouse. Big whoop.

My compaq pentium 75 had bios setup that looked like windows 3. Mouse support in bios wasn't cool or necessary then, and it isn't now. :p

Sometimes the ability to boot an efi-capable image from any efi partition is useful. For example, I used it to install multiple operating systems (including Windows) without a flash drive — you simply create a sufficiently large efi partition on any disk in the system, unpack the iso on it, and pick the new option from the menu. Then wipe the partition when it's no longer needed.

It even works if you have only one disk — the firmware is supposed to support many efi partitions on the same disk, and although I'm sure some of them don't, I haven't personally seen any.

I use UEFI but I am going to be honest I kind of hate it. I miss the simplicity of BIOS, UEFI is so over-engineered.

UEFI might be too complex, but I think BIOS was too simple. I do not miss having to dd over the front of the disk to make it bootable; placing a file (or multiple! It's not exclusive!) on a FAT partition is so much lower stress.

I still see it used commonly for VMs.

Yeah, what's up with that? Like, I don't mind qemu defaulting to BIOS, but why is UEFI booting a VM so convoluted?

Just use Hyper-V. It does UEFI, TPM, GPU passthrough and partitioning and everything else you need by default /ms

People with old hardware abandoned by vendors, who don't provide new uefi drivers. "Why" - because that's how it was set up when they bought it

And you're not "even", most users don't even only about such a choice

It was only ~2 years ago that I switched. Kept using it for a long time because the boot disk came from an older PC and didn't want to reformat it.

I booted my arch Linux Kernel straight from UEFI 9 years ago :)

I have an old server motherboard that does not support UEFI. Otherwise it still runs fine.

I came here to ask why it matters to the GPU how the host boots. Does it need to load some drivers or firmware before the host OS? The only thing I found in the article was "... may lose access to important and necessary features of your motherboard,"

Resizable BAR (which doesn't exist on old pre-UEFI hardware anyway).

> I came here to ask why it matters to the GPU how the host boots. Does it need to load some drivers or firmware before the host OS?

Only if you want some display output before the host OS starts. Like maybe firmware menus, or boot prompts. Generally, this functionality is enabled by a ROM with code for the system firmware to call into: VGA BIOS for CSM and the UEFI GOP for UEFI.

I think all of the IBM video standards involve semi-fixed memory and i/o addresses, so a video card operating in CSM mode needs to listen on those addresses or CSM software is unlikely to work.

Yeah, boot menus and UEFI configuration as the sibling suggests.

This is actually a huge problem with DDR5 memory training. Since memory training must happen before the GPU is brought up, the screen stays blank for that duration (which can take several minutes). The only indication that it's happening is in debug LEDs if your motherboard has them.

The fact boot codes displays are getting pushed to always more expensive motherboards - and there is no standard way to get them otherwise - drives me crazy.

The economic tradeoff would be interesting.

How many good boards get RMA'd because they provide no feedback that you're in the middle of memory training, versus the $1 BOM addition to put a seven-segment display-- or hell, one of those 1" OLED modules-- on boards other than the $300+ "Autonomous Collective of Joystick Monkeys" X870E Torpedo Grenade ExplodyThingy Max?

> DDR5 memory training.

That makes sense. I also have a newer host that uses DDR5 RAM. The first time I powered it up, I thought it was not working. While I was sitting there trying to figure out what to try nest, It finally came up. It gets better with time (or BIOS updates.)

Reply on news.ycombinator.com