Por que os sistemas embarcados precisam da árvore de dispositivos, enquanto os PCs não precisam?

Question

Ao inicializar um kernel em um dispositivo embutido, você precisa fornecer uma árvore de dispositivos para o kernel do Linux, enquanto que inicializar um kernel em um pc x86 normal não requer uma árvore de dispositivos - por que?

Pelo que entendi, em um pc x86 o kernel "investiga" hardware (me corrija se eu estiver errado), então por que o kernel não pode testar o hardware e o sistema embarcado?

    

Answer 1

Os periféricos são conectados ao processador principal por meio de um barramento . Alguns protocolos de barramento suportam enumeração (também chamada de descoberta), ou seja, o processador principal pode perguntar “quais dispositivos estão conectados a este barramento?” E os dispositivos respondem com algumas informações sobre seu tipo, fabricante, modelo e configuração em um formato padronizado. Com essa informação, o sistema operacional pode relatar a lista de dispositivos disponíveis e decidir qual driver de dispositivo usar para cada um deles. Alguns protocolos de barramento não suportam enumeração, e então o processador principal não tem como descobrir quais dispositivos estão conectados além de adivinhar.

Todos os barramentos de PC modernos suportam enumeração, em particular PCI (o original, bem como suas extensões e sucessores, como o AGP e PCIe), sobre o qual a maioria dos periféricos internos são conectados, USB (todas as versões), sobre o qual a maioria dos periféricos externos são conectados, bem como Firewire , SCSI , todas as versões modernas de ATA / SATA , etc. As conexões modernas de monitores também suportam a descoberta do monitor conectado ( HDMI , DisplayPort , DVI , VGA com EDID ). Assim, em um PC, o sistema operacional pode descobrir os periféricos conectados enumerando o barramento PCI e enumerando o barramento USB quando encontrar um controlador USB no barramento PCI, etc. Observe que o sistema operacional deve assumir a existência do barramento PCI. e a maneira de investigar; isso é padronizado na arquitetura do PC (“arquitetura de PC” não significa apenas um processador x86: para ser um PC (moderno), um computador também precisa ter um barramento PCI e ter que inicializar de uma determinada maneira).

Muitos sistemas embarcados usam barramentos menos sofisticados que não suportam enumeração. Isso era verdade no PC até meados dos anos 90, antes que o PCI superasse a ISA . A maioria dos sistemas ARM, em particular, possui barramentos que não suportam enumeração. Este também é o caso de alguns sistemas x86 incorporados que não seguem a arquitetura do PC. Sem enumeração, o sistema operacional precisa ser informado sobre quais dispositivos estão presentes e como acessá-los. A árvore de dispositivos é um formato padrão para representar essas informações.

A principal razão pela qual os barramentos de PC suportam a descoberta é que eles foram projetados para permitir uma arquitetura modular na qual os dispositivos podem ser adicionados e removidos, por exemplo, adicionando um cartão de extensão a um PC ou conectando um cabo em uma porta externa. Os sistemas embarcados normalmente possuem um conjunto fixo de dispositivos¹ e um sistema operacional pré-carregado pelo fabricante e não é substituído, portanto, a enumeração não é necessária.

¹ _{Se houver um barramento externo, como USB, os periféricos USB são descobertos automaticamente, eles não seriam mencionados na árvore de dispositivos.}

    

Answer 2

Os PCs realmente precisam de uma árvore de dispositivos.

Eles só chamam de outra coisa.

Não é correto dizer que sistemas operacionais para descendentes de PC / AT compatíveis assumem a existência de coisas como um barramento PCI. Eles não.

Nem eles sondam. A pesquisa de hardware, apenas cutucando alguns endereços de E / S ou memória para ver se funcionam, não foi necessária desde meados dos anos 90.

Em vez disso, eles enumeram um root bus .

Este é um barramento que não é enumerável pela comunicação com o hardware do dispositivo controlador de barramento, como acontece com outros barramentos enumeráveis. Este é um barramento que existe apenas como uma construção do firmware do sistema e do sistema operacional. Ele é enumerado consultando o firmware do sistema, e o que está presente nele é incluído no firmware do sistema pelo fabricante da placa-mãe, para corresponder ao que está na placa-mãe.

Há pouca diferença no conceito entre esta e uma árvore de dispositivos. Assim como uma árvore de dispositivos, ela precisa ser criada para corresponder à placa real. Assim como uma árvore de dispositivos, é uma lista de nós de dispositivos com informações de recursos (entre outras coisas) anexadas a eles. Assim como uma árvore de dispositivos, ela é externa ao sistema operacional e não é uma lista de coisas a serem testadas pelo próprio código do sistema operacional.

A especificação Plug and Play BIOS faz o firmware fornecer uma árvore de dispositivos simples na memória para um sistema operacional, um dos nós será (por exemplo) um PNP0A03 designando um nó Barramento PCI, fornecendo os recursos de E / S e de memória que são atribuídos e, portanto, onde eles devem ser encontrados.

O ACPI substitui isso, mas a ideia permanece a mesma. Na ACPI há uma tabela chamada Tabela de Descrição do Sistema Diferenciada , aumentada por uma Tabela do Descritor de Sistema Secundário , que (com informações de algumas outras tabelas da ACPI) fornece praticamente o mesmo coisa.

(Se você quiser ver isso do lado dos desenvolvedores de firmware, veja o Coreboot, por exemplo. Ele possui um grande conjunto de arquivos de Linguagem de Origem ACPI, uma seleção dos quais são compilados em uma imagem binária de bytecode que é incorporada o firmware. A seleção é controlada por uma ferramenta de configuração que solicita uma para a placa-mãe específica que está sendo direcionada.)

No FreeBSD, por exemplo, as informações do Plug and Play BIOS Specification foram enumeradas por um driver pnpbios no kernel (que já foi removido), e (hoje em dia) as informações da ACPI é enumerado por um driver de barramento acpi . No Linux, há (ainda) um driver de barramento drivers/pnp/pnpbios que lê as tabelas do BIOS Plug and Play, e as tabelas da ACPI são lidas pelo código espalhadas por arch/arm64/kernel/ e arch/x86/kernel/ .

O barramento raiz enumerável pode, mas geralmente não (sobre algumas usurpações por ACPI) se sobrepor com coisas enumeráveis nos barramentos que são dispositivos no barramento raiz. Por exemplo, enquanto houver PNPxxxx IDs para os barramentos ATA, o firmware do sistema não listará os dispositivos de ponte PCI-para-ATA no barramento raiz, usando-os. Esses dispositivos são encontrados encontrando o barramento PCI ao enumerar o barramento raiz e, em seguida, localizando a ponte PCI-para-ATA ao enumerar o barramento PCI.

O simples fato da questão é que em plataformas descontroladamente divergentes, com nomes diferentes para os conceitos, o mesmo princípio básico está em operação. Há uma lista interna de dispositivos que correspondem aos dispositivos não enumeráveis no sistema, e o firmware ou o carregador de boot em uso fornece um mecanismo para o sistema operacional ler essa lista e configurar os dispositivos nela, permitindo o sistema operacional para enumerar esses dispositivos em seus turnos.

Leitura adicional

• Compaq Computer Corporation, Phoenix Technologies e Intel Corporation (1994-05-05). Especificação do BIOS Plug and Play . Versão 1.0A. Corporação da Intel.
• Links para documentos relacionados à ACPI . Fórum de Interface de Firmware Extensível Unificado. UEFI.
• Patrick Mochel (2002). " O modelo de dispositivo de kernel do Linux ". Anais do Ottawa Linux Symposium 2002 . pp. 368-375.
• Hiten Pandya e Tom Rhodes. " Gerenciamento de energia e recursos ". Manual do FreeBSD .
• "Drivers legados: teste de dispositivo". Dispositivos e Drivers de Plataforma . %código%. Kernel do Linux.
• link