¿Los dispositivos PCIe están diseñados para usarse en arquitecturas y plataformas múltiples?

Question 1

Estos son los problemas con las ROM de opción PCI en la arquitectura ARM:

Una ROM opcional escrita en ensamblaje x86 no será comprensible para una CPU ARM.
Las ROM opcionales destinadas a ser ejecutadas por BIOS de PC (dichas ROM comienzan con 0x55AAy tienen un par de bytes para suma de comprobación e información adicional) asumirán detalles de bajo nivel de la arquitectura de PC, como hardware VGA, puertos de E/S de CPU Intel, etc.
Todo el concepto de BIOS estaba estrechamente ligado a la arquitectura de CPU y PC x86 y nunca se usó para ningún sistema ARM.

Ahora ...

UEFI, el sucesor del BIOS, está diseñado para usarse en CPU distintas a x86.
La solución a los problemas anteriores fuecódigo de bytes EFI- un código de bytes que sería interpretado por un tiempo de ejecución en UEFI, haciendo que el código sea independiente de la CPU.
Los sistemas ARM que utilizan UEFI son relativamente nuevos (Surface RT podría incluso ser el único sistema de este tipo). La mayoría de los sistemas ARM utilizan CFE, U-Boot u otro firmware de arranque que no funciona como el BIOS de una PC.

Ahora bien, si lo conecto a una máquina ARM, ¿no se inicializaría el dispositivo PCIe?

Ni siquiera tendrías ninguna posibilidad a menos que el sistema ARM estuviera usando UEFI. Si así fuera, su sistema probablemente se bloquearía al arrancar. EBC no se utiliza mucho en el firmware de la ROM de arranque.

Si bien la ROM de arranque no funcionaría, un sistema operativo que se inicie más tarde aún reconocería y podría usar el hardware sin problemas.

¿Qué hace una ROM de arranque?

El antiguo BIOS anterior a UEFI implementaba una API a través del mecanismo de interrupción x86. Su programa tendría que configurar varios registros x86 como parámetros y luego emitir una INTinstrucción x86.

INThace que la CPU x86 busque una dirección en una tabla y luego le transfiera el control (esto se llama direccióninterrupción de software(el hardware puede provocar que esto suceda hablando con un controlador de interrupciones también conectado a la CPU).

Antes de procesar las ROM de opción, el BIOS completa esta tabla con varias direcciones que regresan al BIOS y realizan funciones API.

MS-DOS utiliza ampliamente la tabla, confiando en el BIOS para su función original: unBasicoIentrada/ohsalidaSsistema. Otros sistemas operativos no usan llamadas al BIOS una vez que tienen el control, usan sus propios controladores y mecanismos para controlar el hardware.

Dado que esta tabla de interrupciones está en la RAM, se puede modificar. Las ROM de opción podrían "conectarse" a la tabla de interrupciones (sobrescribiendo la dirección de una interrupción específica en algo en la ROM) y hacer que las llamadas a la API del BIOS vayan primero a la ROM de opción.

Una llamada a la API del BIOS que el BIOS utiliza es 13h: esta llamada lee un sector de un dispositivo de disco. Es necesario cargar el sector 0 de un disco duro para iniciar un sistema operativo (incluso MS-DOS).

BIOS sabe cómo comunicarse con dispositivos IDE y disquetes, pero nada más. Una tarjeta SCSI tendría una ROM opcional que se reescribiría o "engancharía" 13hy eso haría posible arrancar desde una unidad SCSI. Si el sistema operativo es MS-DOS, entonces MS-DOS podría funcionar con la unidad SCSI, ya que se utilizaría 13hpara operaciones de disco.

El arranque en red es otra situación en la que se utilizan ROM opcionales.

Si es así, ¿es posible que los controladores puedan diseñarse para encargarse de esto?

Sí, y lo hacen. Las ROM de opción de BIOS en realidad solo admiten el inicio de un sistema operativo y, opcionalmente, un menú de configuración (el mensaje "Presione Ctrl-A para ingresar a la configuración RAID" proviene de la ROM de opción y lo ve en el punto en que el BIOS llama a su código de inicialización).

IIRC Linux se encarga de enumerar los dispositivos nuevamente y prácticamente ignorará la información del BIOS x86

Windows también hace eso. El BIOS x86 (y el modo real x86) se mantuvo tanto tiempo como lo hizo para la compatibilidad con MS-DOS.

Answer

Estos son los problemas con las ROM de opción PCI en la arquitectura ARM:

Una ROM opcional escrita en ensamblaje x86 no será comprensible para una CPU ARM.
Las ROM opcionales destinadas a ser ejecutadas por BIOS de PC (dichas ROM comienzan con 0x55AAy tienen un par de bytes para suma de comprobación e información adicional) asumirán detalles de bajo nivel de la arquitectura de PC, como hardware VGA, puertos de E/S de CPU Intel, etc.
Todo el concepto de BIOS estaba estrechamente ligado a la arquitectura de CPU y PC x86 y nunca se usó para ningún sistema ARM.

Ahora ...

UEFI, el sucesor del BIOS, está diseñado para usarse en CPU distintas a x86.
La solución a los problemas anteriores fuecódigo de bytes EFI- un código de bytes que sería interpretado por un tiempo de ejecución en UEFI, haciendo que el código sea independiente de la CPU.
Los sistemas ARM que utilizan UEFI son relativamente nuevos (Surface RT podría incluso ser el único sistema de este tipo). La mayoría de los sistemas ARM utilizan CFE, U-Boot u otro firmware de arranque que no funciona como el BIOS de una PC.