Are PCIe devices designed to use in multi-platform and architectures?
Some PCIe devices contain "PCI Expansion ROM" or "PCI Option ROM", which stores programs to initialize the devices.
Now let's say I have a PCIe RAID controller, which is usually used on x86 machines. Now, if I plug it in a ARM machine, would the PCIe device failed to initialize? In other words, are most PCIe devices x86 specific?
Here's the issues with PCI option ROMs on ARM architecture:
- An option ROM written in x86 assembly won't be understandable by an ARM CPU.
- Option ROMs meant to be executed by PC BIOSes (such ROMs start with
0x55AAand have a couple of bytes for checksum and additional information) will assume PC architecture low-level details, such as VGA hardware, Intel CPU I/O ports, etc. - The whole BIOS concept was tightly wedded to the x86 CPU and PC architecture and never used for any ARM system.
Now ...
UEFI, BIOSes successor is meant to be used on CPUs other than x86.
The solution to the problems above was EFI byte code - a bytecode that would be interpreted by a runtime in the UEFI, making the code CPU independent.
ARM systems using UEFI are relatively new (the Surface RT might even be the only such system). Most ARM systems use CFE, U-Boot, or other boot firmware that don't work like PC BIOSes.
Now, if I plug it in a ARM machine, would the PCIe device failed to initialize?
You wouldn't even have a chance unless the ARM system was using UEFI. If it was, your system would probably hang on boot. EBC is not widely used in boot ROM firmware.
While the boot ROM wouldn't work, an OS that later boots would still recognize and be able to use the hardware just fine.
What does a boot ROM do?
The old pre-UEFI BIOS implemented an API through the x86 interrupt mechanism. Your program would have to set various x86 registers as parameters, then issue an x86 INT instruction.
INT causes the x86 CPU to look up an address in a table, and then transfers control to it (this is called a software interrupt - hardware can cause this to happen by talking to an interrupt controller also connected to the CPU).
Before processing option ROMs, the BIOS populates this table to various addresses that go back into the BIOS and perform API functions.
MS-DOS uses table extensively, relying on the BIOS for its original function - a Basic Input/Output System. Other operating systems don't use BIOS calls once they have control, they use their own drivers and mechanisms for driving hardware.
Since this interrupt table is in RAM, so it can be modified. Option ROMs could "hook" into the interrupt table - overwriting a specific interrupt's address to something in the ROM - and make it so BIOS API calls go to the option ROM first.
One BIOS API call that the BIOS uses itself is 13h - this call reads a sector off of a disk device. It's required to load sector 0 off of a hard drive to boot an OS (even MS-DOS).
BIOS knows how to talk to floppy and IDE devices but nothing else. A SCSI card would have an option ROM that would rewrite or "hook" 13h - and that made it possible to boot off of a SCSI drive. If the operating system is MS-DOS then MS-DOS could work with the SCSI drive since it would use 13h for disk operations.
Network booting is another situation where option ROMs are used.
If so, is it possible that the drivers could be designed to take care of this instead?
Yes, and they do. BIOS option ROMs really only support booting an OS and optionally a configuration menu (the "Press Ctrl-A to enter RAID configuration" is from the Option ROM and you see it at the point the BIOS calls its initialization code).
IIRC Linux takes care of enumerating devices again, and will pretty much ignore information from the x86 BIOS
Windows does that too. x86 BIOS (and x86 real mode) hung around as long as it did for MS-DOS support.
Most PCIe devices that have on-board firmware are x86 specific.
The on-board firmware is designed to work together with an Intel compatible environment.
There are devices made for other architectures. Mainly GPU, storage/raid and network cards. Some of these even allow flashing the firmware to change from one architecture to the other. Others are dual-firmware and can switch between architectures as needed.
I have even seen some raid-controllers that could be loaded (at boot-time from the UEFI environment) with the appropriate firmware for the architecture it was placed in.
Most of these are data-center grade and very expensive. Not something the average user will ever encounter in the wild.
For devices without on-board firmware (or better said: On-board firmware that doesn't interact with the host system) it is possible they work in whatever architecture that has drivers for them.