USB EHCI: aide avec les erreurs de transaction

L'un de nos jalons actuels pour notre projet (open source) est actuellement de compléter le support USB, et nous travaillons donc dur sur les pilotes pour le moment. Notre développement actuel se concentre sur EHCI à la fois sur x86 et ARM (SoC OMAP35xx spécifiquement, EHCI uniquement dans le silicium de la carte). La plupart du temps, tout fonctionne parfaitement avec une variété d'émulateurs - VMware (versions gratuites et non-libres), QEMU et VirtualBox.USB EHCI: aide avec les erreurs de transaction

Lorsque nous faisons des tests sur du matériel réel, cependant, nous n'avons absolument rien. La routine de base pour le dénombrement dans notre système ressemble à ceci:

sous tension du port (si l'option est disponible) et attendez le pouvoir de stabiliser le dispositif
Effectuez une réinitialisation du port (tenu pour 50 ms), puis attendez la fin de la réinitialisation (boucle)
Si le périphérique est équipé d'un périphérique et qu'il est activé, informez le système qu'un nouveau périphérique USB est disponible pour l'initialisation.
Envoyez la commande SET ADDRESS pour attribuer une adresse au périphérique. C'est là que nous rencontrons des problèmes partout:
1. La transaction SETUP pour cette commande est exécutée sans erreur
2. La longueur nulle dans la transaction (phase d'état) renvoie une erreur de transaction, arrête le TAJ, et désactive le port.

Nos retards de synchronisation sont essentiellement les mêmes que le pilote de Linux (le cas échéant, plus). Selon la spécification USB 2.0, ce comportement est une "erreur de port" (section 11.8) mais pour être complètement honnête je ne vois pas comment traduire sa description d'une erreur de port en une solution de travail pour notre pilote. Comme nous sommes un projet open source, nous n'avons pas non plus l'argent pour sortir et acheter un analyseur de protocole USB adéquat pour étudier ce qui se passe sur la ligne.

Est-ce que quelqu'un a rencontré un problème similaire et connaît une solution?

Source

2010-07-19 Matthew Iselin

Nous avons identifié la cause de ce problème a été un problème de synchronisation, mais dans notre cas, le problème était trop beaucoup d'un retard. En modifiant notre code de création qTD/QH pour créer un QH unique avec plusieurs qTD associés, nous avons réussi à obtenir des exécutions réussies sur le matériel physique.

Nous avons également dû utiliser des structures de données EHCI 64 bits, qui n'avaient pas été implémentées auparavant.

Source

2010-07-21 08:34:29

En outre, sur certains matériels réels, l'arrêt du contrôleur hôte et sa reprise lors de la gestion de l'IRQ provoquent réellement cette erreur. Je crois que cela a à voir avec le calendrier asynchrone n'étant pas correctement arrêté, créant une désynchronisation dans l'état perçu entre l'hôte et le périphérique. –

Comment avez-vous utilisé les structures de données 64 bits? Je pensais que le registre CTRLDSSEGMENT était utilisé comme un sélecteur pour les systèmes 64 bits. –

@Jonas: nous avons simplement ajouté les "champs d'extension 64 bits" à notre structure qTD - toutes les structures de données 64 bits ont 5 DWORDS de plus. Nous avions des métadonnées dans ce domaine. Cela simplifie également notre code de gestion des contrôleurs hôtes qui prennent en charge les structures 64 bits (car nous n'avons pas besoin d'avoir deux types différents). Le registre CTRLDSSEGMENT est juste nul, je ne l'ai pas encore trouvé utile sur nos systèmes de test. –

USB EHCI: aide avec les erreurs de transaction

Répondre

Questions connexes