|
|||||||
|
|
|
 |
|
|
Strumenti |
08-01-2006, 12:21
|
#1 |
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Driver in linux
Avrei intenzioni (sempre conscio delle mie modeste capacità) di creare un driver per il pinguino di questa periferica:
http://www.adstech.com/products/USBA...p?pid=USBAV701 Magari avreste un volume in cui sono indicati i passaggi e le librerie indicate da utilizzare nel pingux? Le specifiche visto che non sono fornite -.- sto cercando di fare un reverse dei driver proprietari... Se riesco a cavare un ragno dal buco...  Consigli please??? |
|
|
|
08-01-2006, 13:09
|
#2 |
|
Senior Member
Iscritto dal: Oct 2001
Messaggi: 11471
|
Qui c'è un libro gratuito in pdf che spiega le basi. http://lwn.net/Kernel/LDD3/ Per il resto non posso che augurarti un bel in bocca al lupo.
 ciao 
|
|
|
|
|
08-01-2006, 13:15
|
#3 |
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Ok, ti ringrazio!!!
|
|
|
|
|
09-01-2006, 10:34
|
#4 |
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Ti consiglio prima di esercitarti con il protocollo del paperweight (ammesso che riesci a farne reverse engeenering), puoi farlo in userspace tramite le libusb. E' molto più semplice che farlo nel kernel.
Se poi nel frattempo riesco a trovare tempo e voglia per completare il mio bridge user space -> char device (che tengo nel cassetto da tempo immemore), puoi realizzare il driver completamente in userspace.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
|
|
|
|
09-01-2006, 14:58
|
#5 |
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Ok ti ringrazio, io intanto vedo se riesco a ricavare qualcosa con il reverse.
Se mi potresti consigliare qualche dritta anche per quest'utimo, (anche perchè sui driver non ho esperienza, ad esempio i decompilatori come funzionerebbero???) te ne sarei infinitamente grato.
|
|
|
|
|
09-01-2006, 15:34
|
#6 |
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Non tentare di decompilare il driver, è una follia. Invece, dovrebbe esserci in giro qualche tool per sniffare il traffico usb, per windows.
Ti avverto, è un lavoraccio.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
|
|
|
|
10-01-2006, 17:05
|
#7 | ||
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Allora, oggi ho avuto un po' di tempo e ho fatto un po' di sniffing....
 In 2356 pacchetti solo all'avvio e quindi (in conseguenti 23 mega di log da polparmi) sono riuscito a rilevare dei pacchetti che dovrebbero essere abbastanza importanti, e li ho classificati in questo modo: I pacchetti di inizializzazione: 2266 in totale. Ma che si possono riassiumere in 5 pacchetti fondamentali: Quote:
Quote:
|
||
|
|
|
|
10-01-2006, 17:30
|
#8 | |
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Quelle "function" sono l'incapsulamento standard e le funzioni di controllo e configurazione di base del protocollo usb; niente di misterioso. Nota che già capire come funziona il rpotocollo usb è complicato. Tu sai benissimo come funziona, vero?
Quote:
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
|
|
|
|
|
10-01-2006, 19:11
|
#9 | ||||
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Quote:
Quote:
Quote:
Quote:
Ma questi sono i dati che vengono trasferiti durante la trasmissione (o almeno credo). Io infatti ho abbreviato tutto (ho messo i tre puntini) altrimenti usciva qualcosa di enorme. Secondo me, per implementare qualcosa e nella funzione "SELECT_CONFIGURATION" che dovremmo dare una bella occhiata, casomai vedo mi meglio il protocolla usb e poi ti faccio sapere. Inoltre Leggendomi qualche guida su qualche sito son riuscito a capire  che per implementare una semplice "function" come la definisci tu in downstream è possibile utilizzare la funzione usb_control_msg della libusb ma non ho idea che valori metterci -_- .Tu qualche hai info sul protocollo usb o altro? Ah quante domande, vado a magnà qualcosa!!! 
Ultima modifica di homer87 : 10-01-2006 alle 19:14. |
||||
|
|
|
|
11-01-2006, 10:54
|
#10 |
|
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Ti dico quel poco che so sul protocollo.
I device usb sono organizzati secondo gerarchie, questo forse lo sai. La gestione dell'albero dei dispositivi è demandata all'hardware e ai driver dei bridge; non devi occuparti di questi dettagli. Le libusb ti consentono di "sfogliare" l'albero alla ricerca del device che ti interessa. Un device è destritto da alcune informazioni standard, quali il vendorId:deviceId, la classe, ecc. Esistono classi standard di device, quali "usb mass storage" oppure "usb serial converter". Queste classi utilizzano lo stesso protocollo (o con piccole variazioni), quindi puoi gestire tutti i device di una classe con lo stesso driver. Il tuo dispositivo probabilmente utilizza un protocollo proprietario. La comunicazione con un device passa tramite diversi "pipe" logici di comunicazione. Puoi pensare a un singolo pipe come a un canale seriale, monodirezionale. Ogni pipe è detto anche "endpoint" (ep). Gli ep (tranne lo 0, v. sotto) sono in genere configurabili dal driver; il tuo controllo è (fortunatamente!) in genere abbastanza limitato, puoi al massimo selezionare un tipo di configurazione oppure una alternativa. Oltre che dalla direzione (in oppure out), un ep è descritto dalla dimensione in byte dei singoli pacchetti, e dal tipo: - canale di controllo E' generalmente associato convenzionalmente all'ep0. Serve per inviare comandi di configurazione al device. Alcuni comandi sono standard nel protocollo usb; altri possono essere specifici del vendor. - canale interrupt Canale ad alta priorità per trasferire piccole quantità di dati. Serve in genere per comunicare eventi importanti. - canale bulk Pipe di comunicazione affidabile per i dati. Viene usato ad es. dagli storage device per trasmettere o ricevere i dati dei settori. Il canale bulk viene usato quando i dati da trasmettere non devono essere persi. - canale isochronous (iso) Simile al canale bulk, ma senza l'affidabilità. Viene utilizzato quando i dati da trasmettere possono essere persi se la banda non è sufficiente (ad es. webcam, o dispositivi di acquisizione in genere). Puoi fare una analogia tra il canale bulk e un socket tcp, e tra il canale iso e un socket udp, per renderti una idea. Un device definisce un certo numero di ep, tipicamente 6-8. Consente, come ho accennato, di scegliere anche configurazioni alternative. Queste informazioni possono essere consultate tra le caratteristiche del dispositivo, tramite le libusb. Quindi, per iniziare, ti consiglio di sniffare il traffico iniziale con il dispositivo, che probabilmente passa per il canale di controllo, e cercare di capire cosa viene fatto. Ti consiglio inoltre di fare un pò di pratica con le libusb, in rete trovi un pò di codice di esempio. Utilizza la versione devel in cvs, in quanto non credo che quella ufficiale gestisca i canali interrupt. Per gestire il canale iso, nel caso il tuo device lo usi, potrebbe essere necessaria una patch esterna. E iscriviti alla loro mailing list, possono aiutarti
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
|
|
|
|
11-01-2006, 19:35
|
#11 | |
|
Member
Iscritto dal: Oct 2005
Messaggi: 263
|
Quote:
Ok grazie mille delle informazioni, vedrò ciò che riesco a fare.
|
|
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 02:44.
