Bonjour,
je souhaiterai pouvoir interagir avec un périphérique sans avoir à passer par l'espace kernel. Un contact m'a dit qu'il était possible d'utiliser l'appel mmap() .
Ma question concerne /dev/mem : mémoire physique - Est ce que ça correspond au mapping et donc la possibilité d'accéder à tous les périphériques ?
Merci d'avance
Mohadib
Forum Linux.noyau dev/mem mémoire physique
25
mar.
2005
# gni?
Posté par TheBreton . Évalué à 2.
Pour autant que je me rapelle il existe plusieurs facon dans la ligne de commande du kernel de lui dire de ne pas acceder a une zone memoire (ISA hole) par exemple ou reserver la zone memoire acessible (lui dire d'acceder 128MO meme si 512Mo sont present sur la machine).
MAIS (le voila) tout ceci servait a l'epoque de l'ISA (et de la gestion des 16 permier Mo de la memoire) a adresser des cartes ISA directement par adresse. Tout ceci n'est PAS utilisable avec des cartes PCI.
Une appli standard ne peut pas acceder a une zone memoire de sont choix sans passer par une passerelle situer dans le kernel.
En clair ton peripherique c'est quoi ? car il est tout a fait possible qu'une tel techno soit existante dans le kernel et qu'il te faille juste savoir comment la declencher ?
[^] # Re: gni?
Posté par Toufik YAHIA . Évalué à 1.
Je te plante le décors . Je bosse actuellement sur une petite carte qui s'appelle l'OPUS 103 développée par la société Com2gether . Tu peux consulter leurs site et avoir des précisions sur ce petit système embarqué bien sympathique - web server Linux embedded. Le driver du composant central ( EPLD) a été dévelloppé dans les règles de l'art ( module ). Par ses adresses physiques de l'EPLD, je voudrais en mode user via l'appel mmap( ) pouvoir interagir avec les adresses physiques de la carte. l'EPLD est fixé à l'adresse physique 0xB000 0000 ( mapping mémoire de la carte) et les 16 adresses qui suivent nous permettent d'accéder à des registres ( exeemple : FPGA, Led, Dip switch, version ... ).
J'espère avoir été clair...
[^] # Re: gni?
Posté par TheBreton . Évalué à 2.
voir l'exemple ici
http://www.tldp.org/LDP/khg/HyperNews/get/devices/fake.html(...)
[^] # Re: gni?
Posté par TheBreton . Évalué à 2.
En tout cas, si ton module fait une reservation de la zone memoire tu ne pourras pas faire un mmap dessus par /dev/mem car cette requete echoueras (mmap ne fonctionne que sur une zone libre).
Deux solutions soit tu redeveloppe tout le drivers de l'epld en user space avec le mmap via le /dev/mem soit tu rajoute l'acces en ecriture dans le fil-op de ton module.
# mmap
Posté par Anonyme . Évalué à 3.
utiliser mmap sur /dev/mem revient a faire correspondre X bytes d'un emplacement mémoire dans un autre emplacement mémoire... pas grand interet sauf cas tres particulier.
Pour interagir avec un composant matériel sans passer par l'espace kernel, les fichiers de /dev, /proc/ et /sys sont, à ma connaissance, les seules solutions possibles, à condition que tu aies les droits necessaires pour y lire et y écrire. Tu es alors limité par la maniere dont le module gérant ce composant dans le noyau circonscrit le degré d'interaction possible avec ce composant via ces fichiers pour un utilisateur lambda.
j'ai bon ?
[^] # Re: mmap
Posté par Toufik YAHIA . Évalué à 1.
Je bosse sur une petite carte qui s'appelle l'OPUS 103 développé par la société Com2gether . Tu peux consulter leurs site et avoir des précision sur ce petit système embarqué bien sympathique - web server Linux embedded. Le driver du composant central
( EPLD) a été dévelloppé dans les règles de l'art sous forme de module. Le pilote de ce périphérique tient compte des 16 adresses qu'occupe ce composant dans le mapping de carte. Pour info, ce pilote permet de charger un FPGA avec des fichiers au format rbf
ce périphérique n'est accessible qu'en écriture. Par les adresses physiques de l'EPLD, je voudrai en mode user via l'appel mmap( ) pouvoir interagir avec les 16 adresses qui permettent d'accéder à des registres ( exemple : FPGA, Led, Dip switch, version ... ).
fd=open("/dev/epld",O_RDWR);;
adr=mmap( ....,fd......);
J'ai quelques problèmes à implémenter l'accés si il fonctionne
Qu'en penses tu?
[^] # Re: mmap
Posté par Anonyme . Évalué à 2.
n'oublies pas de tester la valeur retournée par open.
pour le reste man mmap sera surement plus complet que moi.
ensuite, tout depend de /dev/epld:
- est-il accessible en lecture et/ou ecriture ?
- quelle est la nature des données transitant par ce fichier ?
- existe-t-il un protocole de communication avec la carte par ce biais ?
Je ne sais pas si ce que j'ai pu raconter avant t'as aidé, mais en ce qui concerne les questions precedentes, je ne peux pas faire grand chose
[^] # Re: mmap
Posté par Toufik YAHIA . Évalué à 1.
epld.mem_baseioremap(adresse de base ,size = 16 )
Faut-il que le pilote soit définit en lecture pour que cela fonctionne?
fd=open("/dev/epld",O_RDWR);;
adr=mmap( ....,fd......);
A plus
# /dev/kcore et périphériques
Posté par galactikboulay . Évalué à 2.
Je pense que tu fais plutôt référence à /proc/kcore qui est un fichier virtuel permettant d'accéder à l'intégralité de la mémoire physique.
Un mmap() judicieusement utilisé sur ce fichier permet d'accéder à n'importe(s) quelle(s) pages physiques. Mal utilisé, je te promets que tu vas flinguer le système très vite (surtout si tu écris sur des pages du noyau).
Après, pour ton périphérique, il y a 2 possibilités (sur architecture x86):
* Soit il utilise des ports IO spécifiques (voir instructions inb/outb et compagnie) et dans ce cas mapper la mémoire ne sert à rien. On peut voir les ports IO avec le fichier /proc/ioports.
* Soit c'est du "memory-mapped", et dans ce cas, je pense que mapper /proc/kcore fonctionnerait (en ne mappant que la zone qui t'intéresse bien sûr).
Le fichier /proc/iomem montre les zones mémoires et les périphériques qui utilisent ces zones.
Attention, toutes ces manips ne peuvent bien sûr se faire qu'en root.
[^] # Re: /dev/kcore et périphériques
Posté par Toufik YAHIA . Évalué à 1.
dr-xr-xr-x 3 root root 0 Jan 1 00:55 1
dr-xr-xr-x 3 root root 0 Jan 1 00:55 10
dr-xr-xr-x 3 root root 0 Jan 1 00:55 161
dr-xr-xr-x 3 root root 0 Jan 1 00:55 2
dr-xr-xr-x 3 nobody root 0 Jan 1 00:55 26
dr-xr-xr-x 3 root root 0 Jan 1 00:55 29
dr-xr-xr-x 3 root root 0 Jan 1 00:55 3
dr-xr-xr-x 3 nobody nobodygr 0 Jan 1 00:55 30
dr-xr-xr-x 3 root root 0 Jan 1 00:55 4
dr-xr-xr-x 3 root root 0 Jan 1 00:55 5
dr-xr-xr-x 3 root root 0 Jan 1 00:55 59
dr-xr-xr-x 3 root root 0 Jan 1 00:55 6
dr-xr-xr-x 3 root root 0 Jan 1 00:55 60
dr-xr-xr-x 3 root root 0 Jan 1 00:55 9
dr-xr-xr-x 3 root root 0 Jan 1 00:55 bus
-r--r--r-- 1 root root 0 Jan 1 00:55 cmdline
-r--r--r-- 1 root root 0 Jan 1 00:55 cpuinfo
-r--r--r-- 1 root root 0 Jan 1 00:55 devices
-r--r--r-- 1 root root 0 Jan 1 00:55 dma
dr-xr-xr-x 2 root root 0 Jan 1 00:55 driver
-r--r--r-- 1 root root 0 Jan 1 00:55 execdomains
-r--r--r-- 1 root root 0 Jan 1 00:55 filesystems
dr-xr-xr-x 2 root root 0 Jan 1 00:55 fs
-r--r--r-- 1 root root 0 Jan 1 00:55 interrupts
-r--r--r-- 1 root root 0 Jan 1 00:55 iomem
-r--r--r-- 1 root root 0 Jan 1 00:55 ioports
dr-xr-xr-x 50 root root 0 Jan 1 00:55 irq
-r-------- 1 root root 16781312 Jan 1 00:55 kcore
-r-------- 1 root root 0 Jan 1 00:55 kmsg
-r--r--r-- 1 root root 0 Jan 1 00:55 ksyms
-r--r--r-- 1 root root 0 Jan 1 00:55 loadavg
-r--r--r-- 1 root root 0 Jan 1 00:55 locks
-r--r--r-- 1 root root 0 Jan 1 00:55 meminfo
-r--r--r-- 1 root root 0 Jan 1 00:55 misc
-r--r--r-- 1 root root 0 Jan 1 00:55 modules
lrwxrwxrwx 1 root root 11 Jan 1 00:55 mounts -> self/mounts
-r--r--r-- 1 root root 0 Jan 1 00:55 mtd
dr-xr-xr-x 4 root root 0 Jan 1 00:55 net
-r--r--r-- 1 root root 0 Jan 1 00:55 partitions
-rw-r--r-- 1 root root 0 Jan 1 00:55 ppc_htab
lrwxrwxrwx 1 root root 64 Jan 1 00:01 self -> 161
-rw-r--r-- 1 root root 0 Jan 1 00:55 slabinfo
-r--r--r-- 1 root root 0 Jan 1 00:55 stat
-r--r--r-- 1 root root 0 Jan 1 00:55 swaps
dr-xr-xr-x 11 root root 0 Jan 1 00:55 sys
dr-xr-xr-x 2 root root 0 Jan 1 00:55 sysvipc
dr-xr-xr-x 4 root root 0 Jan 1 00:55 tty
-r--r--r-- 1 root root 0 Jan 1 00:55 uptime
-r--r--r-- 1 root root 0 Jan 1 00:55 version
/proc #
/proc # cat ioports
/proc #
Comme tu le vois ioports ne donne rien en informations. la suite dit ceci
/proc # cat cpuinfo
processor : 0
cpu : 8xx
clock : 50MHz
bus clock : 50MHz
revision : 0.0 (pvr 0050 0000)
bogomips : 49.76
/proc #
C'est un Powerpc: la suite dit
/proc # cat devices
Character devices:
1 mem
2 pty
3 ttyp
4 ttyS
5 cua
10 misc
90 mtd
101 epld
108 ppp
128 ptm
136 pts
162 raw
254 pcmcia
Block devices:
31 mtdblock
/proc #
Le Powerpc est défini comme un périphérique? Dans ce cas je peux modifier et reconfigurer le µP a chaud? non?
Je plane à mille lieu avec ce systeme.
Help!!!!
/proc # cat modules
epld 1376 0 (unused)
/proc #
Ha voila notre driver epld
/proc # cat mtd
dev: size erasesize name
mtd0: 00800000 00010000 "Physically mapped flash"
mtd1: 00040000 00010000 "RedBoot"
mtd2: 000a0000 00010000 "unallocated space"
mtd3: 00300000 00010000 "JFFS2"
mtd4: 00020000 00010000 "nios.rbf"
mtd5: 00010000 00010000 "sdram.srec"
mtd6: 000b0000 00010000 "zImage"
mtd7: 00320000 00010000 "unallocated space"
mtd8: 00010000 00010000 "RedBoot config"
mtd9: 00010000 00002000 "FIS directory"
/proc #
Ca ,c'est la compact flash... JFFS2 et zImage
et pour iomem:
/proc # cat iomem
/proc #
Je n'ai rien
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.