Documentation for PC Architecture
Hi,
(sorry for the OT but I think here someone will relpy :-)
Problem: I'm interested on PC architecture and looking for documentation I've found al lot of good doc for the CPU (Intel manuals...) but about the basic hardware that surround it I've found only a lot of "pieces of a puzzle"!
IOW: there is an (un)official document spoking about general PC architecture?
In this document I want to find some basic things about PC hardware and especially about these themes (from the logical point of view):
1) communication between CPU, memory, I/O devices:
Example:
If I write byte 'A' to physical address 0xb8000 how does this go to video memory instead of RAM?
I know about memory mapped I/O but I don't know who "decides" WHAT must go WHERE.
Since the CPU can't know if it's writing to memory or some memory mapped I/O device I suppose that is the "BUS CONTROLLER" (PCI BRIDGE in case of a PCI BUS) to write the byte 'A' to the right device.
But how does the "BUS CONTROLLER" do this association?
For now I think in this simple way:
- all the devices are on the BUS and anyone has his own memory mapped I/O addresses;
- if no devices own the address that the CPU ask for the request go to real memory.
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 the REAL MEMORY isn't usable and so we lost 384KB of memory. Is this right?
And what about the I/O address space (IN, OUT x86 instructions)? I know this is a separate address space but...
- how are the addresses assigned? In a static way?
- for these instructions the CPU uses the same address (and data) lines that when it try to acces to memory, how does this work?
2) Compatibilty issues:
for example something about A20 line... is it possible that I found information about this only in unofficial docs?
I didn't know about it before. A day I've found on a web page something like "enabling A20 line" and I've said: "A20 line? What is it?" ;-)
...
Must I search info for any "piece of the puzzle"? This is OK for me but I want to know AT LEAST which are the pieces!
Bye,
Paolo
Quoted 12 lines · Paolo Ornati
Hi,
(sorry for the OT but I think here someone will relpy :-)Problem: I'm interested on PC architecture and looking for documentation I've found al lot of good doc for the CPU (Intel manuals...) but about the basic hardware that surround it I've found only a lot of "pieces of a puzzle"!
IOW: there is an (un)official document spoking about general PC architecture?
In this document I want to find some basic things about PC hardware and especially about these themes (from the logical point of view):
Quoted 15 lines
1) communication between CPU, memory, I/O devices:
Example:
If I write byte 'A' to physical address0xb8000how does this go to video memory instead of RAM?
I know about memory mapped I/O but I don't know who "decides" WHAT must go WHERE.
Since the CPU can't know if it's writing to memory or some memory mapped I/O device I suppose that is the "BUS CONTROLLER" (PCI BRIDGE in case of a PCI BUS) to write the byte 'A' to the right device.
But how does the "BUS CONTROLLER" do this association?
For now I think in this simple way:
- all the devices are on the BUS and anyone has his own memory mapped I/O addresses;
- if no devices own the address that the CPU ask for the request go to real memory.
google for 'IBM' 'PC' 'architecture' ...
and variants of 'Upper Memory' 'Shadow' 'VGA' ...
(for example ...)
http://www.pcguide.com/ref/ram/logicOverview-c.html
http://www.infokomp.no/techinfo/doc/DosMemory.htm
http://world.std.com/~swmcd/steven/rants/pc.html
Quoted 2 lines
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 ...
Quoted 1 line
the REAL MEMORY isn't usable and so we lost 384KB of memory. Is this right?
for DOS, withouth upper memory manager yes ;)
Quoted 5 lines
And what about the I/O address space (IN, OUT x86 instructions)? I know this is a separate address space but...
- how are the addresses assigned? In a static way?
- for these instructions the CPU uses the same address (and data) lines that when it try to acces to memory, how does this work?
there is a line (signal) telling if it is memory or I/O ...
Quoted 10 lines
2) Compatibilty issues:
for example something about A20 line... is it possible that I found information about this only in unofficial docs?
I didn't know about it before. A day I've found on a web page something like "enabling A20 line" and I've said: "A20 line? What is it?" ;-)...
Must I search info for any "piece of the puzzle"? This is OK for me but I want to know AT LEAST which are the pieces!
HTH,
Herbert
Quoted 10 lines
Bye,
Paolo-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines
Quoted 4 lines
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 ...
Quoted 2 lines
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?
I've done some tests with a simple kernel which I wrote: all that region (except video memory at 0xb8000) results "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"
Right?
bye,
Paolo
Quoted 7 lines · Paolo Ornati
Quoted 7 lines
Quoted 4 lines
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 ...
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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 ...
Quoted 2 lines
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 ...
Quoted 3 lines
So I THINK YOU mean: "you can use more than 640KB in real mode using a memory manager that "remap"
0xC0000(for example) to0x100000or 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 ...
given an apropriate address mapping (via mmu) you should be able to access the entire memory (not just the first megabyte) without disturbing any memory mapped hardware ...
how could this be possible? simple there are 32 address lines on a full 386 and above, which gives you 4GB of physical memory addresses, now the memory mapped hardware (pci,agp, but also isa) is only activated if the address lies within a defined range. memory can be designated to a different range, like (ep)roms ...
for example the Intel 386EX allows to define signals for each configured memory range (chip selects) to enable or disable the devices (memory) on demand, other systems use some chipset/onboard logic to do this ...
Quoted 10 lines
Right?
bye,
Paolo-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 25 lines · Herbert Pötzl
Quoted 7 lines · Paolo Ornati
Quoted 7 lines
Quoted 4 lines
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 ...
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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 ...
Quoted 2 lines
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 ...
Quoted 8 lines
Quoted 3 lines
So I THINK YOU mean: "you can use more than 640KB in real mode using a memory manager that "remap"
0xC0000(for example) to0x100000or 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
Jamie,
What is this 2nd address translation you are mentioning.
I always thought that for the sake of cleanliness we just forget about the 384K of memory starting from 640K. RAM anyway is cheap.
Pl correct me if I'm missing something.
Thanx
tomar
Quoted 72 lines · Jamie Lokier
Quoted 3 lines · Herbert Pötzl
Quoted 2 lines · Paolo Ornati
Quoted 2 lines
Quoted 2 lines
Curiosity: since the memory addresses from 640KB to 1MB are
reserved for
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
memory mapped I/O (video memory) and BIOS ROM... the
corrispondent range
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
in
uh oh ...
Quoted 1 line
the REAL MEMORY isn't usable and so we lost 384KB of memory. Is
this
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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 ...
Quoted 1 line
I've done some tests with a simple kernel which I wrote: all that
region
Quoted 7 lines
Quoted 1 line
(except video memory at
0xb8000) results "read only"...because it is usually designated as rom area, which naturally is read only ...
Quoted 1 line
So I THINK YOU mean: "you can use more than 640KB in real mode using
Quoted 7 lines
Quoted 2 lines
a memory manager that "remap"
0xC0000(for example) to0x100000or 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-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Nagendra Singh Tomar
What is this 2nd address translation you are mentioning.
I always thought that for the sake of cleanliness we just forget about the 384K of memory starting from 640K. RAM anyway is cheap.
Pl correct me if I'm missing something.
That is probably true of modern machines. It is hard to tell from the e820 map on two machines I just looked at, because other bits of RAM are missing, more than 384k.
The original question asked about "the PC architecture", and I can say for sure that a PC with 1MB does not just forget about 384k of it :)
-- Jamie
Quoted 5 lines · Jamie Lokier
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.
I know...
Quoted 4 lines
Paolo's question is, what happens to the 384k of _physical_ addresses starting at
0xa0000, which should correspond with 384k of actual physical RAM?
It seems that only you have understand my question! :-)
Quoted 9 lines
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.
OK.
Quoted 3 lines
Enjyo,
-- Jamie
VERY [OT]:
Why do I do all these questions?
At present I'm working on a very small kernel (PabloX :):
- it's very simple: it only uses segmentation and has drivers only for stupid things like AT-PS/2 keyboard (do you have USB keyboard? I'm sorry!)
- some (a lot of) code is taken from linux 0.01 / 1.0 / ...
If anyone want to see this stupid thing:
http://members.xoom.virgilio.it/javaman/
NOTE: don't read the comments in source code! They are a mix of pseudo-English and Italian!
To try it:
tar xzf pablox.tar.gx
cd pablox/
make
now you should have a floppy image in ./IMAGE, I suggest insert a floppy and do "make disk", than reboot and see keyboard leds! (if you have an AT or PS/2 keyboard)
press (1,2,3,4) to switch to console (1,2,3,4): the consoles are stupid! All the programs write to the current console...
press "ESC" to reboot!
Bye,
Paolo
Quoted 3 lines · Jamie Lokier
Paolo's question is, what happens to the 384k of _physical_ addresses starting at
0xa0000, which should correspond with 384k of actual physical RAM?
Part of it is used for BIOS (shadow of EPROM/flash EPROM - usually written by BIOS executing from EPROM and then made read-only by programming chipset registers). This involves main motherboard BIOS (usually 64 KB at 0xF000-0xFFFF) and any extension BIOSes (VGA, LAN etc) in 0xC000-0xEFFF (or 0xC000-0xDFFF) range.
The remaining RAM from 0xA000-0xFFFF is unusable. One could program chipset registers to enable parts of this RAM. It would require knowledge of particular chipset registers, and there might be only one read-only/read-write bit for all shadows (so, unless you want the shadow BIOS to be R/W, the additional RAM would have to be R/O). RAM is quite cheap and these things are very non-standard so I think nobody bothers.
And yes, older machines (older chipsets) used to remap fragments of this memory to the top of RAM. It was common on 80286 machines and I probably haven't seen a 386DX or faster board doing that.
Signature · 2 lines
Krzysztof Halasa Network Administrator
Quoted 2 lines · Paolo Ornati
So I THINK YOU mean: "you can use more than 640KB in real mode using a memory manager that "remap"
0xC0000(for example) to0x100000or something like it"
As with all things PC, you cannot easily tell what RAM address it is mapped to, but yes, it is remapped somewhere by the memory controller so that it isn't wasted.
Perhaps on machines with lots of RAM this isn't done any more.
Also, these days there are other regions of RAM which you cannot see, because they are only available to the BIOS, when the CPU is in SMM mode :)
Your larger question, about how addresses are matched by the hardware, is a complex one and it is different on different PC systems. That is some 20 years of computing history; it has changed a lot even though many of the old programming methods continue to be supported.
Your best bet is to learn about PCI, PCI configuration space, PCI transactions, PCI bridges and additive/subtractive decoding, northbridge and southbridge chipsets (just what they are), PCI to ISA bridge, legacy I/O controller (what provides most of the ISA space I/O ports), AGP and GART, MTRR registers, and get some idea of how the L1/L2/L3 cache hierarchy works.
And of course read all the big x86 manuals from developer.intel.com :-)
Your other large question, How does a PC work?, is huge because there is much variety. For example, on every other architecture in the world, interrupts are quite simple, easy to program and easy to understand. On a modern PC they are extraordinarily complicated, to the point where even the top kernel developers are still changing the code, year on year, to workaround new surprises in different PCs. As you see, there is no readily available answer to your question that is definitive for all the PCs out there. Unfortunately.
-- Jamie