Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Guido Guenther <guido.guenther@gmx.net>, linux-mips@oss.sgi.com
Subject: Re: Should /dev/kmem support above 0x80000000 area?
Date: Mon, 11 Dec 2000 22:16:46 -0800	[thread overview]
Message-ID: <3A35C2CE.2CF718D6@mvista.com> (raw)
In-Reply-To: Pine.GSO.3.96.1001211192843.18945O-100000@delta.ds2.pg.gda.pl

"Maciej W. Rozycki" wrote:
> 
> 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).
> 

I see.  It is funny that you cannot read/write memory beyond high_memory
through /dev/mem, but you can re-map it and then read/write through the
remapped region.

How do you control the width of bus transfers?  If you have direct access to
the device memory, the userland "drivers" should be able to deal with the bus
access width correctly.

> > 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
> *virtual* memory...
>

kseg0 and kseg1 are part of kernel virtual memory space.  If we implement
/dev/kmem correctly, one should be able to directly read/write those area by
specifying 0x80000000 or 0xa0000000 offsets through /dev/kmem.

Jun

  reply	other threads:[~2000-12-11 22:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-08  3:13 Should /dev/kmem support above 0x80000000 area? Jun Sun
2000-12-08 23:32 ` Ralf Baechle
2000-12-11 11:28   ` Maciej W. Rozycki
2000-12-11 12:41     ` Guido Guenther
2000-12-12  2:26       ` Jun Sun
2000-12-11 18:56         ` Guido Guenther
2000-12-11 19:05         ` Maciej W. Rozycki
2000-12-12  6:16           ` Jun Sun [this message]
2000-12-12 11:58             ` Maciej W. Rozycki
2000-12-12 18:53               ` Jun Sun
2000-12-12  7:38   ` Jun Sun
2000-12-12 13:23     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A35C2CE.2CF718D6@mvista.com \
    --to=jsun@mvista.com \
    --cc=guido.guenther@gmx.net \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox