Orange Pi 2G-IOT: mapa del campo minado



Hace algún tiempo, me ofrecieron trabajar un poco con una PC de una sola placa Orange Pi 2G-IOT (2G incorporado y el precio parece muy atractivo). Después de leer una publicación sobre el paraíso naranja , pensé que repetiría este camino sin ninguna dificultad, especialmente porque con Linux estoy en el "tú" (o más bien, pensé hace tres semanas) y ya tenía experiencia con Raspberry Pi 2 B +. En la práctica, este camino resultó ser mucho más largo. Parecía que nuestros amigos chinos creaban deliberadamente dificultades (y a veces con un cinismo especial). Si desea guardar y comprar este tablero, primero lea esta publicación y piense de nuevo.

Si es posible, intentaré contener las emociones o al menos traducirlas en humor.
Entonces, aquí tengo una placa y una tarjeta SD del décimo grado. Vamos

Todo lo que se escribe a continuación se refiere al modelo Orange Pi 2G-IOT, pero en el chat de Telegram (busque “Orange Pi y no solo”) dicen que los modelos 2G, 3G y 4G se comportan de la misma manera (igualmente malo). Lo escrito NO se aplica, por ejemplo, a la PC Orange Pi y Orange Pi One, que, según las revisiones, se comportan de manera estable.

Mina No. 1 (entrenamiento): descargando la imagen del sistema operativo


Parece que podría ser más fácil? Vamos al sitio web del fabricante y lo descargamos. Sin embargo, todos los enlaces conducen a mega.nz, que lo recopila directamente en el navegador. Mi computadora portátil barata con 4 GB de RAM no realizó esa tarea y la pestaña cayó. Se podría usar un programa propietario para descargar desde Mega, pero no me inspiró confianza (sobre todo porque algunas personas escriben en Internet que el programa es reconocido por los antivirus como malware). Opciones de solución: descargue de un sitio no oficial (por ejemplo, aquí ), implemente una máquina virtual y coloque un cliente para descargar de Mega, solicite a alguien con una PC más moderna que descargue la imagen.

Un poco más sobre los sistemas operativos para naranja
Para muchos modelos de Orange, los usuarios recomiendan Armbian, pero no me impresionó con 2G-IOT: parece Raspbian minimalista. Por cierto, no hay imagen para 2G-IOT en el sitio web de Armbian, solo en el sitio web de Orange Pi. También probé Ubuntu Server, pero no mostró ningún signo de vida. El NAND incorporado en Android parece estar funcionando, pero no lo estudié en absoluto, lo más probable es que sin una pantalla táctil sea de poca utilidad. Por cierto, le recuerdo que el dispositivo de arranque está determinado por la posición del puente en la esquina de la placa, por defecto hay un arranque desde la memoria NAND incorporada.

Mina No. 2: acceso a Internet por módem


Después de textualmente la configuración de wvdial y pppd en Internet, de repente descubrí que las solicitudes de ping estaban pasando bien, pero los paquetes TCP normales no eran de ninguna manera:

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:~$ 

La solución provocó edtun : https://www.linux.org.ru/forum/admin/12135523 , aunque admito que podría haber sido de alguna manera más simple.

Alerté inmediatamente de que el módem IMEI está lleno de ceros. Afortunadamente, el operador de telecomunicaciones rojo-blanco no presta atención a esto. (Por cierto, el WiFi incorporado de manera similar no tiene una dirección MAC: se genera aleatoriamente con cada sacudida de la fuente de alimentación).

Mina No. 3: puerto USB


Ponemos un silbato WiFi en el conector USB y ... No pasa nada. lsusb mostró un puerto USB vacío. Un poco de excavación mostró que la placa realmente solo tiene un USB. Y por defecto, está conectado al puerto microUSB. Para cambiarlo a un USB HOST normal, debe cambiar los puentes en la placa, que se encuentran al lado del puente para seleccionar el arranque. Su descripción está en w3bsit3-dns.com:
Solución: cambie los puentes a la posición: 1234 hacia abajo, 5678 hacia arriba.

Solo entonces encontré una pequeña mención de este matiz en el manual de Orange Pi.

Mina No. 4: Conductores


Ahora el dispositivo se detecta en el sistema, lsusb muestra el fabricante y el código del producto, pero la interfaz de red inalámbrica no se detecta en el sistema. Porque los desarrolladores no entregaron controladores para adaptadores WiFi en una naranja. Y ninguno en absoluto. Hay un controlador solo para WiFi incorporado, ni más ni menos. ¿Y qué hacemos cuando no tenemos un controlador para nuestro hardware? Así es, ¡recopilémoslos del código fuente !

Mina # 5: Preparándose para construir


En correspondencia, bad__day sugirió reunirse directamente en Orange Pi. Quizás esto sea posible, pero fallé.

Para Orange Pi, los desarrolladores crearon un sistema de construcción especial de Orange Pi, con la ayuda de la cual, en teoría, para construir un núcleo o módulos, es suficiente simplemente seguir las instrucciones en la pantalla. Las instrucciones detalladas se dan en el manual que comienza en la página 61. Parece que solo sigue, y todo estará bien, pero no.

En primer lugar, para no editar manualmente todas las dependencias en mi computadora (actualizo regularmente el software, esto es genial, pero esta vez no), implementé una máquina virtual con Ubuntu 16.04 y realicé todas las acciones allí. En segundo lugar, se produjo un error en los scripts en algún lugar, y el Sistema de compilación no puso una cadena de herramientas para la compilación multiplataforma. Esto se resuelve con tal muleta:

  1. Manualmente apt-get'om coloca la cadena de herramientas para la compilación cruzada en ARM.
  2. Hacer enlaces 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 
    Tenga en cuenta: el compilador toma la versión 4.9, no se recopilará nada en las versiones anteriores.
  3. Abra OrangePiRDA / scripts / Prepare_toolchain.sh y, por si acaso, comente las líneas que mencionan la cadena de herramientas.

De hecho, todos estos scripts simplemente llaman a apt-get install -y ... y make. El script no ofrece al usuario cambiar la configuración de ninguna manera (¿o no lo encontré?).

Pero después de todo, nada nos impide llamarnos

 make menuconfig 

y marque los controladores necesarios. Hacemos esto y recolectamos nuevamente (ahora solo son posibles los módulos) y ...

Mina # 6 (con un sensor de movimiento IR atornillado y un detonador de repuesto): conjunto del controlador


... Y luego el script comenzó a hacer preguntas afablemente sobre cómo configurar el núcleo. Invocó el antiguo configurador de kernel, pero ¿por qué? Que esta mal

¡Resultó que el Makefile está escrito para verificar los cambios de configuración de TIME (!!!)!



El comentario dice literalmente "alguien estaba cavando". (En la captura de pantalla, el Makefile ya modificado, registré menuconfig.) Intenté llamar a make oldconfig, no me di cuenta de que esto cambió algo en alguna parte. Bien, ahora después de que se llama a menuconfig durante el ensamblaje, no da miedo. Llamo de nuevo al ensamblado, el ensamblaje se da cuenta de que "alguien estaba cavando en la configuración", llama a menuconfig, salgo y espero la finalización. Ahora imagine mi sorpresa cuando no encontré el controlador que seleccioné.

Descargo de responsabilidad antes de leer
En este punto, dejé la comprensión de lo que está sucediendo, y también finalmente perdí el contacto con la realidad, el sentido común y la civilización del planeta Ross 128 b. Fui más allá de los límites de mi conocimiento, de todos mis amigos y TARDIS. Comencé a crear tonterías completas, y el único objetivo era recolectar este controlador [CENSURADO] a toda costa. Si, al leer el texto de arriba, te agarró la cabeza más de dos veces, entonces no leas el texto a continuación. Será más tranquilo para ti y para mí. Si puede dar una explicación clara de lo que está sucediendo y explicar dónde estoy equivocado y cómo hacerlo, por favor dígame. Por favor



Bueno, subimos para entender. Resulta que make crea el archivo modules.order, que describe todos los módulos que se compilarán. E incluso después de todos los cambios de configuración y su guardado, este archivo se llena con el mismo conjunto. No se me ocurrió nada mejor que agregarle líneas manualmente (mi silbato está ensamblado en el chipset RTL8192CU):

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

Todas las referencias a este archivo en el Makefile fueron reemplazadas por modules.order.fake. Empiezo la asamblea. Esta vez, el ensamblaje se fue, pero se interrumpió, ya que no hay un archivo similar en la carpeta de código fuente rtlwifi. Cambié el nombre de los archivos modules.order.fake a modules.order en esta carpeta y subcarpetas, y esta fue mi última aventura en la construcción del controlador. Después de eso, el sistema me mostró menúconfig dos veces más, como si me preguntara "¿realmente quieres esto?", Pero aún así recolectó tres archivos .ko atesorados adicionales, que terminaron como se esperaba.

Mina No. 7: trabajo conjunto de un WiFi externo y un módem


Después de jugar un poco con airodump y asegurarme de que el dispositivo al menos pueda atrapar paquetes en modo monitor, decidí revisar el módem nuevamente. Haciendo

 sudo wvdial 

Y el LED del adaptador WiFi externo se apaga y SSH se cae. Luego leí en los registros que el adaptador estaba desconectado. El primer pensamiento es el problema con la nutrición. Hasta ese momento, usé mi cargador por 1.5 Amperios, y el fabricante recomienda hasta 3 (¿tanto? Ella ni siquiera come un Amperio ). A la mano había un cargador de 2 amperios, que durante años alimentaba regularmente a la Raspberry Pi.

Por el momento, no he encontrado ninguna solución estable a este problema. Aquí hay algunos intentos de solución:

  • Con una probabilidad del 80%, puede deshabilitar WiFi externo usando:

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

    y luego ejecute wvdial, que intentará establecer una conexión con 1-3 intentos y podrá conectarse. En el 20% de todo tipo de cuelga y falla.
  • Una vez, por casualidad, resultó que wvdial fue asesinado, pero pppd siguió funcionando (¿cómo puede ser?), Después de lo cual aumentó el WiFi externo (ver arriba, escribimos vincular en lugar de desvincular) y hubo una conexión a través del módem. No fue posible reproducir la situación.
  • Resultó que sin reconstruir el kernel, puede apagar la alimentación de USB utilizando dicha utilidad con el comando

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

    y enciende el poder
     ./hub-ctrl -h 0 -P 1 -p 1 
    En 2G-IOT, el comportamiento es impredecible: un corte de energía puede ser por un segundo o antes de reiniciar. En algunas fases de la luna, un intento de devolver el poder hace que el tablero se congele.
  • Cambie los puentes a OTG (1234 arriba, 5678 abajo), aplique alimentación a las patas de GPIO 2 y 6 (sonando, están directamente conectados a la alimentación microUSB)

    Pinout


    Conecte el adaptador WiFi a través del adaptador USB-OTG desde el teléfono inteligente. El sistema no ve el dispositivo USB en absoluto. Quizás necesites jugar más persistentemente con puentes.

No probado, pero puede funcionar (planea probar todas estas opciones):

  • Otro adaptador WiFi.
  • Fuente de alimentación muy estable con una corriente máxima de 3 amperios.
  • Potencia extra para pies USB.
  • Gasolina y fósforos.

En general, la tarea parece tirar de una manta triangular sobre una naranja cuadrangular.

Eso es todo por ahora.

Agradecimientos
Quisiera expresar mi gratitud a bad__day , edtun , A. Repin, usuarios del foro de w3bsit3-dns.com , veteranos en el chat de Telegram y Kotu, que me escucharon pacientemente todo este tiempo y casi no intentaron escapar.


UPD: Hoy me trajeron una fuente de alimentación con una salida de 5V 3A. Con él, fue posible iniciar simultáneamente el módem y el adaptador USB WiFi. El módem rocía con errores, deja de responder, pero en promedio se conecta desde el tercer intento. Después de eso, puede usar USB WiFi.

Para resumir.


La placa única Orange Pi 2G-IOT es muy cruda y casi no es compatible con el fabricante. Incluso en cosas simples, donde parece que nada augura problemas, algo puede salir mal. Si necesita usar un dispositivo con acceso a Internet a través de una red móvil y no está seguro de poder hacer frente a Orange Pi, entonces es mejor pagar más y tomar algo más confiable y depurado. Ahorre tiempo y nervios.

Source: https://habr.com/ru/post/440960/


All Articles