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$.
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,"
> 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.
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?
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.)
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.
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.
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.
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.
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.
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.
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.
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.
> Let's make one thing clear, this does not mean that RDNA 4 (and future) GPUs will not boot on older systems. AMD simply does not guarantee an optimal experience, stating that your GPU could be missing out on necessary features such as Smart Access Memory.
> Let's make one thing clear, this does not mean that RDNA 4 (and future) GPUs will not boot on older systems. AMD simply does not guarantee an optimal experience, stating that your GPU could be missing out on necessary features such as Smart Access Memory.
And possibly compatibility or crashing issues, they continue on to say.
BAR resizing (which is all that Smart Access Memory means, as far as I can tell) is just done by the kernel writing some value to the right field in PCI configuration space, why would it require firmware support (and if so, why would CSM preclude that support)?
There are a lot of features that Intel has decided are "supposed" to be enabled by firmware and Windows just goes along with that. AMD copies Intel for compatibility of course.
Typically the system firmware sets up the PCI address assignments.
An OS can reassign addresses, but the firmware is expected to know things about the memory (and i/o) map in the system. If there's some device hard wired to specific memory or i/o addresses, the firmware (should) know not to give that address to any pci devices, but the OS might not know. Or if the system skipped some address pins, again similar thing.
That doesn't really preclude CSM support, but mapping devices outside of 32-bit space is sometimes tied to CSM and a large BAR probably won't fit in 32-bit space. Neither of theae things really need to be tied to CSM, but I guess the assumption is an OS that can use 64-bit device addresses would have an uefi loader.
Just to be clear, it is not the Base Address Register (BAR) itself that gets resized, it is the mapped region of video memory which is pointed to by the BAR.
When I think of the BAR, I think of how the OS uses it. Read the address (32 or 64 bits as the case may be), write the flag so the card is not active, write all 1s to the BAR, read the address which tells you how big the mapped region is (the adress will be 0s for bits that are within the mapped region), write back the original address, and finally re-enable the card.
Resizable bar doesn't change the bar from a 32-bit bar to a 64-bit bar, it just changes the number of bits used in the mapped region.
But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.
As I mentioned in my first reply, the firmware is expected to have complete knowledge of the address mapping of the system, and the OS isn't.
There are lots of ways for the firmware to convey information about the address map to the OS, but it may not always be complete. Mapping two devices to the same address is a recipe for trouble.
That's not to say an OS can't change these things. PCI/PCIe hotplug rely on the OS to set the BAR address for newly connected devices. And that may require rearranging existing device mappings so that things fit. And so, OSes that are capable of hotplug can often do address reallocation for all the devices, but firmware would need to have allocated the devices used to boot the OS already, and you may as well use those if they're there, right?
Given that there's open-source drivers available, and even some hardware documentation, I wonder how long it'll be before the retrocomputing community comes up with a replacement VBIOS for GPUs which don't have one.
49 comments
[ 3.6 ms ] story [ 101 ms ] threadI was a BIOS holdout, and even I switched to pure-UEFI _years_ ago.
Two are from 2010, one from 2008, one from 1996.
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,"
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.
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.
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?
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.)
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
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...
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.
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/
Heads isn't BIOS or UEFI.
What does it get me? A fancier "bios" menu that supports a mouse. Big whoop.
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.
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
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.
And you're not "even", most users don't even only about such a choice
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.
> Let's make one thing clear, this does not mean that RDNA 4 (and future) GPUs will not boot on older systems. AMD simply does not guarantee an optimal experience, stating that your GPU could be missing out on necessary features such as Smart Access Memory.
https://www.tomshardware.com/pc-components/gpus/amds-new-rx-...
> Let's make one thing clear, this does not mean that RDNA 4 (and future) GPUs will not boot on older systems. AMD simply does not guarantee an optimal experience, stating that your GPU could be missing out on necessary features such as Smart Access Memory.
And possibly compatibility or crashing issues, they continue on to say.
https://www.tomshardware.com/pc-components/gpus/amds-new-rx-...
An OS can reassign addresses, but the firmware is expected to know things about the memory (and i/o) map in the system. If there's some device hard wired to specific memory or i/o addresses, the firmware (should) know not to give that address to any pci devices, but the OS might not know. Or if the system skipped some address pins, again similar thing.
That doesn't really preclude CSM support, but mapping devices outside of 32-bit space is sometimes tied to CSM and a large BAR probably won't fit in 32-bit space. Neither of theae things really need to be tied to CSM, but I guess the assumption is an OS that can use 64-bit device addresses would have an uefi loader.
When I think of the BAR, I think of how the OS uses it. Read the address (32 or 64 bits as the case may be), write the flag so the card is not active, write all 1s to the BAR, read the address which tells you how big the mapped region is (the adress will be 0s for bits that are within the mapped region), write back the original address, and finally re-enable the card.
Resizable bar doesn't change the bar from a 32-bit bar to a 64-bit bar, it just changes the number of bits used in the mapped region.
But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.
Is there some reason the kernel can't remap devices after the fact? Why is the firmware involved in this once the kernel takes over?
There are lots of ways for the firmware to convey information about the address map to the OS, but it may not always be complete. Mapping two devices to the same address is a recipe for trouble.
That's not to say an OS can't change these things. PCI/PCIe hotplug rely on the OS to set the BAR address for newly connected devices. And that may require rearranging existing device mappings so that things fit. And so, OSes that are capable of hotplug can often do address reallocation for all the devices, but firmware would need to have allocated the devices used to boot the OS already, and you may as well use those if they're there, right?
Some related discussion: http://www.vogons.org/viewtopic.php?t=81748