Localizando informações de hardware no linux sem lspci
Eu tenho um dispositivo ARM executando o ArchLinux. O dispositivo não parece ter nenhum barramento PCI, apesar de possuir USB.
Eu quero encontrar o que há outros chipsets. Por exemplo, eu sei que há uma placa de som e uma placa de vídeo capazes de HDMI. Esse chip não seria colocado em uma linha USB.
Eu olhei para a configuração do kernel que está atualmente trabalhando no dispositivo em /proc/config.gz, ela lista isto:
Não sei o que é o AMBA. Uma pesquisa minuciosa do google retorna essa entrada no banco de dados do kernel, mas sem nenhuma explicação real, exceto para não usá-lo se você não souber o que está fazendo.
O uso do lshw também não mostra muito mais:
Parece não haver módulos neste kernel carregados:
Além disso, o hwinfo não parece estar disponível:
Preciso saber quais chips são usados ​​neste sistema para que eu possa compilar nos módulos corretos de driver de vídeo. Como descobrir o que há em um sistema sem lspci funcionando?
Muitos SOCs de ARM realmente não têm um barramento PCI. Não tenho certeza qual é o nome do barramento interno em tais SOCs ou se é padronizado. Você pode lsmoddar uma olhada nos módulos existentes. Além disso, se você possui um kernel em funcionamento conhecido com um configarquivo, pode usá-lo para começar - e pesquisar, porque ele já terá os módulos corretos selecionados. Foi útil para mim fazer kernels personalizados para o Guruplug.
Adicionamos o resultado do lsmod, que basicamente não é nada. Este é um kernel ARM genérico, portanto, nenhum módulo específico foi construído. Estou tentando descobrir em quais módulos devo construir para não inundar a máquina com módulos inúteis.
— tu-Restabelece Monica-dor duh
Isso me fornece apenas informações de CPU, não o restante do hardware, como chipsets de som e vídeo.
Qual é o dispositivo ou plataforma que você está usando?
Aqui está a minha resposta oficial depois de você responder aos meus comentários. Eu poderia estar completamente errado sobre isso e receber as correções.
Não sei ao certo quando a Intel começou a incorporar o PCIe (que é uma extensão compatível com o software do PCI) em suas CPUs. No entanto, não tem sido assim na maioria das vezes que o x86 existe. O PCI é realmente parte de toda a "plataforma de PC", que inclui várias outras coisas que são padrão e esperadas, como portas ISA padrão / endereço de E / S / IRQs para dispositivos e coisas assim.
Retroceda um pouco antes do PCI estar disponível - basicamente, exceto com a tentativa abortada de introduzir um padrão PnP com o ISAPNP, você realmente não "sondou" alguns dispositivos. Você geralmente precisaria assumir que elas existiam antes. Você poderia, é claro, testar os registros e o que não ver se as coisas respondem como o esperado, mas você terá problemas se houver um dispositivo diferente, possivelmente resultando em travamentos, etc. Não havia realmente uma maneira de "digitalizar" o barramento ISA. Ou realmente qualquer outro barramento que não suporte conceitos de PnP de maneira padronizada.
Uma das coisas que a ACPI deveria resolver era fornecer algumas tabelas de informações que informavam quais dispositivos ISA estavam embutidos. Mesmo antes da ACPI, o BIOS seria consultado para decidir quantas unidades de disquete havia no sistema. É por isso que em sistemas mais antigos, mesmo se não houver um disquete conectado, você verá uma unidade A: no Windows se o BIOS estiver configurado para dizer que existe um.
Então você pode perguntar como os sistemas operacionais modernos determinam ou fazem interface com um chipset PCI. Na maioria das vezes, o chipset aparece como um dispositivo no próprio barramento PCI. A interface PCI registra "pré-existe" em locais padrão conhecidos na plataforma do PC. Uma varredura programática através de todos os slots de dispositivos e funções no espaço PCI é possível aqui. Nada disso existe para o ISA. Se o dispositivo estiver no barramento com o ISA, os registradores responderão quando carregados / armazenados, e é isso. Você realmente não pode falar com o próprio ônibus.
Aliás, o chipset PCI pode até ter a capacidade de controlar uma ponte "PCI-ISA" e trazer parte da funcionalidade PnP para o barramento ISA (ou agora, LPC). Por si só, o ISA diz que você está por sua conta.
Não existe uma plataforma padrão para o ARM. Ainda não, pelo menos. Existem muitas plataformas exclusivas nas quais as CPUs ARM são executadas. Os barramentos PCI, I2C e SDIO (e possivelmente mais que eu não conheço) são comuns entre alguns deles, mas, novamente, existem plataformas ARM que não possuem nenhum deles. O ACPI não é implementado no ARM AFAIK, exceto no Microsoft Surface RT. Sem trabalhar com um barramento padronizado que suporte alguma noção de PnP, realmente não há como "sondar" nada. Você precisa ter conhecimento prévio fora do sistema do hardware que deveria estar lá. O U-Boot é um carregador de inicialização ARM comumente usado que requer suporte e é construído para a plataforma específica na qual ele deve ser executado. É algo como um padrão, mas mesmo assim, é '
Alguns estudos no Google revelam que este dispositivo possui um chipset de vídeo "Mali 400". Outras pesquisas trazem o site de código-fonte do driver GPU do Mali . Estou um pouco enferrujado no meu C, mas olhei para ele. Parece que você deve fazer, quando criar o driver, informar os endereços que ele precisa atingir para conversar com a GPU. Eu realmente não mergulhei profundamente na fonte, mas não me surpreenderia se não estivesse falando com um barramento, mas apenas carregando / armazenando diretamente da E / S mapeada na memória.
Infelizmente, acho que não há uma resposta genérica para todas as plataformas ARM.
Essa é uma ótima resposta detalhada. Você sabe o que é o AMBA? Não consegui encontrar nenhuma referência a ele fora da fonte do kernel. Ele está listado em ônibus, portanto, deve ser algum tipo de ônibus.
@tudor: AMBA provavelmente significa Avançada microcontrolador Bus Architecture
Eu esperava que houvesse um equivalente em todas as arquiteturas, especialmente porque você pode danificar o dispositivo se especificar as erradas! Estou aceitando isso por enquanto, uma vez que responde a uma pergunta específica, mas acho que há uma nova pergunta sobre como encontrar informações para que essas coisas funcionem com kernels e software.
— tu Reinstala Monica-dor duh
Você pode tentar hwinfo. Está nos repositórios do Arch.
Eu adoraria que fosse assim tão simples. Atualizou a pergunta. Parece que o hwinfo não está disponível para mim, pelo menos, a menos que eu tenha um problema no repositório. Além disso, o archlinux.org/packages não lista o ARM, apenas o i686 e o ​​x86_64.
Tentei o hwinfo e o lshw no raspberry pi / raspian - nenhum deles mostra o adaptador de vídeo, portanto há uma boa chance de você não conseguir vê-lo.