Posts com Tag ‘Hardware’

Este post descreve a instalação do driver para o controlador wireless do netbook Acer Aspire One Series.
Sistema Operacional: GNU/linux, Debian 6 (Squeeze)

Neste equipamento a interface wireless está em eth1.

1) Identificar o hardware wireless
$ lspci -nn | grep Network
01:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01)

Interpretando:
vendor 0x14E4: Broadcom
Devide 0x4315: BCM4315/BCM22062000 Broadcom Wireless b/g

2) Identificar o driver

A Broadcam tem um driver Linux para esta placa em: http://www.broadcom.com/support/802.11/linux_sta.php
Este pacote contém device driver Broadcom’s IEEE 802.11a/b/g/n hybrid Linux® para uso com os hardwares Broadcom’s BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based.

3) Baixar o driver e compilar

3.1) Baixar o driver (no caso, o pacote para 32bits)

minhapasta$ wget -c http://www.broadcom.com/docs/linux_sta/hybrid-portsrc_x86_32-v5_100_82_112.tar.gz

3.2) Desempacotar (no caso, o pacote de 32bits baixado)
minhapasta$ tar -vzxf hybrid-portsrc_x86_32-v5_100_82_112.tar.gz

O arquivo README que está disponível na URL do driver deve ser lido, pois trata-se um tutorial para instalação do driver.

3.3) Headers do Kernel
Se ainda não estiver com os arquivos de headers do kernel instalados, faça-o agora:
# apt-get install build-essential linux-headers-$(uname -r)

3.4) Compilador C
Se ainda não estiver com o compilador C instalado, faça-o agora:
# apt-get install gcc

3.5) Compilar o driver como um “Linux loadable kernel module” (LKM)
minhapasta# make clean
minhapasta# make

Quando a compilação estiver completa, será produzido um arquivo wl.ko
Este driver agora suporta a nova API linux de configuração sem fio cfg80211 em substituição da extensão anterior mais velhos sem fio (wext). O “makefile” automaticamente irá construir a versão correta para o sistema, mas ele pode ser
substituído se necessário:

# make API=WEXT
ou ainda
# make API=CFG80211

4) Instalar driver
4.1) Remover qualquer outro driver instalado para o Broadcom wireless device.
Existem vários outros drivers (além deste baixado) que podem controlar o Broadcom 802.11 tais como b43, BCMA e SSB. Para visualizar os drivers instalados:
# lsmod | grep "b43\|ssb\|bcma\|wl"

Se algum deste estiver instalado, remova-os:
# rmmod b43
# rmmod ssb
# rmmod bcma
# rmmod wl
# rmmod ndiswrapper

Colocar estes drivers na “blacklist” para prevenirque sejam carregados no futuro:
# echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf
# echo "blacklist bcma" >> /etc/modprobe.d/blacklist.conf
# echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf

4.2) Remover uma (possível) versão do “wl” já instalado anteriormente
Se já existia uma versão anterior do wl, basta fazer o procedimento deste subitem desconsiderando os demais passos descritos neste item “Instalar”. Considerando uma versão do “wl” instalada, é necessário fazer uma transição limpa do driver mais antigo para o novo driver. O caminho para o driver anterior é normalmente /lib/modules/<kernel-version>/kernel/net/wireless. Quando da publicação deste post, o caminho era /lib/modules/2.6.32-5-686/kernel/net/wireless/

minhapasta# rmmod wl
minhapasta# mv /lib/modules/<kernel-version>/kernel/net/wireless/wl.ko /lib/modules/<kernel-version>/kernel/net/wireless/wl.ko.orig
minhapasta# cp wl.ko /lib/modules//kernel/net/wireless/wl.ko
minhapasta# depmod
minhapasta# modprobe wl

O novo driver “wl” deve estar agora operacional e está tudo feito. Não há necessidade de fazer os passos descritos nos itens 4.3 à 4.7 abaixo.

4.3) Módulo de segurança de criptografia
Caso não tenha ocorrido uma instalado de um driver “wl” anteriormente, será necessário adicionar um módulo de segurança antes da utilização deste módulo “wl”. De uma maneira geral, os sistemas atuais usam o “lib80211”.
# modprobe lib80211

4.4) Carregar módulo de API cfg80211
# modprobe cfg80211

4.5) Carregar driver
# insmod wl.ko

O novo driver “wl” deve estar agora operacional e está tudo feito. Pode demorar alguns segundos para o “Network Manager” perceber que um novo driver de rede foi instalado e poder mostrar as redes wireless disponíveis.

4.6) Back up o corrente boot ramfs e gerar um novo
minhapasta# cp /boot/initrd.img-`uname -r` somewheresafe
minhapasta# update-initramfs -u
minhapasta# reboot

4.7) Diretório de módulos do kernel
Copiar o módulo gerado para o diretório de módulos do kernel e criar as dependências:

minhapasta# cp wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless
minhapasta# depmod -a

5) Conectando em Redes Sem Fio no Linux
Esta parte do tutorial é referente a como fazer a conexão em redes sem fio que utilizem ou não proteção (WEP e WPA), tudo por linha de comando no GNU/Linux.

5.1) Parar o gerenciador de rede
Deve-se parar o processo do gerenciador de rede caso este esteja sendo utilizando. Por exemplo, os gerenciadores de rede “Network Manager” ou “Wicd”. Aproveitaremos para mostrar sua desativação completa para que não seja mais iniciado durante o boot:

# /etc/init.d/network-manager stop
# update-rc.d -f network-manager remove

5.2) Habilitar a interface de rede
# ifconfig eth1 up

5.3) Rede Aberta
Para conectar quando é uma rede aberta, ou seja, sem nenhuma criptografia, basta o seguinte comando:
# iwconfig eth1 essid WIFI

5.4) Rede com Criptografia WEP
Se a rede tiver criptografia WEP, para conectar execute o seguinte comando:
# iwconfig eth1 essid WIFI key SENHA

5.5) Rede com Criptografia WAP
Mas se a rede estiver com criptografia WPA, conforme foi mostrado no escaneamento de rede, para conectar execute os seguintes comandos:
# wpa_passphrase WIFI SENHA > /etc/wpa_supplicant/wpa_supplicant.conf
# wpa_supplicant -i eth1 -c /etc/wpa_supplicant/wpa_supplicant.conf -B -D wext

5.6) Finalmente solicitar o IP para navegação
# dhclient wlan0

Links:
1- Broadcom BCM4312 com driver nativo do Linux
2- Conectando em Redes Sem Fio no Linux

Anúncios

Ao instalar uma imagem Debian (a que eu usei foi a versão 6 do Debian, a Squeeze) no lap-top HP Pavilion dv2040, nos deparamos com o problema da interface wifi não funcionar. Isso é devido ao fato de que o fabricante do driver (a Intel) não disponibilizá-lo como software livre. Assim, a distribuição Debian não incorpora o driver em sua ISO.

1. Buscando a solução

Estamos diante do desafio de lidar com a instalação e a configuração do dispositivo WiFi. A instalação deste dispositivo é, essencialmente, um processo em duas etapas: 1) instalar um driver (também chamado módulo) e 2) configurar sua interface WiFi. Um dispositivo WiFi opera através de um chip eletrônico chamado “chipset”. Podemos encontrar o mesmo chipset em diversos dispositivos diferentes. Consequentemente, o driver/módulo para um chipset irá funcionar com todos os dispositivos que usam aquele chipset. Uma interface WiFi é uma interface Ethernet que também provê parâmetros específicos de configuração WiFi, que são controlados usando o comando iwconfig.

Antes de mais nada, vamos ver que placa de wifi é esta que está equipada no laptop:

# lspci -nn
05:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)

Fazendo a identificação do dispositivo (vide http://www.pcidatabase.com/):

  • 8086: é a identificação do “vendor”. No caso, o número corresponde a empresa Intel;
  • 4222: é a identificação do “device”. A identificação do chip que encontramos é “Intel 3945ABG Wireless LAN controller”.
  • Vemos que o laptop HP Pavilion dv2040 possui uma placa wireless fabricada pela Intel, referência “Intel Corporation PRO/Wireless 3945ABG”. Para ela funcionar há necessidade de seu driver proprietário correspondente, de forma a controlar corretamente seu chipset (que, fazendo as pesquisas utilizando as referências ao final deste post, encontramos a identificação do seu chipset: ipw3945; e de seu driver necessário: iwl3945). De forma complementar, algumas destas informações também poderiam ser obtidas diretamente do data-sheet do laptop, tal como a encontrada em http://www.retrevo.com/search?q=HP+DV2040&rt=sp&modelid=607833.

    O fabricante do laptop, a HP, mantém em seu portal informações sobre os drivers utilizados em suas máquinas. Informações sobre a placa 3945ABG podem ser obtidas neste portal. Neste mesmo portal da HP encontra-se a indicação da localização de onde podemos baixar o driver da placa. No entanto, nesta página do sourceforge observamos uma nota informando que o projeto do driver fora descontinuado (para kernels Linux a partir do 2.6.24), e que seu desenvolvimento está agora unificado com o projeto iwlwifi (Intel Wireless WiFi) para Linux. Nesta página encontramos o link onde se encontra especificamente o projeto iwlwifi para a placa em uso no laptop (Nota: como dito antes, este projeto serve para kernels Linux a partir do 2.6.24).

    No momento deste post, a versão do driver disponibilizado para download na página do projeto foi a “iwlwifi-3945-ucode-15.32.2.9.tgz”. Na verdade, há necessidade de dois pacotes Debian:
    (a) o firmware: firmware-iwlwifi, que é o firmware binário para a placa Intel Wireless 3945 (iwlwifi-3945-2.ucode);
    (b) o driver: wireless-tools, que contém as ferramentas sem-fio (“wireless”), usadas para manipular diretamente as extensões sem-fio do Linux (“Linux Wireless Extensions”). A extensão sem-fio é uma interface que permite ao usuário ajustar a LAN sem-fio para parâmetros específicos.

    Há duas opções de encaminhamento a partir deste ponto, já que fora alcançado o entendimento das razões do não funcionamento da interface wifi do laptop.

    2. Fazendo a instalação dos softwares necessários

    2.1 Opção 1: adicionar repositório non-free e instalar o driver e o firmware via aptitude (ou Synaptic, usando a interface gráfica)

    (a) Adicione um “non-free” componente à /etc/apt/sources.list. No caso da versão Debian 6, teremos:

    # Debian Squeeze/6.0
    deb http://ftp.br.debian.org/debian squeeze main contrib non-free

    (b) Atualize a lista de pacotes disponíveis. Instale o firmware-iwlwifi e o pacote wireless-tools:

    # aptitude update
    # aptitude install firmware-iwlwifi wireless-tools

    (c) Reinicie a máquina. Após este procedimento a interface wifi do laptop deve funcionar normalmente.


    2.2 Opção 2
    : baixar o driver e o firmware e fazer a instalação manualmente

    Sem dúvidas, a opção 1 descrita anteriormente é mais rápida e simples. Mas com conhecimentos mais avançados em Linux e sendo cuidados@, esta opção 2 pode ser adotada sem problemas. As instruções de instalação estão dentro do README do próprio driver iwlwifi-3945-ucode (que como dito antes, pode ser baixado de http://intellinuxwireless.org/?p=iwlwifi).

    Dica:
    Um interessante aplicativo para ver as configurações da máquina de uma forma gráfica é o “hardinfo”:
    (a) # apt-get install hardinfo
    (b) acesse o aplicativo através do menu suspenso Aplicativos->Sistema->Informações_e_Testes_do_Sistema (no gnome).

    Mais informações:
    1- Como habilitar os dispositivos WiFi baseados nos chipsets Intel 3945 and 4965 em sistemas Debian
    2- Intel Wireless Wifi Link Drivers for Linux
    3- Debian Wireless Fidelity
    4- How to use a WiFi interface
    5- Entendendo melhor como funcionam os drivers em máquinas Linux
    Identificação de dispositivos PCI:
    6- Como identificar os dispositivos PCI de uma máquina
    7- Identificação dos PCI devices
    8- PCIdatabase
    9- Listagem de dispositivos wireless devices com informação sobre o seu chipset, e se são suportados em Linux

    AMD64, x64 ou x86-64 é o nome genérico dada à família (arquitetura) de processadores baseados na tecnologia de 64 bit, utilizada pelos processadores tanto da Intel como da AMD (AMD64 & Intel EM64T). É um superconjunto da arquitetura x86, que, por sua vez, tem esta denominação pelo fato dos primeiros processadores desta arquitetura terem sido identificados somente por números terminados com a seqüência “86”: o 8086, o 80186, o 80286, o 80386 e o 80486. Os processadores x86-64 também podem executar programas x86 (de 32-bit ou 16-bit). Assim, resumindo, arquitetura é o tipo de hardware com que o computador foi construído.

    A mais popular é a arquitetura Intel/AMD. Na maioria dos casos utiliza-se as imagens para “i386”. Se o computador tem um processador de 64 bits, AMD ou Intel, deve-se optar por uma imagem “amd64” (apesar da “i386” funcionar bem). Mas a imagem “ia64” não vão funcionar. Apenas os processadores Itanium (que são da Intel, e para servidores de alto desempenho) roda o IA-64, que é incompativel com o resto. O IA64 só consegue executar nativamente aplicativos 64 bits . Para os demais processadores que suportam 64-bit, deve-se usar o pacote AMD64. O nome AMD64 é porque os primeiros 64-bit eram AMD, e o nome perdura até hoje, mas serve para os intel 64-bit. Para processadores 64bits o pacote AMD64 teoricamente dará um melhor desempenho.

    É bom citar que a imagem de 32 bits tem a capacidade de controlar até 4GB de memória RAM. Assim, se seu PC tem um processador de 64 bits AMD ou Intel, você provavelmente deve optar as imagens AMD64 (apesar da i386 funcionar bem). Mas as imagens IA64 não vão funcionar.

    Veja mais:
    1- Qual das inúmeras imagens eu devo baixar? (FAQ – Debian)
    2- Debian – hardwares suportados
    3- Arquitetura de processadores baseados na tecnologia de 64 bit
    4- EM64T – implementação da Intel da AMD64
    5- Forum Guiadohardware: duvida….ia64 e amd64

    Se você tem dois ou três computadores em casa ou em seu escritório, certamente tem interesse em conectá-los em rede para compartilhar impressoras, arquivos e a conexão à internet. Para isso, a ação mais comum é a criação de um cabo crossover ou de um cabo direto. Este tutorial ensinará como criá-los.

    Itens para a crimpagem de cabos crossover e direto:

    – Alicate de crimpagem;
    – Conectores RJ-45;
    – Cabo UTP padrão CAT 5e (tamanho variável de acordo com a necessidade).

    Para ligar computador a computador, usa-se cabo crossover. Para ligar computador a um hub/switch, usa-se cabo direto. A diferença entre eles é que o cabo crossover tem a disposição de seus fios de maneira diferente em uma ponta em relação à outra, enquanto que o cabo direto tem a disposição dos fios iguais em cada extremidade. O cabo crossover também deve ser usado quando é necessário conectar um hub/switch a outro.

    Montando o cabo direto

    O primeiro passo para montar o cabo consiste em tirar parte do revestimento (em cerca de 1 cm) das extremidades do cabo, deixando expostos os fios. Para isso, deve-se usar um alicate de corte (alguns alicates de crimpagem contam com esse recurso), mas tome cuidado para não cortar os fios. Em seguida, deve-se colocá-los na seguinte ordem:

    Essa seqüência é conhecida como norma EIA/TIA 568A.

    Após a realização desse passo, é necessário encaixar o conector RJ-45, tomando-se o cuidado de fazer com que cada fio entre no orifício correspondente. Para isso, segure o conector firmemente em uma mão e a ponta do cabo na outra. Insira os fios vagarosamente, certificando-se de que nenhum ficou pelo caminho. Se ao atingir o final do conector você notar que algum fio tem alguma diferença de tamanho ou está mais atrás em relação aos outros, refaça o procedimento. Os fios devem ter o mesmo tamanho e todos devem chegar ao final dos orifícios do conector.

    É muito importante que o revestimento do cabo também entre no conector. Do contrário, será mais fácil ocorrer o rompimento dos fios.

    Após ter certeza de que o cabo está devidamente inserido no conector, é hora de crimpar. Para isso, coloque o conector dentro do espaço correspondente do alicate de crimpagem. Segure o cabo com uma mão e com a outra pressione o alicate. Após o cabo estar relativamente preso, reforce o procedimento apertando o alicate com as duas mãos. Aperte bem, mas tome cuidado para não exagerar e danificar o conector.

    1- Branco verde
    2- Verde
    3- Branco com laranja
    4- Azul
    5- Branco com azul
    6- Laranja
    7- Branco com Marrom
    8- Marrom

    Se você notar algum problema após crimpar o cabo, não será possível tirar o conector. A saída é cortar o cabo nesse ponto e repetir todos os passos.

    O cabo direto tem as duas pontas iguais, logo basta repetir os procedimentos acima para a outra ponta. Se tudo se sair bem seu cabo direto está pronto para ser usado!

    Montando o cabo crossover
    O cabo crossover deve ter uma ponta no padrão EIA/TIA 568A. Logo, faça os procedimentos do tópico anterior em um dos lados do cabo.

    Feito isso, na outra extremidade, é necessário que os fios sejam posicionados no conector RJ-45 na seguinte ordem:

    1- Branco com laranja
    2- Laranja
    3- Branco com verde
    4- Azul
    5- Branco com azul
    6- Verde
    7- Branco com Marrom
    8- Marrom

    Essa seqüência é conhecida como norma EIA/TIA 568B. Os cabos são encaixados nessa ordem, com a trava do conector virada para baixo, como no diagrama:

    Posição dos fios

    Posição dos fios

    Veja mais informações em:
    Tutorial da infowest.
    Tutorial do GDH.r

    1- Pequena revisão de tipos de barramentos
    Os barramentos são utilizados para interligar os diferentes componentes da placa-mãe e também permitir o uso de placas de expansão.

    • ISA: foi o primeiro barramento de expansão utilizado em micros PC.  Nos dias atuais as placas mães com slots ISA praticamente desapareceram do mercado.  Uma das razões que levou a isto é o fato do barramento ISA ser muito lento (operam a apenas 8.33MHz). Com isto, a taxa de transferência real ficar a apenas em 5MB/s.
    • MCA: barramento desenvolvido pela IBM, na intenção de superar as limitações do barramento ISA. Tratava-se de um barramento proprietário, onde os fabricantes de PCs e de periféricos tinham de licenciar a tecnologia e pagar royalties para produzir produtos compatíveis.  A taxa de transferência teórica era de 32MB/s.  O MCA acabou por fracassar.
    • EISA: desenvolvido pela Compac, que abriu as especificações para os demais fabricantes.  Era 4 vezes mais rápido que o padrão ISA.  No entanto, acabou tendo vida curta, pois em 1993 surgiu o VLB.
    • VLB: o VESA Local Bus (VLB) é um padrão aberto de barramento de 32 bits, oferecendo taxas de transferência teóricas de 133MB/s. Tornou-se o padrão de barramento para placas com processadores 486, mas acabou desaparecendo com a introdução do barramento PCI.
    • PCI: em 1992 fora introduzido o barramento PCI, que incorporava o suporte nativo plug-and-play e bus mastering (sistema avançado de acesso direto à memória que permite que HDs, placas de vídeo e outros periféricos leiam e gravem dados diretamente na memória RAM, deixando o processador livre). O PCI é um barramento de 32 bits, resultando em uma taxa de transmissão teórica de 133MB/s compartilhada entre todos os periféricos ligados a ele.  Atualmente é amplamente utilizado em computadores PCs.
    • PC Card (PCMCIA): o padrão PCMCIA surgiu em 1990 como um padrão para expansão de memória em notebooks.  A idéia era permitir a instalação de memória RAM adicional sem precisar abrir o notebook. Em 1991 foi lançado o padrão 2.0, que previa a conexão de outros periféricos, como modems, placas de rede, placas de som, adaptadores de cartões e assim por diante. O padrão PCMCIA foi rapidamente adotado pelos principais fabricantes, tornando-se o barramento de expansão mais usado nos notebooks, mas nunca chegou a ser realmente utilizado para atualização de memória, como originalmente proposto. Como os notebooks atuais passaram a vir “completos”, com rede, som, modem e placa wireless e cada vez mais periféricos passaram a utilizar as portas USB, as placas PC Card se tornaram realmente um item relativamente raro. O PC Card é um barramento plug-and-play, de forma que se pode conectar e desconectar as placas com o micro ligado. Elas são detectadas automaticamente pelo sistema, da mesma forma que os periféricos USB. No caso do Linux os drivers para placas compatíveis são, em sua maioria, incorporados diretamente ao Kernel.
    • AGP: a idéia do barramento “Acelerated Graphics Port” (AGP) é ser um barramento rápido, feito sob medida para o uso das placas 3D de alto desempenho. A versão original do AGP foi finalizada em 1996. Ela permite uma taxa de transferência teórica de 266MB/s. O aparecimento do barramento AGP desafogou o PCI, permitindo que a placa de vídeo tivesse seu próprio barramento rápido de comunicação com o chipset dedicado. A AGP permitiu o aparecimento de placas 3D absurdamente mais rápidas bem como desafogou a comunicação entre os demais componentes. Rapidamente todas as placas de vídeo passaram a utilizá-lo, com os fabricantes oferecendo versões PCI apenas dos modelos mais simples. Embora seja mais recente que o PCI e tenha sido largamente utilizado, o AGP é atualmente um barramento em vias de extinção, devido à popularização do PCI-Express.  Desde 2006, placas novas com slots AGP são um item raro. As placas AGP chegam a uma taxa de transferência de 2133MB/s.
    • PCI Express:  o PCI Express, ou PCIe, é um barramento serial (e não um barramento paralelo, como o PCI), que conserva pouco em comum com os barramentos anteriores. Graças a isso, ele acabou se tornando o sucessor não apenas do PCI, mas também do AGP. Uma das características fundamentais do PCI Express é que ele é um barramento ponto a ponto, onde cada periférico possui um canal exclusivo de comunicação com o chipset. No PCI tradicional, o barramento é compartilhado por todos os periféricos ligados a ele, o que pode criar gargalos. Um slot PCI Express 16x atinge incríveis 4 GB/s de taxa de transferẽncia.
    • USB: o “Universal Serial Bus” é o barramento externo mais usado atualmente. No USB 2.0, o padrão atual, a velocidade é de 60 MB/s, suficiente para a maioria dos pendrives e HDs externos. O USB é um barramento serial, com conectores de 4 contatos, sendo dois para a transmissão dos dados (um para enviar, outro para receber) e os outros dois para a transmissão de eletricidade. Tem-se ainda a possibilidade de usar hubs USB para conectar vários dispositivos à mesma porta. Em teoria, cada porta USB permite a conexão de até 127 dispositivos.  O USB utiliza transmissores e circuitos muito baratos e livre de pagamento de royalties, o que facilita sua popularização.
    • Firewire (IEEE 1394): o firewire surgiu em 1995, pouco antes do USB. Inicialmente desenvolvido pela Apple, o nome fireware é marca registrada daquela empresa. Trata-se de um barramento serial plug-and-play, similar ao USB em muitos aspectos. Suporta conexão de vários periféricos na mesma porta. O conector tradicional utiliza 6 pinos, sendo que 2 são usados para alimentação. Nos dias atuais, o fireware está restrito a alguns nichos, sendo o principal desles a transferência de vídeos a partir de uma filmadora digital. Sua taxa de transmissão é de 50 MB/s (no “FireWire 400”, ou IEEE 1394a) e 100MB/s (no “FireWire 800”, ou IEEE 1394b), este último lançado em 2002. Os fabricantes têm de pagar à Apple pelo uso da tecnologia.

    2- O Boot da máquina e o processo de dentificação dos periféricos
    Uma das características de maior relevância no funcionamento do PCI, é de que este tem suporte de autodetecção das placas de interface. Os dispositivos PCI são construídos sem “jumpers” e são automaticamente configurados no momento do boot. Quando a energia da máquina é ligada, o hardware permanece inativo. Em outras palavras, o dispositivo responde apenas para as transações de configuração. Neste momento de energização, o dispositivo não tem nem memória nem portas de I/O mapeadas no espaço de memória do computador.  A placa mãe é equipada com um firmware, chamado BIOS, NVRAM ou PROM, dependendo da plataforma.  O firmware oferece acesso ao espaço de endereçamento de configuração de cada dispositivo através da leitura e escrita nos registros de controle de cada dispositivo PCI.

    BIOS (Basic Input/Output System): é o firmware para um computador cuja principal função é identificar e inicializar os componentes da motherboard bem como carregar e transferir o controle para um pequeno programa que então faz o carregamento do sistema operacional (a partir do HD, CD-ROM, pendrive, ou qualquer outra mídia disponível).

    Aqui estamos nos referindo a “device” ou periférico PCI, indistintamente, e como sendo um dispositivo físico conectado ao barramento PCI. Este dispositivo físico pode ser um cartão de vídeo, um cartão ethernet, uma “Northbridge” etc. Quando do boot do sistema, o firmware realiza os procedimentos de configuração de cada periférico PCI. Os dispositivos PCI fornecem informações que estão guardadas em cada placa. Essas informações são: vendor, device, subsystem_device, subsystem_vendor e class. Um sinal de requisição é enviado pelo BIOS para todos os periféricos instalados no micro.  Cada periférico é capaz de responder ao chamado, permitindo ao BIOS reconhecer que periféricos estão instalados. O passo seguinte é criar uma tabela com todos as interrupções disponíveis e atribuir a cada uma um dispositivo. O sistema operacional (SO) entra em cena logo em seguida, lendo as informações disponibilizadas pelo BIOS e completando a inicialização dos periféricos. Ou seja, quando o device driver acessa o dispositivo, sua região de memória e de I/O já terá sido mapeada dentro do espaço de endereços do processador. O driver pode até alterar esta configuração inicial, porém isto nunca se faz necessário.

    PCI típico

    Leiaute de um sistema típico PCI

    Existem duas pastas especiais que são utilizadas durante o boot do sistema:

    • /proc: trata-se de um diretório virtual, um filesystem virtual. Não contém arquivos como aparenta, mas sim referências a informações dinâmicas do sistema (procedure), geradas constantemente pelo kernel.
    • /sys: destinado à montagem do sysfs (sys filesystem), um repositório utilizado a partir do kernel 2.6 para manter dados atualizados sobre o sistema e os dispositivos de hardware.  Não tem relação com o /proc.

    sysfs
    A pasta /sys implementa o ponto de montagem do sysfs (ou “/sys filesystem” – SYStem FileSystem), que é o diretório de dispositivos de todo o sistema o qual contém informações e estatísticas sobre os dispositivos. Foi adicionado ao Linux a partir da introdução dos kernels 2.6.X.

    O /sys é um diretório especial contendo um sistema de arquivos virtual (o sysfs), montado durante o boot do sistema. Os arquivos contidos em /sys não estão fisicamente no disco rígido, mas sim em áreas protegidas da memória RAM (“ram-based filesystem”). A pasta implementa a montagem do sysfs, vindo a se constituir num repositório de informações atualizadas do sistema, principalmente sobre os recursos instalados na máquina (dispositivos de hardware e drivers com as informações do tipo, fabricante, capacidade, endereços usados, quantidade de dados que foram enviados e recebidos por cada interface de rede, bytes lidos e gravados em uma determinada partição e assim por diante).

    Os arquivos do /sys têm a função de facilitarem a troca de informações entre os programas que rodam no espaço do kernel, como os drivers, com os programas que rodam no espaço do usuário (aplicações). As informações geradas automaticamente pelo kernel permitem que diversos programas façam sua leitura, verifiquem as configurações do sistema ou ainda modifiquem o funcionamento de dispositivos do sistema através da alteração dos arquivos lá existentes. Ou seja, é um mecanismo de exportação das estruturas de dados do kernel, seus atributos e ligações, para o espaço do usuário. Por exemplo, quando um dispositivo é adicionado ao sistema, o kernel cria um nome de dispositivo em /sys, e notifica o utilitário udev, o qual gerencia os nomes de dispositivos dinamicamente, criando então um arquivo de dispositivo, geralmente em /dev.

    Observações:

    • a) as entradas em /sys são criadas através do kernel e pelos drivers. O usuário não deve criar entradas através de linhas de comando.
    • b) o sysfs é semelhante ao mecanismo de sysctl encontrada em sistemas BSD, mas implementado como um sistema de ficheiros em vez de um mecanismo separado.
    • c) exemplos de alguns subdiretórios contidos em /sys e suas funções:
      • /sys/bus – contém as informações para os diversos barramentos presentes no sistema.
      • /sys/module – módulos carregados no kernel. Cada pasta contém informações e configurações para cada módulo em particular.
      • /sys/devices – todos os dispositivos conectados.
      • /sys/block – contém links para os arquivos do sysfs referentes a cada dispositivo de bloco.
      • /sys/power – contém informações sobre o estado da energia, o número de vezes que o sistema hibernou/dormiu, etc.
      • /sys/fs – informações e configurações pertinentes a cada sistema de arquivos montado, organizado por tipo de sistema de arquivos. Isto significa que há uma pasta intitulada “ext4” que detém as pastas para cada dispositivo/partição com ext4.
      • /sys/firmware – contém informações e configuração para os firmwares residentes.
      • /sys/dev/ – exitem dois subdiretórios: “block” e “char” os quais direcionam os usuários para os dispositivos de “block” (como os HDs) e “character” (como os teclados) respectivamente.
      • /sys/class – contém pastas nomeadas por tipo de dispositivo como “printers”, “sound”, “mem”, “leds”, “input”, etc. Os subdiretórios contêm atalhos para os arquivos sysfs que pertencem ao dispositivo selecionado. Isto é útil para quando um usuário está procurando um dispositivo específico.

    Identificação de dispositivos PCI
    A identificação de um dispositivo PCI é realizada através de 32 bits, da seguinte maneira: dddd:bb:dd:f 16 bits para domínio; 8 bits para o barramento; 5 bits para o device; e 3 bits para identificar as funções.

    onde:
    – cada domínio pode receber até 256 barramentos;
    – cada barramento pode receber até 32 devices;
    – cada device pode ter até 8 funções. Todos os devices têm ao menos 1 função, a função #0. Qualquer device que tenha mais que 1 função é chamado de dispositivo “multi-function”.

    A junção de barramentos é realizada por meio de pontes (bridges), que são periféricos PCIs especiais. Uma maneira simples de ter acesso a identificação dos periféricos é através do comando lspci. Na verdade, o comando lspci utiliza os arquivos abaixo de /proc/bus/pci/devices como sua fonte de informação. Para conseguir utilizar este comando, verifique se o pacote a seguir está instalado (caso não esteja, faça sua instalação):
    $ apt-cache policy pciutils

    Exemplo de informações sobre os barramentos PCI de uma máquina e os devices que estão conectados a eles:

    $ lspci -nn
    00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02)
    00:01.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express x16 Root Port [8086:0045] (rev 02)
    00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05)
    00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05)
    00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 05)
    00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05)
    00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 [8086:3b4a] (rev 05)
    00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 05)
    00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev a5)
    00:1f.0 ISA bridge [0601]: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller [8086:3b09] (rev 05)
    00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller [8086:3b29] (rev 05)
    00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 05)
    00:1f.6 Signal processing controller [1180]: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem [8086:3b32] (rev 05)
    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT215 [GeForce GT 335M] [10de:0caf] (rev a2)
    01:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be4] (rev a1)
    02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller [10ec:8172] (rev 10)
    03:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8131 Gigabit Ethernet [1969:1063] (rev c0)
    ff:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers [8086:2c62] (rev 02)
    ff:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2d01] (rev 02)
    ff:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2d10] (rev 02)
    ff:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 [8086:2d11] (rev 02)
    ff:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved [8086:2d12] (rev 02)
    ff:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved [8086:2d13] (rev 02)
    

    Fazendo a leitura da resposta acima:

    1. Por padrão, o comando lspci suprime a identificação do domínio em máquinas que possuam apenas um único domínio (o “domain 0”). Para se ter a leitura completa incluindo o domínio deve-se utilizar o comando “lspci -D“;
    2. Vemos os barramentos 00, 01, 02, 03 e ff na resposta acima. Ou seja, esta máquina possui 5 barramentos.
    3. Por exemplo, podemos entender a sequência “0000:ff:00.1” mostrada acima da seguinte forma: 0000 : PCI domain (cada domínio pode conter até 256 PCI barramentos) ff : o número do barramento onde o device está instalado 00 : o número do device .1 : a função do PCI device
    4. Mas….de onde o comando lspci obtém a identificação dos devices? O comando lspci faz a leitura através das entradas em sysfs (veja mais adiante neste post) e decodifica os números do “vendor” e do “device” usando as informações do “vendor” e “device” de /usr/share/hwdata/pci.ids (utilizando-se da biblioteca libpci3). Se tiver curiosidade, veja através do comando cat /usr/share/hwdata/pci.ids | less

    No comando “lspci -nn” acima, para cada device, existia um par de números no formato [xxxx:yyyy] que identificava o dispositivo. Este par sigifica o [vendor:deviceID]. Por exemplo, acima pode ser visto um par com a identificação [8086:2d11] o que significa o vendor=”Intel” e o device=”1st Generation Core i3/5/7 Processor QPI Physical 0″ (veja a lista de devices para o vendor Intel em The PCI ID Repository). Para uma verificação rápida de compatibilidade dos devices PCI com o Debian, uma página interessante a ser acessada é a Debian GNU/Linux device driver check page. De forma mais geral, de três a cinco registros identificam um device PCI: vendorID, deviceID e class são três destes registros que sempre são utilizados.  Todo fabricante de placas PCIs atribui valores próprios para estes registros de apenas leitura, e o BIOS e o driver pode usá-lo para identificar o dispositivo que está instalado. Adicionalmente, os campos subsystem vendorID e subsystem deviceID são algumas vezes utilizados pelo vendedor para diferenciação de dispositivos similares. Veja mais detalhes e a lista dos identificadores de PCI em PCI Devices ou em PCIdatabase.com. Por exemplo, observe:
    $ lspci -n | tail -1
    ff:02.3 0600: 8086:2d13 (rev 02)

    Podemos entender esta sequência de números da seguinte forma:

    Campo 1 : ff:02.3 : número do barramento (ff), número do device (02) e função (3)
    Campo 2 : 0600 : device class
    Campo 3 : 8086 : vendor ID
    Campo 4 : 2d13 : device ID

    Onde:

    • vendorID: identifica o fabricante do hardware.  Por exemplo, todo dispositivo Intel é marcado com o mesmo número, 0x8086.  Este 16-bit vendor ID é padronizado por um consórcio de fabricantes estabelecidos no ano de 1994.
    • deviceID: é escolhido pelo fabricante, sem existir um registro oficial e geral para isto.
    • class: cada dispositivo periférico pertence a uma classe. É identificado por um valor de 24bits, onde os dois octetos mais elevados identifica a “base class” (ou grupo) e os dois octetos seguintes a “sub-class”. Veja a lista padronizada de classes PCI em PCI Device Classes. Por exemplo, “ethernet” (subclasse 00) e “token ring” (subclasse 01) pertencem a classe “Network controller” (classe 02), enquanto “parallel” (subclasse 01) e “serial” (subclasse 00) pertencem a classe “Communication controllers” (classe 07). Os drivers podem contar com os registros de class para identificar seus periféricos.

    O kernel do Linux representa os PCI devices como pseudo-devices no “sysfs file system“:

    $ ls -la /sys/bus/pci/devices
    lrwxrwxrwx 1 root root 0000:00:00.0 -> ../../../devices/pci0000:00/0000:00:00.0
    lrwxrwxrwx 1 root root 0000:00:01.0 -> ../../../devices/pci0000:00/0000:00:01.0
    lrwxrwxrwx 1 root root 0000:00:1a.0 -> ../../../devices/pci0000:00/0000:00:1a.0
    lrwxrwxrwx 1 root root 0000:00:1b.0 -> ../../../devices/pci0000:00/0000:00:1b.0
    lrwxrwxrwx 1 root root 0000:00:1c.0 -> ../../../devices/pci0000:00/0000:00:1c.0
    lrwxrwxrwx 1 root root 0000:00:1c.1 -> ../../../devices/pci0000:00/0000:00:1c.1
    lrwxrwxrwx 1 root root 0000:00:1c.4 -> ../../../devices/pci0000:00/0000:00:1c.4
    lrwxrwxrwx 1 root root 0000:00:1d.0 -> ../../../devices/pci0000:00/0000:00:1d.0
    lrwxrwxrwx 1 root root 0000:00:1e.0 -> ../../../devices/pci0000:00/0000:00:1e.0
    lrwxrwxrwx 1 root root 0000:00:1f.0 -> ../../../devices/pci0000:00/0000:00:1f.0
    lrwxrwxrwx 1 root root 0000:00:1f.2 -> ../../../devices/pci0000:00/0000:00:1f.2
    lrwxrwxrwx 1 root root 0000:00:1f.3 -> ../../../devices/pci0000:00/0000:00:1f.3
    lrwxrwxrwx 1 root root 0000:00:1f.6 -> ../../../devices/pci0000:00/0000:00:1f.6
    lrwxrwxrwx 1 root root 000:01:00.0 -> ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
    lrwxrwxrwx 1 root root 0000:01:00.1 -> ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1
    lrwxrwxrwx 1 root root 0000:02:00.0 -> ../../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0
    lrwxrwxrwx 1 root root 0000:03:00.0 -> ../../../devices/pci0000:00/0000:00:1c.1/0000:03:00.0
    lrwxrwxrwx 1 root root 0000:ff:00.0 -> ../../../devices/pci0000:ff/0000:ff:00.0
    lrwxrwxrwx 1 root root 0000:ff:00.1 -> ../../../devices/pci0000:ff/0000:ff:00.1
    lrwxrwxrwx 1 root root 0000:ff:02.0 -> ../../../devices/pci0000:ff/0000:ff:02.0
    lrwxrwxrwx 1 root root 0000:ff:02.1 -> ../../../devices/pci0000:ff/0000:ff:02.1
    lrwxrwxrwx 1 root root 0000:ff:02.2 -> ../../../devices/pci0000:ff/0000:ff:02.2
    lrwxrwxrwx 1 root root 0000:ff:02.3 -> ../../../devices/pci0000:ff/0000:ff:02.3
    

    Para obter informações mais detalhadas sobre o device, basta ir ao diretorio do dispositivo e listar as entradas do pseudo-device. Por exemplo:

    $ cd /sys/bus/pci/devices/0000:02:00.0
    $ cat vendor 0x10ec
    $ cat device 0x8172
    $ cat class 0x028000

    3- Outros comandos correlatos
    dmesg   – O hardware detectado no boot fica regristrado no arquivo dmesg. Exibe todo o log do dmesg.
    dmesg | less  – com parada por páginas.
    dmesg | grep hd   – refinar a pesquisa com grep, exibir somente resultados que contenha hd (se máquinas com devices SCSI, procurar por sd).
    dmesg | grep -i eth   – procurar pela placa de rede (eth)
    lspci – lista todos os barramentos e devices PCI
    lspci -v   – aumenta o detalhamento, usando o modo verbose, acrescentando -v ou -vv
    lspci -vv
    /sbin/lspci -vv
    lspci -vv | grep -i audio
    lspci | grep VGA
    lspci -vs|ns 0:1:0.1 – lista a informação do dispositivo do domínio 0, barramento 1, slot 0 e função 1.
    lsusb -v   – mostrar informações sobre os barramentos USB da máquina e sobre os devices conectados a eles. Chave -v “verbose” (resultado expandido em detalhes).
    hwinfo – obter informações do harware.
    hwinfo –<hw_item>  onde hw_item pode ser: all, bios, block, bluetooth, braille, bridge, camera, cdrom, chipcard, cpu, disk, dsl, dvb, fingerprint, floppy, framebuffer, gfxcard, hub, ide, isapnp, isdn, joystick, keyboard, memory, modem, monitor, mouse, netcard, network, partition, pci, pcmcia, pcmcia-ctrl, pppoe, printer, scanner, scsi, smp, sound, storage-ctrl, sys, tape, tv, usb, usb-ctrl, vbe, wlan, zip
    lshw – um utilitário que provê informações detalhadas sobre o hardware.
    lshw -html > lshw-arquivo.html   – gerar página em HTML com informações da máquina.
    cat /proc/meminfo – tamanho e uso da memória RAM
    free -m  – free -m  mostra a quantidade de memória RAM livre e em uso no sistema
    top – mostra os processos da CPU, dando detalhes da ocupação da CPU, da memória e outros.

    4- Veja mais:
    1- Guia do Hardware
    2- Livro: Descobrindo o Linux, de João Eriberto Mota Filho
    3- Livro: Linux Device Drivers
    4- Mini distro específica para testes de hardware
    5- Hardware – FAQ, tutoriais, documentação e indicações
    6- Entendendo melhor como funcionam os drivers em máquinas Linux
    7- sysfs
    8- What is the difference between procfs and sysfs?

    Algumas vezes acontece que quando fazemos a instalação de um sistema operacional GNU/Linux em uma máquina algumas interfaces não funcionam “de primeira”. Típico exemplo disto é o não funcionamento da interface wifi, que pode necessitar da instalação de um determinado driver proprietário. Especialmente na distribuição Debian que preza por todos os softwares terem qualidade e serem 100% livres, os drivers proprietários não estão incluídos entre aqueles softwares da sua imagem ISO dos CDs ou DVDs de instalação.

    Este texto visa dar uma compreensão melhor do que fazer nestes momentos.

    1) O papel do dispositivo driver (“device driver”)

    O papel de um módulo (driver) é estender a funcionalidade do kernel. Ainda mais, o papel do dispositivo driver é prover mecanismos, e não a política. Por exemplo, o driver de floppy é livre de políticas: seu papel é apenas mostrar o disquete como um contínuo array de blocos de dados.  Níveis mais altos provêem as políticas, tais como quem pode acessar o driver de floppy, se o driver é acessado diretamente ou via um filesystem e se os usuários podem montar o filesystem no driver.  Um driver é flexível, oferecendo acesso ao hardware sem adicionar restrições.

    Um módulo (driver) é executado no espaço do kernel.  Uma aplicação é executada no espaço do usuário. No mundo Unix, o kernel é executado no mais alto nível (chamado modo supervisor), onde tudo é permitido, enquanto as aplicações são executadas no nível mais baixo (também chamado modo usuário), onde o processador regulamenta o acesso direto ao hardware e o acesso não autorizado à memória.

    Uma das boas características do Linux é a habilidade de estender o conjunto de facilidades oferecido pelo kernel.  Cada pedaço de código que pode ser adicionado ao kernel em tempo de execução é chamado um módulo. O Linux diferencia três tipos de dispositivos fundamentais: char module, block module e network module.  Mas isto não é rígido. O console de texto (/dev/console) e as postas seriais (/dev/ttyS0 e correlatas) são exemplos de char devices, acessados via device filesBlock devices são acessados também através de device files presentes no diretório /dev. Um  block device é um dispositivo (por exemplo, um disco) que pode hospedar um filesystem.  Já o módulo (ou interface) de rede não é facilmente mapeado através de um device file , como é o /dev/tty1.  A maneira Unix de provê acesso à interfaces é ainda atribuindo um único nome para elas (tal como eth0), porém este nome não tem uma entrada correspondente no filesystem.

    Existem ainda outros tipos de módulos drivers. Cada dispositivo USB é controlado por um módulo USB que trabalha com o subsistema USB, porém o próprio dispositivo mostra-se no sistema como um char device (se for uma porta serial USB), um block device (se for um leitor de cartão de memória USB) ou um network device (se for uma interface USB Ethernet).

    2) Níveis de suporte do Kernel

    O kernel Linux não suporta completamente todos os dispositivos de I/O.  Em termos gerais, existem três possíveis tipos de suporte aos dispositivos de hardware:

    Absolutamente sem suporte

    O programa aplicativo interage diretamente com as portas de I/O do device mediante a emissão correspondente de instruções em linguagem assembly. O exemplo mais comum deste tipo, que não depende de qualquer driver de dispositivo do kernel, é como o “X Window System” tradicionalmente lida com a tela gráfica. Isto tem uma explicação histórica, que vem dos tempos em que o Unix fora introduzido. Naqueles tempos, terminais gráficos eram raros e muito caros, fazendo com que apenas terminais alfanuméricos fossem manipulados diretamente por Kernels Unix.  Quando os terminais gráficos se tornaram difundidos, aplicações ad hoc foram introduzidas, tal como o “X Windows System” (que foi um projeto independente em sua origem *). O “X Windows System” já tinha seus processos padronizados e acessava de forma direta as portas de I/O da interface gráfica e a memória RAM de vídeo.

    Outro exemplo deste tipo de suporte são as interfaces de rede. A placa de rede já empacota seu controlador, que segue padronizações de rede bem definidos (que existem vários, entre eles a Ethernet que atualmente é a mais comum).

    (*) O X Windows foi um projeto criado pelo MIT em 1984. Com o passar do tempo, surgiram variantes deste projeto, como o XFree86 e o X.Org.  O X.Org, por exemplo, surgiu em 1999 como uma reação à mudança da licença do X Windows.

    Suporte Mínimo

    O kernel não reconhece o “device hardware“, mas reconhece sua interface de I/O. Programas dos usuários são capazes de tratar a interface como um dispositivo sequencial capaz de ler e/ou escrever sequencias de caracteres. É usada para manipular os dispositivos de hardware externos conectados a uma interface de I/O de propósito geral. O kernel cuida da interface I/O, oferecendo um “arquivo de dispositivo” (e, portanto, um “driver de dispositivo”), e o programa aplicativo lida com o dispositivo de hardware externo, lendo e escrevendo o arquivo de dispositivo.

    Suporte Mínimo é preferível em relação ao Suporte Estendido, pois contribui para um kernel enxuto.  Exemplos são as portas seriais e paralelas, que são utilizadas por mouses seriais e modem seriais, por exemplo. Nestes casos, os mouses seriais são controlados diretamente pelo programa aplicativo (tal como o servidor X) e os modems necessitam de um programa de comunicação ou um daemon de protocolo ponto-a-ponto (PPP).

    Suporte Estendido

    O kernel reconhece o dispositivo hardware e manipula a interface de I/O por si mesmo. De fato, pode até não existir um “arquivo de dispositivo” para o dispositivo. Esse tipo de suporte é o mais genérico e são necessários para aqueles dispositivos com forte acoplamento com o SO. Neste tipo de suporte, o kernel provê um device driver para cada device. Dispositivos externos conectados à USB, à porta PCMCIA ou à interface SCSI requerem o suporte extendido.

     

    3) Sistemas de Arquivos no Debian
    O sistema Debian fornece o sistema de arquivos sob o qual os dados físicos em discos rígidos e outros dispositivos de armazenamento, e a interação com os dispositivos de hardware como telas de console e consoles seriais remotos são representados em uma forma unificada. Cada arquivo, diretório, pipe nomeada, ou dispositivo físico em um sistema Debian tem uma estrutura de dados chamada “inode” que descreve seus atributos associados como o usuário que é seu dono, o grupo ao qual pertence, a hora do último acesso, etc..

    Essa representação unificada de entidades físicas é muito poderosa já que nos permite usar o mesmo comando para o mesmo tipo de operação em muitos dispositivos totalmente diferentes.

    4) Arquivos de dispositivos (“device files“) no GNU/Linux
    Arquivos de dispositivos se referem a dispositivos físicos ou virtuais em seu sistema, tais como seu disco rígido, sua placa de vídeo, monitor, ou teclado. Um exemplo de dispositivo virtual é o teclado, representado pelo /dev/console.

    No sistema operacional Linux tudo é baseado na noção de arquivos, seja um conjunto de dados ou um periférico do computador (como um HD, impressora,etc). Neste sentido, dispositivos de entrada/saída (I/O) são tratados como arquivos especiais chamados arquivos de dispositivos (“device files“). O diretório /dev contém estes arquivos de dispositivos que servem de comunicação com os dispositivos de hardware (“devices“) e periféricos do computador (discos rígidos, mouses, etc.). Estes arquivos têm influência direta quando do “boot” do sistema. Na prática, representam os dispositivos hardware do computador.

    Um arquivo de dispositivo está associado com um dispositivo hardware (tal como um HD, por exemplo, /dev/sda) ou com alguma porção física ou lógica do dispositivo hardware (tal como uma partição do disco, por exemplo, /dev/sda2). Por exemplo, quando executamos o comando “less -f /dev/sda“, de fato fazemos a leitura diretamente do primeiro HD físico da máquina. Os nomes destes arquivos em /dev é arbitrária e é escolhida por conveniencia e consistência.

    É importante distinguir estes “arquivos de dispostivos” dos “arquivos de drivers”. Os arquivos de dispositivos são simplesmente pontos de encontro usados para comunicação do sistema operacional com os drivers. Eles não são os drivers em si. Um driver de dispositivo, também chamado de módulo de dispositivo, cuida dos detalhes específicos de gerenciamento direto do dispositivo hardware.

    Exemplos de arquivos de dispositivos:

    Nome             Tipo   Major Minor Descrição
    /dev/fd0         bloco    2    0    Floppy disk
    /dev/hda         bloco    3    0    Primeiro disco IDE
    /dev/hda2        bloco    3    2    Segunda partição primária, primeiro disco IDE
    /dev/hdb         bloco    3    64   Segundo disco IDE
    /dev/hdb3        bloco    3    67   Terceira partição primária, segundo disco IDE
    /dev/sdb         bloco    8    0    Segundo disco SCSI
    /dev/ttyp0       char     3    0    Terminal
    /dev/console     char     5    1    Console (terminais não-gráficos)
    /dev/lp1         char     6    1    Impressora paralela
    /dev/ttyS0       char     4    64   Primeira porta serial
    /dev/rtc         char     10   135  Clock de tempo-real
    /dev/null        char     1    3    Null device

    OBS:
    (a) atualmente as placas-mãe possuem duas interfaces IDE (ou duas SCSI), uma primária e outra secundária. Cada interface tem capacidade de controlar até dois dispositivos hardware (geralmente HD ou CD-ROM);
    (b) os arquivos dos dispositivos de rede não estão representados em /dev, sendo considerado uma exceção.

    Número dos dispositivos:

    Os arquivos de dispositivo vêm com duas identificações básicas:

    (a) o tipo do arquivo de dispositivo, se de bloco (para HW do tipo HD ou CD-ROM), de caracter (para HW do tipo cartões de som ou teclado) ou interface de rede (eth0);
    (b) um par de números: o principal e o secundário (“major number” e “minor number“). O primeiro identifica o tipo do dispositivo, e o segundo número identifica o dispositivo específico dentre um grupo de dispositivos que compartilham o mesmo número principal. Por exemplo, um grupo de discos gerenciados pelo mesmo controlador de disco têm o mesmo número principal e diferentes números secundários. Note que os dispositivos tipo bloco e tipo char têm numerações independentes, tal que o dispositivo de bloco (3,0) é diferente do dispositivo char (3,0).

    Os arquivos de dispositivos em /dev possuem essas identificações. Estes números de dispositivo principal e secundário identificam o dispositivo para o kernel, onde este utiliza esses números para associar referências do arquivo de dispositivo ao driver correspondente. O número de dispositivo principal identifica o driver com o qual o arquivo está associado (ou seja, o tipo de dispositivo). O número de dispositivo secundário identifica qual a instância em particular de um dado tipo de dispositivo deve ser tratada.

    %ls -l /dev/sda*
    $ ls -l sd*
    brw-rw---- 1 root disk 8, 0 Dez 29 17:37 sda
    brw-rw---- 1 root disk 8, 1 Dez 29 17:37 sda1
    brw-rw---- 1 root disk 8, 2 Dez 29 17:37 sda2
    brw-rw---- 1 root disk 8, 3 Dez 29 17:38 sda3
    brw-rw---- 1 root disk 8, 5 Dez 29 17:37 sda5

    Observe pela resposta do sistema:

    • na primeira coluna, a letra “b” representa um block driver.  Quando for o caso de um char driver, a letra presente será “c”.
    • 8 identifica o número de dispositivo principal. Ou seja, todos os discos SCSI possuem “major number” 8.
    • 0, 1, 2, 3 e 5 identificam os números de dispositivos secundários (as unidades). O driver é livre para interpretar o número de dispositivo secundário da maneira que lhe aprouver.

    O registro oficial dos números dos dispositivos e o diretório dos devices file /dev está disponível no sítio do desenvolvimento do kernel do Linux em ftp://ftp.kernel.org/pub/linux/docs/device-list/devices.txt; as macros correspondentes aos “major numbers” dos dispositivos podem ser encontradas no arquivo include/linux/major.h (no Debian em /usr/src/linux-headers–common/include/linux/major.h).

    Criando Arquivos de Dispositivos com o comando mknod

    Apesar que todos os arquivos de dispositivos estarem listados no diretório /dev, em tese pode-se criar um arquivo de dispositivo em qualquer localização do sistema de arquivo através do comando mknod:

    mknod [-m ] [b|c]

    onde:
    (a) as letras ‘b’ e ‘c’ são para criação de “device” de bloco ou character, respectivamente;
    (b) ‘mode‘ é a permissão.

    Exemplo:

    mknod -m 0600 ~/my-floppy b 2 0
    ls -al /dev/fd0 ~/my-floppy

    onde neste caso my-floppy pode ser usado da mesma forma que usamos tradicionalmente a /dev/fd0

    5) Montar um dispositivo
    Para acessar os dados que estão em um dispositivo, no Linux usamos o conceito de montar; assim, quando se coloca um cd no computador, por exemplo, tem-se de ‘montar’ o cd para acessá-lo, isto é, deixar os dados que estão no cd disponíveis para uso. O que o comando mount faz é anexar um sistema de arquivos à árvore atual de arquivos (que forma o atual leiaute geral do sistema de arquivos). O comando mount associa um diretório dentro da árvore de arquivos existente, chamado de ponto de montagem, à raiz do sistema de arquivos recém-chegado. O conteúdo anterior do ponto de montagem se torna inacessível enquanto um outro sistema de arquivos esteja montado nele.

    O comando utilizado para montar dispositivos é o mount, e sua sintaxe básica é:

    mount dispositivo ponto_de_montagem

    Como os dispositivos são tratados como arquivos, será sempre /dev/alguma_coisa!
    Exemplos:

    # mount /dev/fd0 /diretorio_onde_o_disco_vai_ser_montado
    # umount /dev/fd0

    O primeiro comando para montar o disco flexível. O diretório_onde_o_disco_vai_ser_montado tem que existir, e tem que estar totalmente vazio. O segundo comando para desmontar o disco flexível.

    # mount /dev/hda2 /diretorio_onde_o_disco_vai_ser_montado
    # umount /dev/hda2

    O primeiro comando para montar a partição /dev/hda2 (HD número 1, partição número 2). O segundo comando para desmontar a partição.

    # mount /dev/cdrom /mnt/cdrom
    # umount /dev/cdrom

    O primeiro comando monta a unidade de CD-ROM. O segundo realiza a operação inversa. Observe que o arquivo /dev/cdrom é sim um link simbólico para o dispositivo correspondente ao CD-ROM (/dev/srx). Isso quer dizer que se pode substituir o /dev/cdrom pelo /dev/srx tranqüilamente, assim como pode também modificar o link simbólico para apontar para outro dispositivo.

    # mount -t ext3 /dev/sda1 /mnt/diretorio

    Comando para montar a partição raiz de um sistema de arquivos, a partir de um live-CD.

    O arquivo /etc/fstab armazena as configurações de quais dispositivos devem ser montados e qual o ponto de montagem de cada um na inicialização do sistema operacional. Por exemplo, quando o sistema operacional inicia, ele procura no arquivo /etc/fstab para saber onde está a raiz do seu sistema, e vai montar no /.

    Vejamos aqui um exemplo de arquivo /etc/fstab:

    $ cat /etc/fstab
    # <file system>       <mount point>                        <type>                             <options>                             <dump>  <pass>
    proc          /proc             proc           defaults             0    0
    /dev/sda1     /                 ext3           errors=remount-ro    0    1
    /dev/sda3     /home             ext3           defaults             0    2
    /dev/sda5     none              swap           sw                   0    0
    /dev/scd0     /media/cdrom0     udf,iso9660    user,noauto          0    0

    OBS: = checagem de disco. Determina se o dispositivo deve ou não ser checado na inicialização do sistema pelo fsck. É um campo numérico, onde 0 é para não ser checado, 1 é para ser checado primeiro(raiz) e 2 para checar depois do raiz.

    Dentro de cada linha, o primeiro parâmetro (/dev/sda1 por exemplo) indica a partição, o segundo parâmetro indica a pasta onde ela será montada (/, por exemplo), o terceiro indica o sistema de arquivos em que a partição foi formatada (ext3, por exemplo), enquanto o “defaults 0 0” permite definir configurações adicionais. O “default” por exemplo faz com que a partição seja acessada usando as opções padrão, enquanto se fosse utilizado o “noatime” seria uma opção de otimização que faria com que o sistema não atualizasse a data de acesso quando os arquivos fossem lidos, o que resultaria em um pequeno ganho de desempenho.

    A segunda linha é a raiz do sistema, que está na partição /dev/sda1, será montada automaticamente (‘defaults’) no diretório “/” durante a inicialização. E esta partição tem o sistema de arquivos ext3. Na quarta temos a montagem da memória SWAP. E vejamos a linha que começa com /dev/scd0. Aqui facilita as coisas porque os parâmetros ‘user,noauto’ significam que qualquer usuário pode montar o CD-ROM (user) e não é montado automaticamente na inicialização (noauto). Qual a diferença? O comando mount só pode ser usado pelo root, mas com essa opção no /etc/fstab, um usuário comum pode montar o cd-rom apenas com o comando “mount /mnt/cdrom”, ou “mount /dev/cdrom”. Você pode criar suas próprias configurações para dar mais praticidade no seu uso com os dispositivos no Linux! Mexa à vontade, mas nunca nas linhas que já vêm, pois se não o Linux pode não achar sua partição e poderá não conseguir iniciar o sistema.

    Ao instalar outros HDs posteriormente, pode-se fazer com que o sistema passe a usá-las inserindo as linhas apropriadas no arquivo “/etc/fstab”. Em sistemas como Debian e Ubuntu a referência as partições em /etc/fstab não é realizada através do dispositivo. Mas sim pelo UUID, que é um identificador único. Para seguir este padrão adicionar o novo HD em /etc/fstab, faça o seguinte:
    (a) após montar o novo disco (identificando as particições, no caso aqui sdc1), verificar qual é o UUID:

    #blkid /dev/sdc1
    /dev/sdc1: LABEL=”novoHD” UUID=”aae8c256-24a8-4533-b163-5a08ff4a49f0″ TYPE=”ext3″

    (b) especificar o UUID na linha do /etc/fstab no lugar do device:
    UUID=aae8c256-24a8-4533-b163-5a08ff4a49f0 /mnt/scd1 ext3 defaults 0 0

    OBS: deixe sempre uma linha em branco no final do arquivo /etc/fstab.

    6) Módulos (drivers) de Kernel carregáveis

    O kernel contém drivers de dispositivos que gerenciam interação com as peças de hardware específicas. O restante do kernel é, em grande parte, independente do dispositivo. A existência da camada de driver ajuda a manter o Linux relativamente independente de dispositivos. Drivers de dispositivos fazem parte do kernel, não sendo processos de usuários. Porém um driver pode ser acessado tanto de dentro do kernel quanto do espaço do usuário. O acesso em nível de usuário para dispositivos é normalmente fornecido através de arquivos de dispositivos especiais que residem no diretório /dev. O kernel transforma operações nesses arquivos em chamadas para o código do driver.

    Somente drivers de dispositivos para uso com linux (e normalmente, para uma versão específica do kernel Linux) pode ser instalada com sucesso num sistema Linux. Drivers para outros sistemas operacionais (como Windows, por exemplo) não funcionarão.

    Um driver de dispositivo pode ser linkado e removido do kernel a qualquer instante. Essa possibilidade facilita a instalação de drivers, já que o binário do kernel não necessita ser modificado. Também possibilita o kernel ser menor, pois os drivers não são carregados a menos que necessário. Os módulos de kernel carregáveis são armazenados em /lib/modules/version-kernel, onde ‘version-kernel’ é a versão do kernel linux em uso (reportada através do comando ‘uname -r’).

    7) Verificar a interface de rede wifi (Network controller) e seu driver

    O não funcionamento do hardware da interface de rede se encaixa em um dos três casos:
    (a) a placa de rede é incompatível com o sistema linux;
    (b) a placa de rede é incompatível com a versão do kernel Linux; e
    (c) o driver da placa não está disponível no sistema.

    As soluções para cada um dos problemas são:
    (a) adquira uma placa compatível com o sistema Linux;
    (b) atualize o kernel do linux; e
    (c) adquira o módulo (driver) correto do fabricante.

    Passo-1: verificar se algum dispositivo “Network” fora reconhecido pelo linux:

    # lspci | grep "Network"
    02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)

    Vemos neste exemplo que a placa de rede fora reconhecido pelo linux. A placa não teria sido reconhecido pelo sistema Linux caso não houvesse nada como resposta. Neste caso, reinicia-se o dispositivo ou retira-se e coloca-se novamente a placa de rede, caso esta placa seja do tipo “espetada”.

    Passo-2: verificar os detalhes deste dispositivo:


    # lspci -v -s 02:00.0
    02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)
    Subsystem: Device 1a32:0308
    Flags: bus master, fast devsel, latency 0, IRQ 16
    I/O ports at 3000 [size=256]
    Memory at d8100000 (32-bit, non-prefetchable) [size=16K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Legacy Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [140] Virtual Channel
    Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
    Kernel driver in use: rtl819xSE

    Vemos que o módulo (driver) em uso referente a placa é o rtl819xSE.
    Caso não tivesse sido carregado nenhum drive, uma possível resposta ao mesmo comando seria:

    
    02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)
        Subsystem: Quanta Microsystems, Inc Device 0308
        Flags: fast devsel, IRQ 16
        I/O ports at 3000 [size=256]
        Memory at d8100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00

    em cuja resposta pode se observar que não há a indicação do driver em uso, como no caso do primeiro comando.

    Passo-3: verificar os módulos em uso (carregados) no sistema:

    # lsmod
    Module Size Used by
    r8192se_pci 481792 0

    onde pode-se verificar que o módulo (driver) realmente está carregado.

    Passo-4: verificar onde se encontra o módulo armazenado no HD:
    Os módulos (drivers) no sistema Linux possuem o sufixo “.ko”:
    # modprobe --list | grep "r8192"
    kernel/drivers/net/wireless/r8192se_pci.ko

    Ou seja, o endereço completo da localização do driver é: /lib/modules/2.6.32-5-amd64/kernel/drivers/net/wireless/r8192se_pci.ko

    OBS: caso o módulo não tivesse carregado, seria possível carregá-lo usando o comando modprobe ou usando o comando insmod:
    # modprobe r8192se_pci
    # insmod /lib/modules/2.6.32-5-amd64/kernel/drivers/net/wireless/r8192se_pci.ko

    Outros comandos úteis:
    (a) lsmod: lista os módulos atualmente carregados. Trabalha lendo o arquivo /proc/modules.  Informações dos módulos carregados também podem ser encontradas em /sys/module
    (b) insmod: carregar (inserir) manualmente um módulo no kernel.
    (c) rmmod: remover manualmente um módulo carregado no kernel.
    (d) modprobe: carregar/remover de forma semi-automática um módulo kernel. Trata-se de um envoltório para os comandos ‘insmod’ e ‘rmmod’ que compreende as dependências, opções e procedimentos de instalação/remoção. Um arquivo muito importante aqui é o ‘/etc/modules.conf’ev, o qual permite controlar as opções de todos os módulos do sistema.
    (e) depmod: verifica as dependências de um determinado módulo.

    Mais informações:
    1- Unix Devices
    2- Linux Device List
    3- Como habilitar os dispositivos WiFi baseados nos chipsets Intel 3945 and 4965 em sistemas Debian
    4- Intel Wireless Wifi Link Drivers for Linux
    5- Debian Wireless Fidelity
    6- How to use a WiFi interface
    Identificação de dispositivos PCI:
    7- Como identificar os dispositivos PCI de uma máquina
    8- Identificação dos PCI devices
    9- PCIdatabase
    10- Listagem de dispositivos wireless devices com informação sobre o seu chipset, e se são suportados em Linux
    outras publicações neste blog referentes a este assunto:
    11- Instalando driver de dispositivo Wifi no laptop HP Pavilion dv2040 usando o Debian
    12- Configurando as interfaces do laptop LG modelo LGR58, configuração R590, para Debian squeeze
    13- Instalando o adaptador de rede wireless D-Link DWL-G510 no Debian
    14- Entendendo os drivers Linux para arquitetura de barramento PCI

    livros:
    15- Livro: Linux Device Drivers