> On Fri, 01 Oct 2004 20:14:07 GMT, Tauno Voipio
> <tauno.voipio@iki.fi.NOSPAM.invalid> wrote:
>
>
>>Ignacio G.T. wrote:
>
> That would be great. Just in case I get stuck with the jump to protected mode.
Ignacio,
please send me you working mail address. The yahoo.es address
refused my mail.
Correct my address in the sig in the obvous way to send.
Tauno Voipio
tauno voipio (at) iki fi
Reply by Jonathan Kirwan●October 4, 20042004-10-04
On Mon, 04 Oct 2004 09:32:16 GMT, igtorque.remove@evomer.yahoo.es (Ignacio G.T.)
wrote:
>Yes, Jon. Now I can LGDT using two different approaches and, best of all, I
>understand both !
Wonderful!
I remember the first time I decided to write code to enter protected mode and
some of the troubles. And... my excitement when I first turned on the paging
system and remapped the VGA memory to a different linear address and it worked
when I wrote characters there! (Interrupts disabled, that first time, because
biting off setting up a decent IDT was a bit much.) I then went back to DOS
mode and exited without crashing, afterwards! Wonderful feeling getting that
right!
Best of luck!
Jon
Reply by Ignacio G.T.●October 4, 20042004-10-04
On Fri, 01 Oct 2004 21:52:08 GMT, Jonathan Kirwan <jkirwan@easystreet.com>
wrote:
>Looks like you have had some good advice and thinking already. Rather than try
>and understand it all, I'll just add some quick thoughts of my own.
>
[lots of useful info]
>
>Does any of that help?
>
Yes, Jon. Now I can LGDT using two different approaches and, best of all, I
understand both !
--
Ignacio G.T.
Reply by Ignacio G.T.●October 4, 20042004-10-04
On Fri, 01 Oct 2004 20:14:07 GMT, Tauno Voipio
<tauno.voipio@iki.fi.NOSPAM.invalid> wrote:
>Ignacio G.T. wrote:
>> Bad news, David. I've just tried
>>
>> LGDT CS:[FFFFF888]
>>
>> and the results are the same.
>>
>> Intel's manual says this, for the LGDT instruction:
>>
>
>Did you try
>
> LGDT CS:[f888]
>
>Please note that the processor is in *16* bit
>mode till the descriptors are in and protected
>mode is turned on.
Thanks, Tauno. You are right. It works with this:
66 67 2E 0F 01 15 88 F8 00 00
i.e.
LGDT CS:[0000F888]
>
>There is somewhere in the back of my trash box
>a piece of code that boots an i386 into 32-bit
>protected mode. If it is of any help, I could
>find it among the dusty backup CD's.
That would be great. Just in case I get stuck with the jump to protected mode.
>
>Tauno Voipio
>tauno voipio (at) iki fi
>
--
Ignacio G.T.
Reply by David Lindauer●October 2, 20042004-10-02
that won't work because you have to take into account the base address of CS:... which
is FFFF0000.
you should do:
LGDT CS:[F888]
what you did GPFs because the limit on CS is 64K as well, and when you add in the base
you are out
of range.
David
"Ignacio G.T." wrote:
> On Fri, 01 Oct 2004 09:30:57 GMT, igtorque.remove@evomer.yahoo.es (Ignacio G.T.)
> wrote:
>
> >On Fri, 01 Oct 2004 00:20:59 GMT, David Lindauer <camille@bluegrass.net> wrote:
> >
> >>bear in mind the processor WILL do segmentation faults while in real mode, I don't
> >>remember whether it is a catch-all or if there are more restrictive rules though.
> >>So if you really can't figure things like this out you might hook int 0x0d and see
> >>if it gets triggered.
> >
> >You are right. In fact, after posting the original message, I filled the
> >interrupt vectors zone with pointers to difrent HLT instructions, and the GP
> >vector (0x0d) was triggered.
> >
> >>It has been a while since I did raw protected mode, but the one thing that jumps
> >>out at me is you are
> >>reading from 0fffff890h with no segment prefix, and with DS=0 where the limit on
> >>DS is 0ffffh according to your dumps. This is I think what you do get when you
> >>boot... I am wondering if you may get a segmentation fault under these
> >>conditions? I don't know for sure on this since I haven't dealt with the boot-up
> >>process personally. But if this is the case you can get around it by forcing a
> >>CS: prefix on the faulting instruction and changing the offset accordingly.
> >
> >It sounds reasonable. I'm trying it right now.
> >
> >Thank you, David.
> >
>
> Bad news, David. I've just tried
>
> LGDT CS:[FFFFF888]
>
> and the results are the same.
>
> Intel's manual says this, for the LGDT instruction:
>
> ===
> Real-Address Mode Exceptions
> ------------------------------------
> #UD If source operand is not a memory location.
> #GP If a memory operand effective address is outside the CS, DS, ES, FS, or
> GS segment limit.
> #SS If a memory operand effective address is outside the SS segment limit.
> ===
>
> We know its a #GP, but I still don't know why. Perhaps I should try copying the
> GDT to RAM and trying to load it from there...
>
> --
> Ignacio G.T.
Reply by Jonathan Kirwan●October 1, 20042004-10-01
Looks like you have had some good advice and thinking already. Rather than try
and understand it all, I'll just add some quick thoughts of my own.
When the processor starts up, it starts in 'real' mode. It's still actually in
protected mode, but the internal cached versions of descriptor entries are
pre-loaded by the processor reset to use USE16 segment interpretations and to
specify default behavior that 'appears' to be real mode behavior.
In your case, you correctly identify the fact that the CPU, by default, starts
up at the end of 32-bit memory, using CS = F000 and EIP = 0000FFF0. However,
the CS register's contents are essentially ignored during operation, as they are
meaningless to the actual hardware. Instead, the hardware uses the "hidden"
cached copies of the descriptor, which on reset for the CS are:
Value = F000H
Base = FFFF0000H
Limit = FFFFH
AR = Present,
R/W,
Accessed
The value, as I said, isn't used by the bus interface unit. It is always
ignored. When you load a segment/selector register, the processor looks at CR0
to determine "real or protected" and then either precodes the base and limit
through a fixed calculation on the loaded value (if in real mode) or else goes
out into memory and loads them from the indicated place. But in no case, not
ever, whether CR0 says real or protected mode, does the processor's BIU ever use
the value field. It's ignored, except for a tiny moment in time when it first
gets loaded.
So when you say the "hidden part of CS is 0xFFFF0000" what you really mean is
that the base field of the cached area related to CS is that value.
Note that the Limit is still 0xFFFF!
This will be used, whether or not you like it, to validate any offset values you
try and apply when referring to CS. You need your offset to remain within a 64k
area of where the CS base refers.
I *do* have to disagree with Chris when he says, "32-bit addresses greater than
0xFFFF are illegal in real mode." It is CR0 that decides what mode your are in,
but that has absolutely nothing to do with what kind of offsets are accepted.
It is strictly the Limit field of the cached region in the CPU associated with
the selector that decides this. And it does so without any regard whatsoever
for the CR0 status. You can load up the CS when in protected mode and thereby
control what goes into this cache and then you can switch back to real mode and
the cached Limit field will still operate. If you set it to some very large
limit, you will be allowed to use very large offsets even while in what is
supposed to be real mode, according to the CR0 condition. So long as you don't
reload CS while in real mode you won't blow that cached value. Of course, if
you do change CS while in real mode, that Limit field will immediately get
recoded back to 0xFFFF and your CS segment will again be limited.
One thing to keep in mind is that when the processor first comes out of reset it
does NOT have paging enabled. Without paging, it is impossible to generate
anything other than 0 for the upper 4 bits of the 36 bit physical addresses.
Instead, only the low-order 32-bits are used. The initial address executed has
to be found in the flash or ROM that must be located at that place. The first
JMP you encounter, the one going to 0xF800, does not change the CS. So these
addresses are still "high."
Your LGDT is executed quite quickly, I gather, after that point. I assume that
your CR0 still has you in real mode at this point in time and that the Limit
field for the CS still applies and is tiny. As such, your offset there is far
too big.
Also, take a close look at the description for the LGDT instruction. I've
usually used a DB 66h before the instruction to force the operand size from the
USE16 I'm currently running in to the USE32 interpretation, because I want the
16-bit limit and 32-bit base, not the 16-bit limit and 24-bit base for the data
I'm pointing to. Also, you'll need to then change CR0 and perform a JMP to
flush the instruction pipeline to start new instruction interpretations
afterwards.
Does any of that help?
Jon
Reply by Tauno Voipio●October 1, 20042004-10-01
Ignacio G.T. wrote:
> Bad news, David. I've just tried
>
> LGDT CS:[FFFFF888]
>
> and the results are the same.
>
> Intel's manual says this, for the LGDT instruction:
>
Did you try
LGDT CS:[f888]
Please note that the processor is in *16* bit
mode till the descriptors are in and protected
mode is turned on.
There is somewhere in the back of my trash box
a piece of code that boots an i386 into 32-bit
protected mode. If it is of any help, I could
find it among the dusty backup CD's.
Tauno Voipio
tauno voipio (at) iki fi
Reply by Ignacio G.T.●October 1, 20042004-10-01
>===
>
>We know its a #GP, but I still don't know why. Perhaps I should try copying the
>GDT to RAM and trying to load it from there...
>
Well, that has worked. Copy the GTD to RAM (0x0400), copy the GDT descriptor
just after the GDT (0x0418), and load the GDT with LGDT 0x00000418.
Now, switching to protected mode. Stay tuned...
--
Ignacio G.T.
Reply by Ignacio G.T.●October 1, 20042004-10-01
On Fri, 01 Oct 2004 09:30:57 GMT, igtorque.remove@evomer.yahoo.es (Ignacio G.T.)
wrote:
>On Fri, 01 Oct 2004 00:20:59 GMT, David Lindauer <camille@bluegrass.net> wrote:
>
>>bear in mind the processor WILL do segmentation faults while in real mode, I don't
>>remember whether it is a catch-all or if there are more restrictive rules though.
>>So if you really can't figure things like this out you might hook int 0x0d and see
>>if it gets triggered.
>
>You are right. In fact, after posting the original message, I filled the
>interrupt vectors zone with pointers to difrent HLT instructions, and the GP
>vector (0x0d) was triggered.
>
>>It has been a while since I did raw protected mode, but the one thing that jumps
>>out at me is you are
>>reading from 0fffff890h with no segment prefix, and with DS=0 where the limit on
>>DS is 0ffffh according to your dumps. This is I think what you do get when you
>>boot... I am wondering if you may get a segmentation fault under these
>>conditions? I don't know for sure on this since I haven't dealt with the boot-up
>>process personally. But if this is the case you can get around it by forcing a
>>CS: prefix on the faulting instruction and changing the offset accordingly.
>
>It sounds reasonable. I'm trying it right now.
>
>Thank you, David.
>
Bad news, David. I've just tried
LGDT CS:[FFFFF888]
and the results are the same.
Intel's manual says this, for the LGDT instruction:
===
Real-Address Mode Exceptions
------------------------------------
#UD If source operand is not a memory location.
#GP If a memory operand effective address is outside the CS, DS, ES, FS, or
GS segment limit.
#SS If a memory operand effective address is outside the SS segment limit.
===
We know its a #GP, but I still don't know why. Perhaps I should try copying the
GDT to RAM and trying to load it from there...
--
Ignacio G.T.