On Mon, 11 Dec 2000, Jun Sun wrote:
> I am surprised. I thought /dev/mem is for accessing SYSTEM RAM. (do a 'man'
You access the memory space. Whatever is found at the address you
specify, be it RAM, an MMIO area or unoccupied space. You may receive a
bus error in the latter case (depending on a system configuration).
> on /dev/mem) It is also confirmed by the code in drivers/char/mem.c. If you
> want to access anything beyond 'high_memory", nothing is read.
Yep, you may only use read()/write() for system RAM. For other areas you
have to mmap() the interesting part of /dev/mem and then access it
directly (which is easier and better anyway, as you may control the width
of bus transfers -- not all MMIO devices support all widths).
> Note that drivers/char/mem.c is cross-platform code. I am not sure how X
> would access video memory through /dev/mem on either MIPS or other platforms.
It mmap()s the areas it's interested in. Read the code!
> That reason I want to fix /dev/kmem is that in some cases before a driver is
> written people want to play with the hardware directly from the userland
> (especially for demo purpose. :-0) Very useful for embedded systems.
I'm not sure how to use /dev/kmem for this purpose -- it's kernel's
> Potentially fixing /dev/mem can do the same job. However /dev/mem cannot
> differentiate cached or uncached accesses. With /dev/kmem, we just specify
> 0x8.. or 0xa....
Yep, /dev/mem for non system RAM areas is always uncached which is what
is almost always desired (for system RAM areas you may request
uncacheability by passing O_SYNC when opening the file).
Anyway, /dev/mem works great -- I've successfully used it to access APICs
(at 0xfec00000 and 0xfee00000) in my i386 system and various stuff (an
NVRAM at 0x1c000000, a graphics accelerator at 0x1e000000, a FDDI network
controller at 0x1f000000, onboard I/O stuff at 0x1f800000 and a system ROM
at 0x1fc00000) in my DECstation.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +