rapport pdf

Rapport.md

@@ -3,6 +3,7 @@
 Un driver (pilote) est un composant logiciel qui fait l’interface entre le noyau du système d’exploitation et un périphérique matériel ou une couche d’abstraction. Il traduit les demandes génériques du système (lire/écrire, configurer, envoyer/recevoir paquets, etc.) en opérations spécifiques au matériel, et inversement expose l’état et les événements matériels au système.
 
 Principales responsabilités
+
 - Initialisation et énumération : détecter le matériel, allouer ressources et configurer le périphérique.
 - Traduction d’appels : implémenter les callbacks et API attendus par le sous‑système du noyau (ex. net_device ops, block ops, file ops) pour que le reste du système utilise le périphérique de façon standardisée.
 - Gestion des I/O : orchestrer transferts (DMA, URB, interruptions), mise en file d’attente, copies de buffers et synchronisation.
@@ -11,11 +12,13 @@ Principales responsabilités
 - Concurrence et sécurité : protéger les ressources partagées (mutex, spinlock), respecter les contextes d’exécution (process/context IRQ/softirq).
 
 Types et niveaux
+
 - Pilotes noyau (in‑kernel) : s’exécutent au sein du noyau, offrent faibles latences et accès direct au matériel (ex. pilotes réseaux, disques, USB).
 - Pilotes en espace utilisateur : utilisent un mécanisme de médiation (ex. UIO, libusb) et conviennent pour prototypage ou usages moins critiques.
 - Pilotes de classe vs vendor‑specific : les pilotes de classe implémentent une interface standard (ex. CDC, HID) interopérable ; les pilotes vendor‑specific gèrent fonctionnalités propriétaires.
 
 Propriétés attendues
+
 - Stabilité et sécurité : ne pas corrompre la mémoire noyau, gérer correctement les erreurs et concurrents.
 - Performance : minimiser copies, utiliser offloads matériels, gérer pools/URB/queues pour hauts débits.
 - Portabilité et intégration : respecter les conventions du sous‑système kernel concerné (APIs, structures, callbacks, sysfs/ethtool si applicable).
@@ -25,6 +28,7 @@ Propriétés attendues
 Le CH397 est une puce NIC USB hautement intégrée et basse consommation, destinée à étendre une interface Ethernet via USB pour ordinateurs de bureau, portables, tablettes, consoles de jeu, etc. Elle intègre un processeur RISC‑V QingKe, un contrôleur USB2.0/2.1 avec transceiver PHY conforme USB2.1, ainsi qu’un sous‑système Ethernet complet (MAC + PHY) conforme IEEE 802.3, supportant 10/100 Mbps.
 
 Architecture matérielle
+
 - **SoC tout‑en‑un :** processeur embarqué QingKe RISC‑V, contrôleur USB, transceiver PHY USB et contrôleur Ethernet MAC+PHY intégrés sur une unique puce (packages QFN24/QFN32).
 - **USB 2.0/2.1 Full/High‑Speed :** contrôleur et transceiver conformes à la spécification USB2.1, avec LDO intégré et composants périphériques réduits (résistance 50, condensateurs oscillateur).
 - **Ethernet 10/100M :** MAC et PHY conformes IEEE 802.3 (10BASE‑T / 100BASE‑TX) ; support de l’auto‑négociation 10/100 Mbps, Auto‑MDIX et distances jusqu’à 120 m sur câbles CAT5/CAT6.
@@ -32,6 +36,7 @@ Architecture matérielle
 - **Fonctions matérielles supplémentaires :** LDO interne, support ESD amélioré (6 kV), configuration LED matérielle, wake‑up réseau et modes basse consommation.
 
 Interfaces réseau disponibles
+
 - **CDC‑ECM, CDC‑NCM et RNDIS :** support natif de CDC‑ECM et CDC‑NCM (USB Ethernet classes) et RNDIS — possibilité d’utilisation sans pilote propriétaire sur de nombreux hôtes, ou avec pilote vendor‑specific si souhaité.
 - **Endpoints USB standard :** modes vendor‑specific (bulk endpoints) et classes réseau standard (interfaces Communications/Data avec alt‑setting pour endpoints bulk IN/OUT).
 - **Fonctionnalités réseau hardware‑assist :**
@@ -41,6 +46,7 @@ Interfaces réseau disponibles
   - wake‑on‑LAN (magic packet / wake packets).
 
 Contraintes et exigences spécifiques
+
 - **Choix de configuration USB :** la puce expose plusieurs configurations (vendor, CDC‑ECM, NCM, RNDIS) — le pilote doit détecter la configuration active et sélectionner l’interface/altsetting offrant les endpoints bulk nécessaires (ex. altsetting 1 pour CDC Data).
 - **Taille et gestion des buffers :** présence de buffers internes signifie que le périphérique peut livrer des trames agrégées ou de taille > MTU standard ; prévoir côté pilote des buffers hôtes suffisamment grands (ex. >= 1600–2048 octets) et gérer l’alignement skb.
 - **Performances et flux :** le CH397 prend en charge features hardware‑assist (checksum offload, flow control, VLAN), le pilote peut en tirer parti pour réduire la charge CPU et améliorer le débit ; envisager gestion des URB/queues pour atteindre des débits proches du 100 Mbps.