They are for option ROMs...

Can be for network boot or any other option ROM. Like XTIDE, Y2K Patch, boot loaders like Plop, etc.

It's extremely common to put XTIDE in a NIC boot prom socket.

Option ROMs are just software the BIOS runs at boot time after the POST sequence. They usually extend BIOS functionality in some way.

As for why a NIC has one;

PXE.

Pre-eXecution Envirionment.

It's a kind of combination TCP/IP stack and boot loader, used to pull small disk images from off the network, then boot from them, to allow network boot.

demiurge wrote on 2024-06-03, 02:44:

Is the OPROM code specific to the chipset and therefore has to be specific to the card?

For the intended purpose - yes (just like different cards need different drivers in "normal operating systems"), though as others have said it's just a combo ethernet + general purpose rom card with the two features mostly independent

In fact, just like the XTIDE configurator shows for a disk controller, a netboot option rom would need a comparably large number of variants - not only in core drivers but also in address range (jumpers) and protocol (no domination of tcp/ip + dhcp with additional attributes + tftp, back then!) - so there's a reason for not including one, secondary to cost cutting of course 😀

wierd_w wrote on 2024-06-03, 04:05:

As for why a NIC has one; […]
Show full quote

As for why a NIC has one;

PXE.

Pre-eXecution Envirionment.

It's a kind of combination TCP/IP stack and boot loader, used to pull small disk images from off the network, then boot from them, to allow network boot.

I thought PXE was a specific thing part of a modern BIOS boot sequence. But I get the idea, I was just asking if it was the same concept.

demiurge wrote on 2024-06-03, 11:02:

wierd_w wrote on 2024-06-03, 04:05:

As for why a NIC has one; […]
Show full quote

As for why a NIC has one;

PXE.

Pre-eXecution Envirionment.

It's a kind of combination TCP/IP stack and boot loader, used to pull small disk images from off the network, then boot from them, to allow network boot.

I thought PXE was a specific thing part of a modern BIOS boot sequence. But I get the idea, I was just asking if it was the same concept.

Nope. Several (now old, and mature) projects exist to enable PXE booting on such cards, like EtherBoot.

http://etherboot.org/wiki/

(etherboot is even old enough to be period correct!)

Usually, the boot proms were very card specific, and many even used different kinds of transport.

Novell used such a solution in its Netware ecosystem, called RPL.

https://en.m.wikipedia.org/wiki/Remote_Initial_Program_Load

At the end of the day, it's JUST a 64kb option Rom.

Any 64kb option Rom can live there. The socket was just meant for bootstrapping over a network.

demiurge wrote on 2024-06-03, 11:02:

I thought PXE was a specific thing part of a modern BIOS boot sequence

At first it couldn't be, mainly because of the above reasons + "wtf is a network card anyway" 😀

Then various motherboards, especially on big brand PCs, started getting integrated ethernet, these can fit in the above or the next case depending on design and may even have, possibly hidden in a driver pack, a rom modding program

Then by the very late 90s ethernet + PXE became dominant, at this point it made sense (still for computers with integrated network) to include it out of the box, but while the code is physically in the main firmware chip it still uses option rom technology (which makes replacing it one of the easiest bios mods if you have the appropriate "private" tools, like MMTool for AMI)

Then, for reasons absolutely unrelated to M$'s dominant position and their Win8 certification standards, every brand switched to EFI overnight, one of which major advantages being having a truly modular firmware (with real drivers/utilities combined in the firmware and/or loaded from disk, and interacting in a cleaner way than shared tables and interrupt hook chains), so "the same but theoretically better" 😀

Amd of course many EFIs of the 2010s have decent BIOS emulation, so they probably also have a traditional PXE option ROM too!

demiurge wrote on 2024-06-03, 11:02:

wierd_w wrote on 2024-06-03, 04:05:

As for why a NIC has one; […]
Show full quote

As for why a NIC has one;

PXE.

Pre-eXecution Envirionment.

It's a kind of combination TCP/IP stack and boot loader, used to pull small disk images from off the network, then boot from them, to allow network boot.

I thought PXE was a specific thing part of a modern BIOS boot sequence. But I get the idea, I was just asking if it was the same concept.

Later BIOS just contain the (usually) intel PXE option ROM and execute it if you set boot to network in the BIOS config.

kingcake wrote on 2024-06-06, 05:45:

demiurge wrote on 2024-06-03, 11:02:

wierd_w wrote on 2024-06-03, 04:05:

As for why a NIC has one; […]
Show full quote

As for why a NIC has one;

PXE.

Pre-eXecution Envirionment.

It's a kind of combination TCP/IP stack and boot loader, used to pull small disk images from off the network, then boot from them, to allow network boot.

I thought PXE was a specific thing part of a modern BIOS boot sequence. But I get the idea, I was just asking if it was the same concept.

Later BIOS just contain the (usually) intel PXE option ROM and execute it if you set boot to network in the BIOS config.

I could be wrong, but I think there's also a historic reason for the socket.

Back in the 80s/90s, there had been various network protocols, not just Novell Netware and MS Lan Manager.

So a boot ROM had contained custom bootloaders which also had been programmed with a serial number and/or a station's ID.

So the server software could assign a station properly to the network.

Then there was the dongle situation.
Back in late 20th century, commercial software not seldomly shipped with a hardware dongle.

Such a dongle often shipped in form of a parallel port dongle, but it also existed as small ISA card or an ROM.

The ISA card flavor also was being used by emulators to hold the original ROMs of a given system (Atari ST, Mac).

This essentially was a licensing thing, there was no technical reason since a ROM file on a HDD was serving same purpose.

What also comes to mind is the "ROM" of the DBT-03 modem here (the "ROM" was more of a PAL/GAL chip).
It did contain the user ID and the telephone number of the closest gateway.
- The DBT-03 was an early smart modem (technology state of 1980) meant to dial into our national online service here (BTX).
It did the dialing sequence and the login on its own, if one of the serial port pins was shorted.

Edit:

Ryccardo wrote on 2024-06-06, 04:49:

Then, for reasons absolutely unrelated to M$'s dominant position and their Win8 certification standards, every brand switched to EFI overnight, one of which major advantages being having a truly modular firmware (with real drivers/utilities combined in the firmware and/or loaded from disk, and interacting in a cleaner way than shared tables and interrupt hook chains), so "the same but theoretically better" 😀

Sorry, if this is a bit off-topic but I think Open Firmware as found on Power Macs would have been better choice than EFI or UEFI.
It had a real command line built-in and was more mainframe-like, more professional.
UEFI is so.. consumer-oriented. 😑

https://en.wikipedia.org/wiki/Open_Firmware

But maybe that's just me. I've been always sort of an opponent to EFI.
Even before UEFI was out, I saw the flaws.
Biggest issue is that UEFI adds unnecessary complexity without any meaningful use.

It's no longer a monitor program or a firmware, but a miniature operating system (meaning it's fatter than Windows 3).
UEFI has the ability to lie to the operating system anytime it wishes, it can run malware behind the operating system's back and it can spy network traffic.
And no anti-virus program or firewall software can prevented this.

That's one of the reasons as to why the old BIOS was more trustworthy. It wasn't smart.
It didn't even have drivers or modules for the integrated hardware on the motherboard.
Everything it did was to assist the PC operating system.

In order to be secure, UEFI would require same level of security software as a real operating system.
It would need to download the latest security patches, need an antiviral software, need certificates etc.
But then, what do you need your host OS for anymore?

This is exactly why I was so upset/shocked about intels decision of deprecation of BIOS and the CSM.
Because it took away the only workaround to have a clean, secure environment.

I mean, just look at ATMs. They used to run on Windows 2k/XP and OS/2 for a reason (both BIOS based).
Running a fleet of ATMs under UEFI control
would literally invite hackers to find a weak spot in the code.
And since UEFI has driver modules for the integrated NIC on motherboard, it's very inviting.

Edit: Another treat were (or are) the Intel chipsets running on Minix 3.
They do essentially form a dedicated computer on the motherboard, outside of control of the CPU.
Such things compromise any concept of security.

https://www.zdnet.com/article/minix-intels-hi … erating-system/

Because, you're essentially dealing with foreign hardware in your own PC.
It's as if a remote-controlled keylogger is built directly into your keyboard. It can record key presses, but also simulate them on command.

Edit: I forgot to mention a scary little detail here.
Both the chipset and the NIC on motherboard are being connected to the standby power (5v?).
So they're always being powered even if the PC is switched off.
(The NIC needs that for its wake-on-LAN event feature.)

So even a seemingly harmless, powered-off PC on a random workplace could be part of a bot net or act as a control server for malware.
The activity LED on the network socket could be the only way of noticing what's actually going on.

Jo22 wrote on 2024-06-06, 06:14:

UEFI has the ability to lie to the operating system anytime it wishes, it can run malware behind the operating system's back and it can spy network traffic.
And no anti-virus program or firewall software can prevented this.

Lucky that hasn't already been abused, other than Gigabyte using it to install their bloatware on Windows without the user doing so. The bloatware was downloaded by https, but the certificates were never checked, so was MITM-able.

https://eclypsium.com/blog/supply-chain-risk- … enter-backdoor/

My motherboard? Yes, it was one with a backdoor. The only thing that perhaps saved me getting corporate malware was that this motherboard has only ever run Linux.

progman.exe wrote on 2024-06-06, 11:37:

Lucky that hasn't already been abused, other than Gigabyte using it to install their bloatware on Windows without the user doing […]
Show full quote

Jo22 wrote on 2024-06-06, 06:14:

UEFI has the ability to lie to the operating system anytime it wishes, it can run malware behind the operating system's back and it can spy network traffic.
And no anti-virus program or firewall software can prevented this.

Lucky that hasn't already been abused, other than Gigabyte using it to install their bloatware on Windows without the user doing so. The bloatware was downloaded by https, but the certificates were never checked, so was MITM-able.

https://eclypsium.com/blog/supply-chain-risk- … enter-backdoor/

My motherboard? Yes, it was one with a backdoor. The only thing that perhaps saved me getting corporate malware was that this motherboard has only ever run Linux.

Wow. Thanks for that blog article! It's a very interesting read! That it involves NT Native API, even, is even more thrilling.