VOGONS

Common searches


First post, by eton975

User metadata
Rank Newbie
Rank
Newbie

Link

Intel's dropping support for the UEFI Compatibility Support Module (also known as 'level 2 compatibility') for their new platforms come 2020. Come then, you'll be unable to natively boot from devices with a MBR partition table, which was the primary method to boot the system from BIOS. Curious (!) to see how this will affect things like older graphics cards and PCI/PCIe NICs that only (AFAIK?) have VGA BIOS support, and hook in to the system boot through interrupt capture.

Personally, I feel this isn't even trying to fix something that ain't broke, but rather, breaking what was already fixed with UEFI for little good reason. However, perhaps I'm underestimating the effort it takes to validate BIOS compatibility and peripheral emulation on new hardware...

Reply 1 of 14, by Kubik

User metadata
Rank Member
Rank
Member

The fact Intel is dropping support doesn't mean that there will be no CSM support in BIOS. It's responsibility of the BIOS vendor (IBV) to provide CSM module, and board manufacturer can decide if they want it or not. The problem would be onboard graphics from Intel that won't get VGA BIOS, thus you'll need to use discrete VGA card. Other problem might be certain level of USB support in DOS, if Intel decides to remove the legacy emulation stuff.

Reply 2 of 14, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

I don't see this as a problem at all for new hardware as of 2020.

All new video cards already support UEFI and have for a couple years.

Unless you are wanting to run really old cards on a newer motherboard I don't see why this would be a problem at all.

Maybe it will force some companies to actually update their hardware/software that was never updated to work on newer stuff. Having to try to get 20+ year old software/hardware to work on newer systems because a company will not spend a few grand for a newer version is infuriating.

And then when they have to use an old OS that is not allowed on the network for security reasons they complain about it.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 3 of 14, by Zup

User metadata
Rank Oldbie
Rank
Oldbie

I'm worried about alternate OSs and legacy hardware.

- DOS is still useful for some things, like HDD tests and BIOS flashing on some devices.
- There are some bootable tools (are Memtest and Memtest + still developed?) that doesn't fully support UEFI, or does not support it at all.
- Some flavours of Linux don't fully support UEFI. I'm thinking about secure booting and (although the link does not say anything about it) maybe they'll force it.
- Hiren's Boot CD (not updated since a long time, but still useful) and Ultimate Boot CD... well, they won't boot.
- What about older/legacy cards with BIOS? Think about a business that (for some reason) needs to connect an old (SCSI of FC) disk array to a newer computer. Those systems use HBAs with their own BIOS... will they work in a non-legacy UEFI environment?

I have traveled across the universe and through the years to find Her.
Sometimes going all the way is just a start...

I'm selling some stuff!

Reply 4 of 14, by eL_PuSHeR

User metadata
Rank l33t++
Rank
l33t++

I am worried too because I don't like UEFI, no matter how marketing tries to sell it to us.

Intel i7 5960X
Gigabye GA-X99-Gaming 5
8 GB DDR4 (2100)
8 GB GeForce GTX 1070 G1 Gaming (Gigabyte)

Reply 5 of 14, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Oh my, 2020, that's in about two years already. 🙁 In worst case, I hope there will be BIOS emulators, at least.
Just like Boot Camp for booting Windows XP on an EFI-based Intel Mac or something similar to those
BIOS emulators/compatibility layers the Hackintosh scene used to use in the past years.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 14, by Kubik

User metadata
Rank Member
Rank
Member
Zup wrote:
I'm worried about alternate OSs and legacy hardware. […]
Show full quote

I'm worried about alternate OSs and legacy hardware.

- DOS is still useful for some things, like HDD tests and BIOS flashing on some devices.
- There are some bootable tools (are Memtest and Memtest + still developed?) that doesn't fully support UEFI, or does not support it at all.
- Some flavours of Linux don't fully support UEFI. I'm thinking about secure booting and (although the link does not say anything about it) maybe they'll force it.
- Hiren's Boot CD (not updated since a long time, but still useful) and Ultimate Boot CD... well, they won't boot.
- What about older/legacy cards with BIOS? Think about a business that (for some reason) needs to connect an old (SCSI of FC) disk array to a newer computer. Those systems use HBAs with their own BIOS... will they work in a non-legacy UEFI environment?

- Flash tools for EFI shell / Windows / Linux exist for many, many years already. Most HDD tests I've seen are Windows only.
- Memtest86 supports UEFI boot
- Secure Boot requires CSM to be disabled. I bet all major Linux distributions support UEFI boot.
- Hiren's Boot CD - yes, it's not updated since a long time. Maybe using tools from this century would help? 😀
- Connecting an old disc array to a newer computer isn't an issue. Booting from it would, but from my experience, those devices are used mostly as data storage. I am more like guessing that the problem will basically be newer system won't support corresponding bus (ISA, PCI, PCI-X etc.)

Reply 7 of 14, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
cyclone3d wrote:

All new video cards already support UEFI and have for a couple years.

Unless you are wanting to run really old cards on a newer motherboard I don't see why this would be a problem at all.

How new and how old cards are we talking about? Is it safe to assume all PCIe cards support UEFI?
Would it affect secondary cards (not used during boot) as well?

Reply 8 of 14, by eton975

User metadata
Rank Newbie
Rank
Newbie
Azarien wrote:
cyclone3d wrote:

All new video cards already support UEFI and have for a couple years.

Unless you are wanting to run really old cards on a newer motherboard I don't see why this would be a problem at all.

How new and how old cards are we talking about? Is it safe to assume all PCIe cards support UEFI?
Would it affect secondary cards (not used during boot) as well?

No, it's definitely not safe. However, I believe most stuff since the GTX 600 series and AMD 7000 series -> 200 series support UEFI.

As for the other cards, potentially yes. A modern OS should(?) still be able to detect them with its drivers as long as they don't rely on asking the BIOS about what devices are present.

Last edited by eton975 on 2017-12-03, 05:40. Edited 2 times in total.

Reply 9 of 14, by Kubik

User metadata
Rank Member
Rank
Member
eton975 wrote:

A modern OS should(?) still be able to detect them with its drivers if they don't rely on asking the BIOS about what devices are present.

Detecting and configuring a device is a feature of PCI / PCI-X / PCIe since the very beginning.

Reply 10 of 14, by Jade Falcon

User metadata
Rank BANNED
Rank
BANNED
eL_PuSHeR wrote:

I am worried too because I don't like UEFI, no matter how marketing tries to sell it to us.

UEFI is ok with legacy bios support. But the damn crappy UI's they put on alot of boards makes me pull out my hair.

Reply 11 of 14, by eton975

User metadata
Rank Newbie
Rank
Newbie
Kubik wrote:
eton975 wrote:

A modern OS should(?) still be able to detect them with its drivers if they don't rely on asking the BIOS about what devices are present.

Detecting and configuring a device is a feature of PCI / PCI-X / PCIe since the very beginning.

For PCI, AFAIK not necessarily. Plenty of PCI cards I know use Option ROMs that use interrupts 18h and 19h (25th and 26th interrupts, counting 0) and don't work properly otherwise.

Not sure about PCI-X and PCIe cards though.

Reply 12 of 14, by Jo22

User metadata
Rank l33t++
Rank
l33t++

In the future, could good old SeaBIOS be used as an alternative CSM, perhaps ?

The Wikipedia article of SeaBIOS mentions "SeaBIOS as a Compatibility Support Module (CSM) for
Unified Extensible Firmware Interface (UEFI) and Open Virtual Machine Firmware (OVMF)
".

Unfortunately, I don't know what to make of that. But if UEFI uses an standardized API/ABI,
couldn't a generic version of SeaBIOS run atop of UEFI and provide some degree of backwards compatibility ?

Please forgive my ignorance, but I know very little about UEFI's internals.
Maybe I get it wrong and the current CSM is implemented as a payload that works on its own.

Edit: Seems removal of CSM may only be the beginning. Other core components from the PC/XT/AT eras *could* be next.
I just hope that x87 and the classic 8086 registers will stay for a while, so VMs can use them in hardware-assisted virtualization, at least.

Also, I hope that AMD, VIA or mainboard makers in general, won't follow intel's approach so quickly,
now that FreeDOS and OS/2 (ArcaOS) are making some progress..

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 13 of 14, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Just found something interesting. Over ten years ago, researchers from IBM were working on a BIOS emulator for EFI-based systems.
http://www.insanelymac.com/forum/topic/11953- … ulator-for-efi/

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 14 of 14, by Kubik

User metadata
Rank Member
Rank
Member
eton975 wrote:
Kubik wrote:
eton975 wrote:

A modern OS should(?) still be able to detect them with its drivers if they don't rely on asking the BIOS about what devices are present.

Detecting and configuring a device is a feature of PCI / PCI-X / PCIe since the very beginning.

For PCI, AFAIK not necessarily. Plenty of PCI cards I know use Option ROMs that use interrupts 18h and 19h (25th and 26th interrupts, counting 0) and don't work properly otherwise.

Not sure about PCI-X and PCIe cards though.

PCI and PCI-X are the same from software point of view. PCIe is backward compatible, but the configuration space is extended to 4KB, where first 256 bytes are accesible via the same mechanism as PCI / PCI-X, and whole 4KB are accessible only via memory mapped I/O.

Basic card configuration is typically done by BIOS. BIOS allocates resources for the card (I/O, memory mapped, IRQ). Option ROM can configure additional features, detect attached drives, install legacy handlers (interrupt 13h, 18h, 19h etc), eventually provide some sort of setup program etc.

Anyway, the point is that mechanism of detecting and configuring the card is part of PCI specification.