| Author |
Message |
Zdenek Sojka
Guest
|
 Posted:
Thu Dec 01, 2005 1:15 am Post subject:
First instruction executed after RESET and A20 cache consist |
|
|
Hello,
I have two and a half questions:
In Intel documentation, there is a paragraph showing that first instruction
executed is at 0xfffffff0 (4GB-16B).
But as far as I know, the ROM BIOS is located 'under first megabyte' - at
0xffff0 (this is a FAR JMP instruction, the first to be executed).
Also, there is third possibility - when A20 is turned off, the first
physical address of instruction is 0xffeffff0.
All these 3 addresses have to be translated to ROM are. Is this done in
chipset?
Second question is about A20. When it is turned off, is maintenanted cache
consistency? (eg. writing to 1MB+5B changes the byte at 5B in both cache and
RAM) What about when the A20 is turned off just before write to this
address- and so, it can be interpretted as turned off, but has not rise up
yet? (I think there is some #A20 pin at CPU - is it an input pin?) And when
the A20 rise up after write to cache, but before the cache is written back?
(well... it could even damage interrupt vectors when turning off A20 - th
content of 1MB+nB can be written to 0MB+nB)
Anyway - was there any real reason to use A20 than just unneeded backware
compatibility? (eg., was there any software using aliasing after 1MB?)
Thanks all,
Zdenek Sojka |
|
| Back to top |
|
 |
robertwessel2@yahoo.com
Guest
|
| Posted:
Thu Dec 01, 2005 9:15 am Post subject:
Re: First instruction executed after RESET and A20 cache con |
|
|
Zdenek Sojka wrote:
| Quote: | Hello,
I have two and a half questions:
In Intel documentation, there is a paragraph showing that first instruction
executed is at 0xfffffff0 (4GB-16B).
But as far as I know, the ROM BIOS is located 'under first megabyte' - at
0xffff0 (this is a FAR JMP instruction, the first to be executed).
|
On CPU reset the descriptor cache for CS is loaded with 0xffff0000 and
IP with 0xfff0. This results in instructions being fetched from
physical location 0xfffffff0. As soon as you do anything to reload CS,
normal real mode addressing rules will apply. Before the reload of CS,
it's still real mode, but CS "magically" points to the top 64KB of the
4GB address space, even though the value in CS is still 0xf000.
What this allows is for a system where the initial boot code is in ROM
at a convenient out-of-the-way location (you could have boot code at
physical addresses 0xffff0000 through 0xffffffff), and you can execute
in real mode, in that area as long as you do not reload CS. If you did
nothing in that code but switch into protected mode, that would be a
good thing.
Unfortunately compatibility issues (notably the requirement to support
a real mode BIOS and boot sequence) prevent a PC from doing that. So
essentially all motherboards map the boot ROM to both areas -
0xffff0000 *and* 0x000f0000. So when that "jmp 0xf000:xxxx) is
executed, control moves to the copy of the ROM at the traditional
location. If we go back to the 286, the primary copy of the boot ROM
was at the top of the 16MB physical address space (IOW at 0xff0000).
A system not constrained by PC compatibility could execute a few dozen
instructions in the high-address real mode and then switch into a
protected mode "BIOS," and never look back to real mode.
| Quote: | Also, there is third possibility - when A20 is turned off, the first
physical address of instruction is 0xffeffff0.
|
It's possible some motherboards shadow the BIOS into that range as
well, but typically A20M will not be enabled after a reset, an so it is
not necessary.
| Quote: | All these 3 addresses have to be translated to ROM are. Is this done in
chipset?
|
Yes.
| Quote: | Second question is about A20. When it is turned off, is maintenanted cache
consistency? (eg. writing to 1MB+5B changes the byte at 5B in both cache and
RAM) What about when the A20 is turned off just before write to this
address- and so, it can be interpretted as turned off, but has not rise up
yet? (I think there is some #A20 pin at CPU - is it an input pin?) And when
the A20 rise up after write to cache, but before the cache is written back?
(well... it could even damage interrupt vectors when turning off A20 - th
content of 1MB+nB can be written to 0MB+nB)
|
Yes, the A20M pin is an input - on PC's it's the keyboard controller
chip that drives it. A20M (on at least 486 and later processors) only
applies to addresses generated in real mode anyway, and modifies the
addresses before they hit cache (this is why A20M is an input on all
processors that actually have cache), so no cache consistency issues
can occur.
| Quote: | Anyway - was there any real reason to use A20 than just unneeded backware
compatibility? (eg., was there any software using aliasing after 1MB?)
|
The story was that there *was* software assuming address wrap-around
when the AT was introduced (which was why the A20 mask was introduced
there), but I don't know that I've ever seen a real example. |
|
| Back to top |
|
|
Zdenek Sojka
Guest
|
| Posted:
Fri Dec 02, 2005 1:15 am Post subject:
Re: First instruction executed after RESET and A20 cache con |
|
|
<robertwessel2@yahoo.com> píse v diskusním príspevku
news:1133417461.165034.128900@g14g2000cwa.googlegroups.com...
| Quote: |
Zdenek Sojka wrote:
Hello,
I have two and a half questions:
In Intel documentation, there is a paragraph showing that first
instruction
executed is at 0xfffffff0 (4GB-16B).
But as far as I know, the ROM BIOS is located 'under first megabyte' -
at
0xffff0 (this is a FAR JMP instruction, the first to be executed).
On CPU reset the descriptor cache for CS is loaded with 0xffff0000 and
IP with 0xfff0. This results in instructions being fetched from
physical location 0xfffffff0. As soon as you do anything to reload CS,
normal real mode addressing rules will apply. Before the reload of CS,
it's still real mode, but CS "magically" points to the top 64KB of the
4GB address space, even though the value in CS is still 0xf000.
What this allows is for a system where the initial boot code is in ROM
at a convenient out-of-the-way location (you could have boot code at
physical addresses 0xffff0000 through 0xffffffff), and you can execute
in real mode, in that area as long as you do not reload CS. If you did
nothing in that code but switch into protected mode, that would be a
good thing.
Unfortunately compatibility issues (notably the requirement to support
a real mode BIOS and boot sequence) prevent a PC from doing that. So
essentially all motherboards map the boot ROM to both areas -
0xffff0000 *and* 0x000f0000. So when that "jmp 0xf000:xxxx) is
executed, control moves to the copy of the ROM at the traditional
location. If we go back to the 286, the primary copy of the boot ROM
was at the top of the 16MB physical address space (IOW at 0xff0000).
|
Interesting, I didn't know that... I could try if I got my 286 back working.
The idea of placing ROM to the top of memory is undestandable, but the
backward compatibility makes bad here.
| Quote: |
A system not constrained by PC compatibility could execute a few dozen
instructions in the high-address real mode and then switch into a
protected mode "BIOS," and never look back to real mode.
|
Well, if the first instruction was a near jump, the CS.base would stay
loaded with 0xffff0000, wouldn't it?
| Quote: |
Also, there is third possibility - when A20 is turned off, the first
physical address of instruction is 0xffeffff0.
It's possible some motherboards shadow the BIOS into that range as
well, but typically A20M will not be enabled after a reset, an so it is
not necessary.
|
Does the MB know that CPU got a reset? (eg. triple-faulting CPU or some
other conditions make CPU reset itself)
And anyway - if it knew, would it turn on A20 before the CPU starts
executing instructions?
As I were steeping thru BIOS loader, it first turned A20 on - so it were off
when resetting (AFAIR)
| Quote: |
All these 3 addresses have to be translated to ROM are. Is this done in
chipset?
Yes.
|
So there is not any A20 emulation done in CPU?
eg. is this still handled by KB controller (or chipset etc.), not at CPU?
(CPUs are not dedicated to be run at IBM-PC architecture, so it would be
useless for other architectures... but it could make some things easier -
with exception that some devices might use adress bus too, and there could
be conflict, if the "MB's A20" is everytime on, but that in CPU is off...
ok, nevermind)
| Quote: |
Second question is about A20. When it is turned off, is maintenanted
cache
consistency? (eg. writing to 1MB+5B changes the byte at 5B in both cache
and
RAM) What about when the A20 is turned off just before write to this
address- and so, it can be interpretted as turned off, but has not rise
up
yet? (I think there is some #A20 pin at CPU - is it an input pin?) And
when
the A20 rise up after write to cache, but before the cache is written
back?
(well... it could even damage interrupt vectors when turning off A20 -
th
content of 1MB+nB can be written to 0MB+nB)
Yes, the A20M pin is an input - on PC's it's the keyboard controller
chip that drives it. A20M (on at least 486 and later processors) only
applies to addresses generated in real mode anyway, and modifies the
addresses before they hit cache (this is why A20M is an input on all
processors that actually have cache), so no cache consistency issues
can occur.
|
I dont think so... maybe I misunderstood you, but when the CPU switches to
PM, it is up to programmer to turn on A20. Or is there some pin which in PM
is activated and chipset turns A20 on then automatically?
Thanks,
Zdenek |
|
| Back to top |
|
|
robertwessel2@yahoo.com
Guest
|
| Posted:
Fri Dec 02, 2005 1:15 am Post subject:
Re: First instruction executed after RESET and A20 cache con |
|
|
Zdenek Sojka wrote:
| Quote: | A system not constrained by PC compatibility could execute a few dozen
instructions in the high-address real mode and then switch into a
protected mode "BIOS," and never look back to real mode.
Well, if the first instruction was a near jump, the CS.base would stay
loaded with 0xffff0000, wouldn't it?
|
Exactly. But in the case where a system did not care about real mode,
it would quickly switch into protected mode, and (presumably) never
reload CS until the switch, so that bit of real mode code can live
anywhere in the 0xffff0000 segment, and you wouldn't have to mess up
your system's address space by mapping a ROM into the 0xf0000 range.
| Quote: |
Also, there is third possibility - when A20 is turned off, the first
physical address of instruction is 0xffeffff0.
It's possible some motherboards shadow the BIOS into that range as
well, but typically A20M will not be enabled after a reset, an so it is
not necessary.
Does the MB know that CPU got a reset? (eg. triple-faulting CPU or some
other conditions make CPU reset itself)
And anyway - if it knew, would it turn on A20 before the CPU starts
executing instructions?
As I were steeping thru BIOS loader, it first turned A20 on - so it were off
when resetting (AFAIR)
|
The CPU does not reset itself. If it triple faults, it enters a
specific shutdown/halt state, and then the motherboard (chipset) resets
it.
In any event this is an interesting question - while the CPU is reset
after a triple fault (or the explicit CPU reset request), the
motherboard is not, and by extension the A20 signal from the keyboard
controller will not be either. This implies that the A20 gated reset
will either generate addresses in 0xffef0000 range, which would require
that third mapping for the BIOS ROM, or that the A20 gate is ignored
for those high addresses generated in the reset sequence before the
first CS reload. The later would be my guess.
| Quote: | So there is not any A20 emulation done in CPU?
eg. is this still handled by KB controller (or chipset etc.), not at CPU?
(CPUs are not dedicated to be run at IBM-PC architecture, so it would be
useless for other architectures... but it could make some things easier -
with exception that some devices might use adress bus too, and there could
be conflict, if the "MB's A20" is everytime on, but that in CPU is off...
ok, nevermind)
|
All of the A20 gate handling is done in the CPU. The A20 gate
circuitry is buried someplace between the final stages of the CPUs
address generation logic and the L1 cache. It's just that the
processing is controlled by the A20M signal, which traditionally comes
from the keyboard controller. Note that many chipsets have alternative
ways to drive the A20M signal, which are much faster than using the
keyboard controller.
| Quote: | Yes, the A20M pin is an input - on PC's it's the keyboard controller
chip that drives it. A20M (on at least 486 and later processors) only
applies to addresses generated in real mode anyway, and modifies the
addresses before they hit cache (this is why A20M is an input on all
processors that actually have cache), so no cache consistency issues
can occur.
I dont think so... maybe I misunderstood you, but when the CPU switches to
PM, it is up to programmer to turn on A20. Or is there some pin which in PM
is activated and chipset turns A20 on then automatically?
|
That was certainly true on 286 and 386 systems. On 486 and later
systems, A20M is ignored in protected mode. Of course turning the A20
gate off before switching into protected mode certainly wont hurt
anything. OTOH, I have never seen any code that switches into
protected mode *without* ensuring the A20 gate is off (after all,
it's only a few lines of code). |
|
| Back to top |
|
|
Zdenek Sojka
Guest
|
| Posted:
Sat Dec 03, 2005 1:15 am Post subject:
Re: First instruction executed after RESET and A20 cache con |
|
|
Thanks for all answers, I have read some documents from Intel now and it
seems interesting. (anyway, there are not so much information about A20M, as
you gave me) Also, thanks for killing some of my thoughts I was almost sure
with!
I will do some tests later.
Have a nice day,
Zdenek
<robertwessel2@yahoo.com> píse v diskusním príspevku
news:1133479055.811455.298250@z14g2000cwz.googlegroups.com...
| Quote: |
Zdenek Sojka wrote:
A system not constrained by PC compatibility could execute a few
dozen
instructions in the high-address real mode and then switch into a
protected mode "BIOS," and never look back to real mode.
Well, if the first instruction was a near jump, the CS.base would stay
loaded with 0xffff0000, wouldn't it?
Exactly. But in the case where a system did not care about real mode,
it would quickly switch into protected mode, and (presumably) never
reload CS until the switch, so that bit of real mode code can live
anywhere in the 0xffff0000 segment, and you wouldn't have to mess up
your system's address space by mapping a ROM into the 0xf0000 range.
Also, there is third possibility - when A20 is turned off, the first
physical address of instruction is 0xffeffff0.
It's possible some motherboards shadow the BIOS into that range as
well, but typically A20M will not be enabled after a reset, an so it
is
not necessary.
Does the MB know that CPU got a reset? (eg. triple-faulting CPU or some
other conditions make CPU reset itself)
And anyway - if it knew, would it turn on A20 before the CPU starts
executing instructions?
As I were steeping thru BIOS loader, it first turned A20 on - so it were
off
when resetting (AFAIR)
The CPU does not reset itself. If it triple faults, it enters a
specific shutdown/halt state, and then the motherboard (chipset) resets
it.
In any event this is an interesting question - while the CPU is reset
after a triple fault (or the explicit CPU reset request), the
motherboard is not, and by extension the A20 signal from the keyboard
controller will not be either. This implies that the A20 gated reset
will either generate addresses in 0xffef0000 range, which would require
that third mapping for the BIOS ROM, or that the A20 gate is ignored
for those high addresses generated in the reset sequence before the
first CS reload. The later would be my guess.
So there is not any A20 emulation done in CPU?
eg. is this still handled by KB controller (or chipset etc.), not at
CPU?
(CPUs are not dedicated to be run at IBM-PC architecture, so it would be
useless for other architectures... but it could make some things
easier -
with exception that some devices might use adress bus too, and there
could
be conflict, if the "MB's A20" is everytime on, but that in CPU is
off...
ok, nevermind)
All of the A20 gate handling is done in the CPU. The A20 gate
circuitry is buried someplace between the final stages of the CPUs
address generation logic and the L1 cache. It's just that the
processing is controlled by the A20M signal, which traditionally comes
from the keyboard controller. Note that many chipsets have alternative
ways to drive the A20M signal, which are much faster than using the
keyboard controller.
Yes, the A20M pin is an input - on PC's it's the keyboard controller
chip that drives it. A20M (on at least 486 and later processors) only
applies to addresses generated in real mode anyway, and modifies the
addresses before they hit cache (this is why A20M is an input on all
processors that actually have cache), so no cache consistency issues
can occur.
I dont think so... maybe I misunderstood you, but when the CPU switches
to
PM, it is up to programmer to turn on A20. Or is there some pin which in
PM
is activated and chipset turns A20 on then automatically?
That was certainly true on 286 and 386 systems. On 486 and later
systems, A20M is ignored in protected mode. Of course turning the A20
gate off before switching into protected mode certainly wont hurt
anything. OTOH, I have never seen any code that switches into
protected mode *without* ensuring the A20 gate is off (after all,
it's only a few lines of code).
|
|
|
| Back to top |
|
|
Zdenek Sojka
Guest
|
| Posted:
Tue Dec 06, 2005 1:15 am Post subject:
Re: First instruction executed after RESET and A20 cache con |
|
|
Ok, I did some tests and:
when in PM and A20 off:
0xfffff800 = nul
0xfffef800 = nul
0xff800 = BIOS
0x10000 = 0x00000
when in PM and A20 on:
0xfffff800 = some BIOS
0xfffef800 = nul
0x000ff800 = BIOS
0x10000 = 0x00000
BIOS at 4GB is different than one at 1MB ( 0xfffff800 != 0x000ff800 )
going into PM doesnt implicitly enable A20
(disabled A20 -> A20=0 )
Tested on PMMX 200MHz / 96 MB RAM
So now, I am really confused... The A20 must be turned on before CPU is
resetted (as you said, it never resets itself - so chipset first turns on
A20, then resets the CPU)
"Zdenek Sojka" <XzsoXjkaX@XsezXnamX.cz> píše v diskusním příspěvku
news:dmqkca$avt$1@ns.felk.cvut.cz...
| Quote: | Thanks for all answers, I have read some documents from Intel now and it
seems interesting. (anyway, there are not so much information about A20M,
as
you gave me) Also, thanks for killing some of my thoughts I was almost
sure
with!
I will do some tests later.
Have a nice day,
Zdenek
robertwessel2@yahoo.com> píse v diskusním príspevku
news:1133479055.811455.298250@z14g2000cwz.googlegroups.com...
Zdenek Sojka wrote:
A system not constrained by PC compatibility could execute a few
dozen
instructions in the high-address real mode and then switch into a
protected mode "BIOS," and never look back to real mode.
Well, if the first instruction was a near jump, the CS.base would stay
loaded with 0xffff0000, wouldn't it?
Exactly. But in the case where a system did not care about real mode,
it would quickly switch into protected mode, and (presumably) never
reload CS until the switch, so that bit of real mode code can live
anywhere in the 0xffff0000 segment, and you wouldn't have to mess up
your system's address space by mapping a ROM into the 0xf0000 range.
Also, there is third possibility - when A20 is turned off, the
first
physical address of instruction is 0xffeffff0.
It's possible some motherboards shadow the BIOS into that range as
well, but typically A20M will not be enabled after a reset, an so it
is
not necessary.
Does the MB know that CPU got a reset? (eg. triple-faulting CPU or
some
other conditions make CPU reset itself)
And anyway - if it knew, would it turn on A20 before the CPU starts
executing instructions?
As I were steeping thru BIOS loader, it first turned A20 on - so it
were
off
when resetting (AFAIR)
The CPU does not reset itself. If it triple faults, it enters a
specific shutdown/halt state, and then the motherboard (chipset) resets
it.
In any event this is an interesting question - while the CPU is reset
after a triple fault (or the explicit CPU reset request), the
motherboard is not, and by extension the A20 signal from the keyboard
controller will not be either. This implies that the A20 gated reset
will either generate addresses in 0xffef0000 range, which would require
that third mapping for the BIOS ROM, or that the A20 gate is ignored
for those high addresses generated in the reset sequence before the
first CS reload. The later would be my guess.
So there is not any A20 emulation done in CPU?
eg. is this still handled by KB controller (or chipset etc.), not at
CPU?
(CPUs are not dedicated to be run at IBM-PC architecture, so it would
be
useless for other architectures... but it could make some things
easier -
with exception that some devices might use adress bus too, and there
could
be conflict, if the "MB's A20" is everytime on, but that in CPU is
off...
ok, nevermind)
All of the A20 gate handling is done in the CPU. The A20 gate
circuitry is buried someplace between the final stages of the CPUs
address generation logic and the L1 cache. It's just that the
processing is controlled by the A20M signal, which traditionally comes
from the keyboard controller. Note that many chipsets have alternative
ways to drive the A20M signal, which are much faster than using the
keyboard controller.
Yes, the A20M pin is an input - on PC's it's the keyboard controller
chip that drives it. A20M (on at least 486 and later processors)
only
applies to addresses generated in real mode anyway, and modifies the
addresses before they hit cache (this is why A20M is an input on all
processors that actually have cache), so no cache consistency issues
can occur.
I dont think so... maybe I misunderstood you, but when the CPU
switches
to
PM, it is up to programmer to turn on A20. Or is there some pin which
in
PM
is activated and chipset turns A20 on then automatically?
That was certainly true on 286 and 386 systems. On 486 and later
systems, A20M is ignored in protected mode. Of course turning the A20
gate off before switching into protected mode certainly wont hurt
anything. OTOH, I have never seen any code that switches into
protected mode *without* ensuring the A20 gate is off (after all,
it's only a few lines of code).
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in