From: Jamie Lokier <jamie@shareable.org>
To: Paolo Ornati <javaman@katamail.com>, linux-kernel@vger.kernel.org
Subject: Re: [OT] Documentation for PC Architecture
Date: Tue, 19 Aug 2003 02:02:05 +0100 [thread overview]
Message-ID: <20030819010205.GE11081@mail.jlokier.co.uk> (raw)
In-Reply-To: <20030818225422.GA23927@www.13thfloor.at>
Herbert Pötzl wrote:
> On Mon, Aug 18, 2003 at 11:11:53PM +0200, Paolo Ornati wrote:
> > >
> > > > Curiosity: since the memory addresses from 640KB to 1MB are reserved for
> > > > memory mapped I/O (video memory) and BIOS ROM... the corrispondent range
> > > > in
> > >
> > > uh oh ...
> > >
> > > > the REAL MEMORY isn't usable and so we lost 384KB of memory. Is this
> > > > right?
> > >
> > > for DOS, withouth upper memory manager yes ;)
> >
> > I'm talking about an OS in protected mode... in any case how
> > can I access to this memory region if it's mapped for other things?
>
> this is usually done via the MMU which can do miracolous
> things to memory and addresses ...
>
> > I've done some tests with a simple kernel which I wrote: all that region
> > (except video memory at 0xb8000) results "read only"...
>
> because it is usually designated as rom area, which naturally
> is read only ...
>
> > So I THINK YOU mean: "you can use more than 640KB in real mode using
> > a memory manager that "remap" 0xC0000 (for example) to 0x100000 or
> > something like it"
>
> basically a memory manager (depending on the processors
> capabilities) does either use memory mapping or simple
> memory exchanging between designated regions and above
> 1M+64k memory ...
The MMU _is_ used to remap memory addresses. It is part of the CPU itself.
But it translates what's called "virtual address" space to "physical
address space". Physical addresses seemingly map directly to RAM and
memory-mapped I/O.
Paolo's question is, what happens to the 384k of _physical_ addresses
starting at 0xa0000, which should correspond with 384k of actual
physical RAM?
If you use the MMU to map a virtual address to the physical addresses from
0xa0000..0xfffff, then whichever virtual addresses you chose will map to
video memory, ROM, BIOS etc.
The answer is that after the MMU has translated, a _second_ address
translation takes place, outside the CPU, which maps the physical addresses
so that a hole is created in the RAM without any RAM going missing. This
second translation is done by the motherboard chipset.
Enjyo,
-- Jamie
next prev parent reply other threads:[~2003-08-19 1:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-18 9:27 Paolo Ornati
2003-08-18 18:55 ` Herbert Pötzl
2003-08-18 21:11 ` Paolo Ornati
2003-08-18 22:54 ` Herbert Pötzl
2003-08-19 1:02 ` Jamie Lokier [this message]
2003-08-18 16:34 ` Nagendra Singh Tomar
2003-08-19 16:30 ` Jamie Lokier
2003-08-19 8:01 ` Paolo Ornati
2003-08-19 15:23 ` Krzysztof Halasa
2003-08-19 0:53 ` Jamie Lokier
2003-08-18 10:14 John Bradford
2003-08-18 11:24 ` Paolo Ornati
2003-08-19 7:37 John Bradford
2003-08-19 11:48 ` 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=20030819010205.GE11081@mail.jlokier.co.uk \
--to=jamie@shareable.org \
--cc=javaman@katamail.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®