Os dispositivos PCIe são projetados para uso em arquiteturas e multiplataformas?

Question 1

Aqui estão os problemas com ROMs de opção PCI na arquitetura ARM:

Uma ROM opcional escrita em assembly x86 não será compreensível por uma CPU ARM.
ROMs opcionais destinadas a serem executadas por BIOSes de PC (tais ROMs começam 0x55AAe possuem alguns bytes para soma de verificação e informações adicionais) assumirão detalhes de baixo nível da arquitetura do PC, como hardware VGA, portas de E/S de CPU Intel, etc.
Todo o conceito de BIOS estava intimamente ligado à CPU x86 e à arquitetura do PC e nunca foi usado em nenhum sistema ARM.

Agora ...

UEFI, sucessor do BIOS, deve ser usado em CPUs diferentes de x86.
A solução para os problemas acima foiCódigo de byte EFI- um bytecode que seria interpretado por um runtime na UEFI, tornando o código independente da CPU.
Os sistemas ARM que usam UEFI são relativamente novos (o Surface RT pode até ser o único sistema desse tipo). A maioria dos sistemas ARM usa CFE, U-Boot ou outro firmware de inicialização que não funciona como BIOS de PC.

Agora, se eu conectá-lo a uma máquina ARM, o dispositivo PCIe não conseguirá inicializar?

Você nem teria chance, a menos que o sistema ARM estivesse usando UEFI. Se fosse, seu sistema provavelmente travaria na inicialização. O EBC não é amplamente utilizado no firmware da ROM de inicialização.

Embora a ROM de inicialização não funcionasse, um sistema operacional que inicializasse posteriormente ainda reconheceria e seria capaz de usar o hardware perfeitamente.

O que uma ROM de inicialização faz?

O antigo BIOS pré-UEFI implementava uma API por meio do mecanismo de interrupção x86. Seu programa teria que definir vários registros x86 como parâmetros e, em seguida, emitir uma INTinstrução x86.

INTfaz com que a CPU x86 procure um endereço em uma tabela e, em seguida, transfira o controle para ele (isso é chamado deinterrupção de software- o hardware pode fazer com que isso aconteça conversando com um controlador de interrupção também conectado à CPU).

Antes de processar ROMs de opção, o BIOS preenche esta tabela com vários endereços que retornam ao BIOS e executam funções de API.

O MS-DOS usa tabelas extensivamente, contando com o BIOS para sua função original - umBasicEUentrada/ÓsaídaSsistema. Outros sistemas operacionais não usam chamadas de BIOS, uma vez que têm controle, eles usam seus próprios drivers e mecanismos para controlar o hardware.

Como esta tabela de interrupção está na RAM, ela pode ser modificada. ROMs de opção podem "enganchar" na tabela de interrupção - sobrescrevendo o endereço de uma interrupção específica para algo na ROM - e fazer com que as chamadas da API do BIOS vão primeiro para a ROM de opção.

Uma chamada de API do BIOS que o próprio BIOS usa é 13h: esta chamada lê um setor de um dispositivo de disco. É necessário carregar o setor 0 de um disco rígido para inicializar um sistema operacional (até mesmo MS-DOS).

O BIOS sabe como se comunicar com dispositivos de disquete e IDE, mas nada mais. Uma placa SCSI teria uma ROM opcional que reescreveria ou "engancharia" 13h- e isso tornaria possível inicializar a partir de uma unidade SCSI. Se o sistema operacional for MS-DOS, o MS-DOS poderá funcionar com a unidade SCSI, pois seria usado 13hpara operações de disco.

A inicialização pela rede é outra situação em que ROMs opcionais são usados.

Em caso afirmativo, é possível que os drivers possam ser projetados para cuidar disso?

Sim, e eles fazem. As ROMs opcionais do BIOS realmente suportam apenas a inicialização de um sistema operacional e, opcionalmente, um menu de configuração (o "Pressione Ctrl-A para entrar na configuração RAID" é da ROM opcional e você o vê no momento em que o BIOS chama seu código de inicialização).

O IIRC Linux cuida da enumeração de dispositivos novamente e praticamente ignora as informações do BIOS x86

O Windows também faz isso. BIOS x86 (e modo real x86) durou tanto tempo quanto para suporte ao MS-DOS.

Answer

Aqui estão os problemas com ROMs de opção PCI na arquitetura ARM:

Uma ROM opcional escrita em assembly x86 não será compreensível por uma CPU ARM.
ROMs opcionais destinadas a serem executadas por BIOSes de PC (tais ROMs começam 0x55AAe possuem alguns bytes para soma de verificação e informações adicionais) assumirão detalhes de baixo nível da arquitetura do PC, como hardware VGA, portas de E/S de CPU Intel, etc.
Todo o conceito de BIOS estava intimamente ligado à CPU x86 e à arquitetura do PC e nunca foi usado em nenhum sistema ARM.

Agora ...

UEFI, sucessor do BIOS, deve ser usado em CPUs diferentes de x86.
A solução para os problemas acima foiCódigo de byte EFI- um bytecode que seria interpretado por um runtime na UEFI, tornando o código independente da CPU.
Os sistemas ARM que usam UEFI são relativamente novos (o Surface RT pode até ser o único sistema desse tipo). A maioria dos sistemas ARM usa CFE, U-Boot ou outro firmware de inicialização que não funciona como BIOS de PC.