Forum Linux.noyau dev/mem mémoire physique

Posté par  .
Étiquettes : aucune
0
25
mar.
2005
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
  • # gni?

    Posté par  . Évalué à 2.

    je ne vois pas trop exactement ce que tu veux faire et ne pas faire.
    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  . Évalué à 1.

      Salut à toi , pour ta réponse.
      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  . Évalué à 2.

        Donc effectivement si personne n'utilise cette place memoire un programme s'executant en user=root peut faire un mmap sur une zone libre
        voir l'exemple ici

        http://www.tldp.org/LDP/khg/HyperNews/get/devices/fake.html(...)
      • [^] # Re: gni?

        Posté par  . Évalué à 2.

        note en relisant ta prose il me semble voir un petit probleme, ton module utilise ces zones memoires, donc ce qu'il te faut c'est plutot un acces en ecriture au travers de ton module non ?
        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  . Évalué à 3.

    mmap te permettra de faire correspondre X bytes d'un emplacement mémoire au contenu d'un fichier. Le fait que ton fichier soit une entrée de /dev reliée à un composant matériel ne veut pas dire que tu pourras interagir avec ce composant: cela veut simplement dire que tu auras accès en memoire aux données transitant par ce fichier, telles qu'elles sont definies par le module gérant ce composant dans le noyau.

    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 ?

    Ce commentaire passe-t-il les trois tamis de Socrate ? -- https://linuxfr.org/suivi/autoriser-la-correction-limitee-de-commentaires-apres-les-5min

    • [^] # Re: mmap

      Posté par  . Évalué à 1.

      Merci pour ta réponse,
      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  . Évalué à 2.

        fd=open("/dev/epld",O_RDWR);;
        adr=mmap( ....,fd......);


        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

        Ce commentaire passe-t-il les trois tamis de Socrate ? -- https://linuxfr.org/suivi/autoriser-la-correction-limitee-de-commentaires-apres-les-5min

        • [^] # Re: mmap

          Posté par  . Évalué à 1.

          Pour te répondre brièvement, c'est un pilote en mode caractère accessible en écriture seulement, il permet le chargement d'un fichier type rbf( raw binary file ) c'est par exemple le coeur NIOS d'un FPGA programmé en VHDL. Via 2 ou 3 registres de contrôle ou de data du FPGA , on lui charge le nios ou un programme. 16 adresses sont disponibles sur l'EPLD. Dans le module epld:
          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  . Évalué à 2.


    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 ?


    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  . Évalué à 1.

      /proc # ls -l
      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 à ceux qui les ont postés. Nous n’en sommes pas responsables.