Orange Pi 2G-IOT: mapa do campo minado

Há algum tempo, me ofereceram a trabalhar um pouco com um PC de placa única Orange Pi 2G-IOT (2G embutido e o preço parece muito atraente). Depois de ler um post sobre o Orange Paradise , pensei em repetir esse caminho sem dificuldade, principalmente porque no Linux estou no “você” (ou melhor, pensei há três semanas) e já tinha experiência com o Raspberry Pi 2 B +. Na prática, esse caminho acabou sendo muito mais longo. Havia um sentimento de que nossos amigos chineses criavam intencionalmente dificuldades (e às vezes com cinismo especial). Se você deseja salvar e comprar este quadro, leia primeiro este post e pense novamente.

Se possível, tentarei conter as emoções ou, pelo menos, traduzi-las em humor.
Então, aqui eu recebo uma placa e um cartão SD da décima série. Vamos lá

Tudo escrito abaixo se refere ao modelo Orange Pi 2G-IOT, mas no bate-papo do Telegram (procure “Orange Pi e não apenas”) eles dizem que os modelos 2G, 3G e 4G se comportam da mesma maneira (igualmente ruim). O escrito NÃO se aplica, por exemplo, ao Orange Pi PC e ao Orange Pi One, que, de acordo com as análises, se comportam de maneira estável.

Mina No. 1 (treinamento): baixando a imagem do SO

Parece que poderia ser mais fácil? Vamos ao site do fabricante e fazemos o download. No entanto, todos os links levam ao mega.nz, que o coleta diretamente no navegador. Meu laptop barato com 4 GB de RAM não executou essa tarefa e a guia caiu. Pode-se usar um programa proprietário para fazer o download do Mega, mas isso não inspira confiança em mim (tanto mais que algumas pessoas escrevem na Internet que o programa é reconhecido pelos antivírus como malware). Opções de solução: faça o download de um site não oficial (por exemplo, aqui ), implante uma máquina virtual e coloque um cliente para fazer o download do Mega, peça a alguém com um PC mais moderno para baixar a imagem.

Mina No. 2: Acesso à Internet via modem

Após a configuração literal de wvdial e pppd na Internet, repentinamente descobri que as solicitações de ping estavam passando bem, mas os pacotes TCP regulares não eram de forma alguma:

orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32 curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32 curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out orangepi@OrangePi:~$ curl --interface ppp0 195.201.201.32 curl: (7) Failed to connect to 195.201.201.32 port 80: Connection timed out orangepi@OrangePi:~$ curl --interface wlan0 195.201.201.32 46.0.208.54 orangepi@OrangePi:~$ ping 195.201.201.32 -I ppp0 PING 195.201.201.32 (195.201.201.32) from 10.33.64.21 ppp0: 56(84) bytes of data. 64 bytes from 195.201.201.32: icmp_seq=1 ttl=52 time=664 ms 64 bytes from 195.201.201.32: icmp_seq=2 ttl=52 time=240 ms 64 bytes from 195.201.201.32: icmp_seq=3 ttl=52 time=234 ms 64 bytes from 195.201.201.32: icmp_seq=4 ttl=52 time=246 ms 64 bytes from 195.201.201.32: icmp_seq=5 ttl=52 time=241 ms 64 bytes from 195.201.201.32: icmp_seq=6 ttl=52 time=237 ms ^C --- 195.201.201.32 ping statistics --- 7 packets transmitted, 6 received, 14% packet loss, time 6032ms rtt min/avg/max/mdev = 234.634/310.971/664.998/158.370 ms orangepi@OrangePi:~$ 

A solução levou o edtun : https://www.linux.org.ru/forum/admin/12135523 , embora eu admita que poderia ter sido de alguma forma mais simples.

Alertou imediatamente que o modem IMEI está repleto de zeros. Felizmente, o operador de telecomunicações vermelho-branco não presta atenção nisso. (A propósito, o Wi-Fi embutido da mesma forma não possui um endereço MAC: é gerado aleatoriamente a cada movimento da fonte de alimentação.)

Mina No. 3: Porta USB

Colocamos um apito de WiFi no conector USB e ... Nada acontece. LSUSB exibiu uma porta USB vazia. Uma pequena escavação mostrou que a placa realmente tem apenas um USB. E, por padrão, ele está conectado à porta microUSB. Para alternar para um USB HOST normal, é necessário alternar os jumpers na placa, localizados ao lado do jumper para selecionar a inicialização. A descrição deles está em w3bsit3-dns.com:
Solução: coloque os jumpers na posição: 1234 para baixo, 5678 para cima.

Só então encontrei uma pequena menção a essa nuance no manual do Orange Pi.

Mina No. 4: Motoristas

Agora, o dispositivo foi detectado no sistema, lsusb exibe o código do fabricante e do produto, mas a interface de rede sem fio não é detectada no sistema. Porque os desenvolvedores não entregaram drivers para adaptadores WiFi em laranja. E nenhum. Há um driver apenas para WiFi embutido, nem mais nem menos. E o que fazemos quando não temos um driver para o nosso hardware? É isso mesmo, vamos colecioná-los a partir do código fonte !

Mina 5: Preparando-se para construir

Em correspondência, bad__day sugeriu a montagem diretamente no Orange Pi. Talvez isso seja possível, mas eu falhei.

Para o Orange Pi, os desenvolvedores criaram um Sistema de Compilação Orange Pi especial, com o qual, em teoria, para construir um kernel ou módulos, basta seguir as instruções na tela. Instruções detalhadas são fornecidas no manual, começando na página 61. Parece que basta seguir, e tudo vai ficar bem, mas não.

Primeiramente, para não editar manualmente todas as dependências do meu computador (eu atualizo regularmente o software, isso é ótimo, mas não desta vez), implantei uma máquina virtual com o Ubuntu 16.04 e realizei todas as ações lá. Em segundo lugar, ocorreu um erro nos scripts em algum lugar, e o Build System não colocou uma cadeia de ferramentas para compilação entre plataformas. Isso é resolvido com uma muleta:

1. O apt-get'om manualmente coloca a cadeia de ferramentas para compilação cruzada no ARM.
2. Fazendo links simbólicos:

    mkdir $HOME/OrangePiRDA/toolchain/bin ln -s $(which arm-linux-gnueabi-ld) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ld ln -s $(which arm-linux-gnueabi-gcc-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-gcc ln -s $(which arm-linux-gnueabi-g++-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-g++ ln -s $(which arm-linux-gnueabi-ar) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ar ln -s $(which arm-linux-gnueabi-nm) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-nm ln -s $(which arm-linux-gnueabi-objcopy) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-objcopy ln -s $(which arm-linux-gnueabi-size) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-size 

   Por favor note: o compilador está na versão 4.9, nada será coletado nas versões acima.
3. Abra o OrangePiRDA / scripts / Prepare_toolchain.sh e, por precaução, comente as linhas que mencionam a cadeia de ferramentas.

De fato, todos esses scripts chamam apt-get install -y ... e make. O script não oferece ao usuário a alteração da configuração de forma alguma (ou não a encontrei?).

Mas, afinal, nada nos impede de nos chamarmos

 make menuconfig 

e marque os drivers necessários. Fazemos isso e coletamos novamente (agora apenas os módulos são possíveis) e ...

Mina nº 6 (com um sensor de movimento infravermelho parafusado e um detonador de reposição): Montagem do driver

... E então o script começou a fazer perguntas sobre como configurar o kernel. Ele chamou o configurador antiquado do kernel, mas por quê ?! O que está errado?

Descobriu-se que o Makefile foi escrito para verificar as alterações na configuração TIME (!!!)!



O comentário diz literalmente "alguém estava cavando". (Na captura de tela, o Makefile já modificado, registrei o menuconfig.) Tentei ligar para make oldconfig, não percebi que isso mudava alguma coisa em algum lugar. Ok, agora após o menuconfig ser chamado durante a montagem, não é assustador. Eu ligo para a montagem novamente, a montagem percebe que “alguém estava acessando a configuração”, chama menuconfig, saio e espero a conclusão. Agora imagine minha surpresa quando não encontrei o driver que selecionei.


Bem, subimos para entender. Acontece que o make cria o arquivo modules.order, que descreve todos os módulos que serão compilados. E mesmo após todas as alterações de configuração e salvamento, esse arquivo é preenchido com o mesmo conjunto. Eu não criei nada melhor do que adicionar linhas manualmente a ele (meu apito é montado no chipset RTL8192CU):

 kernel/driver/net/wireless/rtlwifi.ko kernel/driver/net/wireless/rtlwifi/rtl8192cu.ko 

Todas as referências a esse arquivo no Makefile foram substituídas por modules.order.fake. Eu começo a montagem. Desta vez, a montagem foi interrompida, pois não há arquivo semelhante na pasta de código-fonte rtlwifi. Renomeei os arquivos modules.order.fake para modules.order nesta pasta e subpastas, e essa foi minha última aventura na criação do driver. Depois disso, o sistema me mostrou o menuconfig mais duas vezes, como se perguntasse "você realmente quer isso?", Mas ainda assim coletou outros três arquivos .ko valiosos, que foram concluídos conforme o esperado.

Mina No. 7: Trabalho conjunto de um Wi-Fi externo e um modem

Depois de brincar um pouco com o airodump e garantir que o dispositivo possa pelo menos capturar pacotes no modo monitor, decidi verificar o modem novamente. Fazendo

 sudo wvdial 

E o LED do adaptador WiFi externo apaga e o SSH cai. Depois li nos logs que o adaptador foi desconectado. O primeiro pensamento é o problema da nutrição. Até aquele momento, eu usava meu carregador por 1,5 A e o fabricante recomenda até 3 (onde tanto? Ela nem come um A ). Na mão estava um carregador de 2 ampères, que durante anos alimentava regularmente o Raspberry Pi.

No momento, não encontrei nenhuma solução estável para esse problema. Aqui estão algumas tentativas de solução:

• Com uma probabilidade de 80%, você pode desativar o Wi-Fi externo usando:
  
  

   chmod 777 /sys/bus/usb/drivers/usb/unbind echo 1-1 > /sys/bus/usb/drivers/usb/unbind 

  
  e execute wvdial, que tentará estabelecer uma conexão com 1 a 3 tentativas e você poderá ficar online. Em 20% de todos os tipos de travamentos e falhas.
• Uma vez, por acaso, descobriu-se que o wvdial foi morto, mas o pppd continuou funcionando (como poderia ser?), Após o qual o WiFi externo aumentou (veja acima, escrevemos bind em vez de unbind) e houve uma conexão através do modem. Não foi possível reproduzir a situação.
• Aconteceu que, sem reconstruir o kernel, você pode desligar a energia do USB usando esse utilitário com o comando
  
  

   ./hub-ctrl -h 0 -P 1 -p 0 

  
  e ligue a energia

   ./hub-ctrl -h 0 -P 1 -p 1 

  No 2G-IOT, o comportamento é imprevisível: uma queda de energia pode ser por um segundo ou antes de uma reinicialização. Em algumas fases da lua, uma tentativa de retornar a energia faz com que o painel congele.
• Mude os jumpers para OTG (1234 para cima, 5678 para baixo), aplique energia às pernas do GPIO 2 e 6 (toque, eles estão diretamente conectados à energia microUSB)
  
  
  Pinagem

  
  
  
  Conecte o adaptador WiFi através do adaptador USB-OTG do smartphone. O sistema não vê o dispositivo USB. Talvez você precise jogar com mais persistência com os jumpers.
  

Não testado, mas pode funcionar (planeja tentar todas essas opções):

• Outro adaptador WiFi.
• Fonte de alimentação muito estável com uma corrente máxima de 3 Amperes.
• Potência extra para os pés USB.
• Gasolina e fósforos.

Em geral, a tarefa parece puxar um cobertor triangular sobre uma laranja quadrangular.

Por enquanto é tudo.



UPD: Hoje eles me trouxeram uma fonte de alimentação com uma saída de 5V 3A. Com isso, conseguimos iniciar simultaneamente o modem e o adaptador USB WiFi. O modem polvilha com erros, para de responder, mas em média se conecta a partir da terceira tentativa. Depois disso, você pode usar o USB WiFi.

Para resumir.

A placa-mãe Orange Pi 2G-IOT é muito simples e quase não é suportada pelo fabricante. Mesmo em coisas simples, onde parece que nada indica problemas, algo pode dar errado. Se você precisar usar um dispositivo com acesso à Internet por uma rede móvel e não tiver certeza de que pode lidar com o Orange Pi, é melhor pagar mais e levar algo mais confiável e depurado. Economize tempo e nervosismo.