4G modem em um kernel 2.6.32.9 embutido em um Parrot AR Drone 2.0

2

Eu estou tentando compilar o suporte para um modem USB LTE Huawei E3276 para uma instalação Linux / BusyBox embutida em um Parrot AR Drone 2.0, que é baseado no kernel 2.6.32; no entanto, estou correndo em alguns problemas depois de carregar os módulos do kernel.

Eu começo carregando os módulos do kernel necessários:

  • usbnet
  • cdc-acm,
  • cdc_subset,
  • cdc_ether,
  • mii
  • usbserial

Este modem se comporta como um NIC Ethernet que apresenta uma interface roteada (192.168.1.100 em uma eth port), então toda a configuração 4G real é feita no próprio modem através de uma interface web (caso você esteja se perguntando porque eu não estou incluindo qmi_wwan drivers).

Em seguida, conecto o modem 4G até obter as seguintes entradas em dmesg e lsusb :

lsusb :

Bus 001 Device 002: ID 12d1:1f01 Huawei Technologies Co., Ltd.

dmesg :

scsi8 : SCSI emulation for USB Mass Storage devices
usb 1-1: uevent
usb-storage: device found at 12
usb-storage: waiting for device to settle before scanning
/home/stephane/.ardrone/linux/ardrone2_ARDrone2_Version_20130102/Linux/kernel/omap/drivers/usb/core/inode.c: creating file '012'
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 1-0:1.0: port 1 enable change, status 00000503
scsi 8:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2

Neste ponto, eu uso o comando modeswitch para colocar o dispositivo no modo modem:

usb_modeswitch-1.1.9-arm-static -v 12d1 -p 1f01 -W -M 55534243123456780000000000000011060000000000000000000000000000

Isso é bem-sucedido e altera o código do produto e o reconecta:

lsusb :

Bus 001 Device 003: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem

dmesg :

usb-storage 1-1:1.0: disconnect by usbfs
usb 1-1: usbfs: process 4792 (usb_modeswitch-) did not claim interface 0 before use
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
usb 1-1: USB disconnect, address 12
usb 1-1: unregistering device
usb 1-1: usb_disable_device nuking all URBs
usb 1-1: unregistering interface 1-1:1.0
usb 1-1:1.0: uevent
usb 1-1: uevent
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 1-0:1.0: hub_suspend
usb usb1: bus auto-suspend
usb usb1: usb resume
hub 1-0:1.0: hub_resume
hub 1-0:1.0: port 1: status 0101 change 0001
hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000
hub 1-0:1.0: port 1, status 0101, change 0000, 12 Mb/s
usb 1-1: new high speed USB device using musb_hdrc and address 13
usb 1-1: skipped 4 descriptors after interface
usb 1-1: skipped 4 descriptors after interface
usb 1-1: skipped 4 descriptors after interface
usb 1-1: default language 0x0409
usb 1-1: udev 13, busnum 1, minor = 12
usb 1-1: New USB device found, idVendor=12d1, idProduct=1001
usb 1-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
usb 1-1: Product: HUAWEI Mobile
usb 1-1: Manufacturer: HUAWEI Technology
usb 1-1: uevent
usb 1-1: usb_probe_device
usb 1-1: no configuration chosen from 1 choice
/home/stephane/.ardrone/linux/ardrone2_ARDrone2_Version_20130102/Linux/kernel/omap/drivers/usb/core/inode.c: creating file '013'
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 1-0:1.0: port 1 enable change, status 00000503
Spurious irq 95: 0xffffffdf, please flush posted write for irq 56

Infelizmente, após a etapa usb_probe_device , ela mostra que encontrou uma configuração, mas não a está escolhendo sem uma explicação.

Alguém pode me ajudar a descobrir o motivo de não ter prosseguido com a configuração encontrada? Quais etapas de diagnóstico devo seguir? Quais testes devo experimentar?

    
por Roland 23.06.2015 / 12:45

1 resposta

1

Estou tentando fazer o mesmo que você: obter um modem 3G / 4G para trabalhar no ARDrone2. Eu não estou tão longe como você é, eu apenas consegui colocar minhas mãos no toolchain, e minhas primeiras tentativas em um mundo hello falharam.

Eu realmente não tenho uma resposta, apenas uma ideia. Eu fiz um rápido google em suas mensagens de log, e achei isso: link

No entanto, acredito que o ARDrone2 está usando o kernel 2.6.32.9, e depois de examinar os arquivos de código mencionados no bugzilla, parece-me que a correção mencionada está presente.

Então, isso me fez pensar: o ARDrone2 tem uma uclinux build, que geralmente tem como alvo os sistemas incorporados e, portanto, os builds são otimizados com recursos minimalistas. Talvez algum sinalizador não tenha sido definido quando o módulo do kernel no drone foi compilado (o arquivo generic.c tem comentários que parecem também sugerir isso em torno da linha relevante com a instrução #if !defined ).

Se isso for verdade, seria uma questão de recompilar com os sinalizadores corretos ativados. Não tenho como testar seu problema, no entanto. Meu modem ainda está a caminho.

    
por 29.06.2015 / 08:46