UEFI-Only Support for AMD Radeon RX 9000 Series Graphics and Later
amd.com
amd.com
> 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-...
I 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...
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.
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.
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?
> 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-...
Some related discussion: http://www.vogons.org/viewtopic.php?t=81748