infos on /dev/mem - Linux

This is a discussion on infos on /dev/mem - Linux ; Hi guys, someone knows which is the option to activate in the Linux Kernel configuration to have the /dev/mem working? Thank you very much Ste -- questo articolo e` stato inviato via web dal servizio gratuito http://www.newsland.it/news segnala gli abusi ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: infos on /dev/mem

  1. infos on /dev/mem


    Hi guys,

    someone knows which is the option to activate in the Linux Kernel
    configuration to have the /dev/mem working?

    Thank you very much

    Ste



    --

    questo articolo e` stato inviato via web dal servizio gratuito
    http://www.newsland.it/news segnala gli abusi ad abuse@newsland.it



  2. Re: infos on /dev/mem

    steve wrote:
    > someone knows which is the option to activate in the Linux Kernel
    > configuration to have the /dev/mem working?


    The driver for /dev/mem is present in all kernels unless you have
    manually gone into the Makefile and disabled it; there is no
    configuration option. To confirm its presence, look at /proc/devices.
    It should always have major device # 1. If the device node is not
    present in the /dev directory, it can be re-created with the command
    mknod /dev/mem c 1 1

    GH


  3. Re: infos on /dev/mem

    gil_hamilton@hotmail.com writes:
    >steve wrote:
    >> someone knows which is the option to activate in the Linux Kernel
    >> configuration to have the /dev/mem working?

    >
    >The driver for /dev/mem is present in all kernels unless you have
    >manually gone into the Makefile and disabled it; there is no
    >configuration option. To confirm its presence, look at /proc/devices.
    >It should always have major device # 1. If the device node is not
    >present in the /dev directory, it can be re-created with the command
    >mknod /dev/mem c 1 1


    Unfortunately, /dev/mem represents not the physical memory space as a CPU without
    MMU would see it. It covers only the lower 16MB. The remaining RAM is not
    accessible and mapped to a null page. If you limit the memory at boot time with
    the "mem=xxx" option, the unused memory above the xxx is accessible again.
    However, the PCI memory mapped IO can always be accessed by /dev/mem.

    --
    Georg Acher, acher@in.tum.de
    http://www.lrr.in.tum.de/~acher
    "Oh no, not again !" The bowl of petunias

  4. Re: infos on /dev/mem

    Georg Acher wrote:
    > Unfortunately, /dev/mem represents not the physical memory space as a CPU without
    > MMU would see it. It covers only the lower 16MB. The remaining RAM is not
    > accessible and mapped to a null page. If you limit the memory at boot time with
    > the "mem=xxx" option, the unused memory above the xxx is accessible again.
    > However, the PCI memory mapped IO can always be accessed by /dev/mem.


    This isn't the case with the several kernels I am looking at (including
    at least three 2.6 versions and a couple of 2.4 versions), all of which
    allow mapping of arbitrary physical addresses. Are you perhaps looking
    at code that is specific to a particular architecture?

    The mem=xxx specification merely redefines what is considered the top
    of ordinary memory and hence affects only the "page protection" bits
    with which the memory is accessed, usually by mapping pages above that
    point uncached.

    GH


  5. Re: infos on /dev/mem

    gil_hamilton@hotmail.com writes:
    >Georg Acher wrote:
    >> Unfortunately, /dev/mem represents not the physical memory space as a CPU without
    >> MMU would see it. It covers only the lower 16MB. The remaining RAM is not
    >> accessible and mapped to a null page. If you limit the memory at boot time with
    >> the "mem=xxx" option, the unused memory above the xxx is accessible again.
    >> However, the PCI memory mapped IO can always be accessed by /dev/mem.

    >
    >This isn't the case with the several kernels I am looking at (including
    >at least three 2.6 versions and a couple of 2.4 versions), all of which
    >allow mapping of arbitrary physical addresses. Are you perhaps looking
    >at code that is specific to a particular architecture?


    You can do the mmap without any error, but you will not get access to the
    intended area. Verified on 2.6.8 and with an logic analyzer listening on the
    SDRAM. I can look up the responsible code, it should be trackable along the
    kernel versions.

    --
    Georg Acher, acher@in.tum.de
    http://www.lrr.in.tum.de/~acher
    "Oh no, not again !" The bowl of petunias

  6. Re: infos on /dev/mem

    In article ,
    acher@in.tum.de (Georg Acher) writes:
    <...>

    Just a note: I'm talking about i386/x86_64. It might be different (less
    annoying...) on other architectures. The responsible code is in
    arch/i386/mm/ioremap.c:__ioremap(), it has the comment "Don't allow anybody to
    remap normal RAM that we're using..".

    --
    Georg Acher, acher@in.tum.de
    http://www.lrr.in.tum.de/~acher
    "Oh no, not again !" The bowl of petunias

  7. Re: infos on /dev/mem

    Georg Acher wrote:
    > Just a note: I'm talking about i386/x86_64. It might be different (less
    > annoying...) on other architectures. The responsible code is in
    > arch/i386/mm/ioremap.c:__ioremap(), it has the comment "Don't allow anybody to
    > remap normal RAM that we're using..".


    Hmm....
    Digging further, I see that you're right: non-Reserved pages don't get
    mapped to the requested address (though the actual code lines for this
    are in mm/memory.c, function remap_pte_range -- the ioremap* functions
    are only used within the kernel).

    However, it appears to me that one can still access those pages via
    read and write of /dev/mem rather than mmap. Annoyingly, one *can't*
    access the PCI memory space with read and write. So, one has to use
    read/write for the "real" memory and mmap for everything else.

    GH


+ Reply to Thread