Page 1 of 1
More Probs with PMode
Posted: Sat Aug 31, 2002 8:24 am
by pskyboy
[attachment deleted by admin]
Re:More Probs with PMode
Posted: Sat Aug 31, 2002 9:17 am
by crazybuddha
I think I answered this already.
Try using ORG 0x7c00, which will be added to your offset. Once you switch the processor, the CS value is what you put in the GDT (specifically the base address of 0).
You need to put some code in your 32-bit 'section'. Even jmp $ would prevent the processor from walking through the RAM and resetting.
As far as triple-faulting goes, clean up some of this other stuff and see where you are.
Re:More Probs with PMode
Posted: Sat Aug 31, 2002 8:32 pm
by Tom
doesn't A20 have to be done after pmode?
Re:More Probs with PMode
Posted: Sat Aug 31, 2002 10:27 pm
by Schol-R-LEA
Tom wrote:
doesn't A20 have to be done after pmode?
No, they are unrelated issues. It is possible to set the a20 line in real mode and access the so-called 'high memory area' (the 64K-16k area above the first 1M. A system running in real mode which has 21 or more address lines (i.e., the 80286 and later) is capable of addressing this due to a quirk of the segment:offset scheme which is explained in detail
elsewhere). This is, in fact, the primary function of the MS-DOS 'himem.sys' driver.
You might want to see my
explanation/rant on segmentation and
another explanation gave of the a20 line to help clarify things (though each has a few embarassing typos and errors, they are mostly correct).
Re:More Probs with PMode
Posted: Sun Sep 01, 2002 10:30 am
by pskyboy
Hey Guys
I think you did say this before crazy budda but i tried it then and again when you posted again and i just can't get it to work for the life of me. Is it a problem with my GDT Tables cos thats all i can think it is or do i have to set up all segments as soon as i switch to PMode?
Cheers
Peter
Re:More Probs with PMode
Posted: Mon Sep 02, 2002 1:19 am
by Pype.Clicker
there is no chance for this code to work ! you're telling the CPU that your code segment is the null descriptor -> next instruction (if the mov cs, ... does assemble, which would amaze me
) will try to access an invalid descriptor and issue a GPF. As you have no IDT at all, the GPF handler doesn't exists and the CPU reboots...
This is what could've happened if your jump reached your PMODECODE.
however, your bootcode is assembled with org 0 -> thus PMODECODE is an offset within [0..511], and your LINEAR_CODE_SELECTOR has a base address of 0, thus the physical address you jump to is somewhere in realmode Interrupt vector Table, not your own code! thus chances are that the behaviour is even more strange ...
try
Code: Select all
jmp LINEAR_CODE_SELECTOR:PMODECODE+0x7c00
Re:More Probs with PMode
Posted: Mon Sep 02, 2002 1:17 pm
by pskyboy
Tryed the Jmp LINEAR_CODE_SEL:PMODECODE + 0x7c00 with little luck still triple faults teh CPU, God PMode is a pain.
Peter
Re:More Probs with PMode
Posted: Mon Sep 02, 2002 2:18 pm
by Pype.Clicker
okay, so you assume to be called with CS = 0x7c0 and EIP = 0. You could also have been called with CS = 0000 and EIP = 0x7c00. Bios is unclear on this, so i suggest you start with "jmp far 0x7c00:BOOT" to enforce this to be true.
Code: Select all
GDTptr:
dw GDT_END - GDT - 1 ; GDT limit
dd GDT ; linear, physical address of GDT
remember GDTptr.base should be an ABSOLUTE address, so you absolutely need to write "dd GDT+0x7c00" in your GDTptr section.
Code: Select all
cli
mov ax,0x9000
mov ss,ax
mov sp,0xFFFF
as you're going to use some BIOS i/o that requests the use of an IRQ (hdd), i strongly recommand that you re-enable interrupts after setting the stack. You'll simply disable it again before entering pmode.
as i said in my previous post, PMODECODE must be added 0x7c00 in order to become an offset in LINEAR_CODE_SEL.
Code: Select all
[BITS 32]
PMODECODE:
mov ax,0x0
mov cs,ax
mov ds,ax
mov es,ax
mov fs,ax
mov ax,0x10
mov gs,ax
strange idea ...
try
Code: Select all
[BITS 32]
PMODECODE:
mov ax, LINEAR_DATA_SEL
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax
here: jmp here
instead
Re:More Probs with PMode
Posted: Mon Sep 02, 2002 2:23 pm
by Pype.Clicker
now, if - as crazybuddah wisely suggested - you turn into
and thus assuming that you'll be loaded with CS = 0 and IP = 7C00, you should
to force CS = 0 if you were actually loaded with CS = 7c0.
No GDTPTR conversion is required, and your JMP CODE_SELECTOR:PMODE_CODE should be valid.
however, you should then
so that you use the proper data segment
Re:More Probs with PMode
Posted: Wed Sep 04, 2002 1:29 pm
by pskyboy
Whay its seems to finally be working and gets into PMode without rebootingg. I ended up rewriting it and going through bit bit.
I have it in PMode without the FAR jump and it works is that alright.
Peter
Re:More Probs with PMode
Posted: Wed Sep 04, 2002 2:18 pm
by Pype.Clicker
it would be nice if you also post the *working* code after all these debugging sessions
Re:More Probs with PMode
Posted: Wed Sep 04, 2002 2:53 pm
by pskyboy
[attachment deleted by admin]
Re:More Probs with PMode
Posted: Thu Sep 05, 2002 2:17 am
by Pype.Clicker
there is a slight error in your code, imho:
you made the jmp 0x7c0:0 and org 0000, thus when you assemble offset 0, you're actually addressing absolute 0x00007c00.
Unfortunately, you patch your GDT register with +7c0 (which is the code segment), but remember segments are *16 in address formation.
so
Code: Select all
GDTptr:
dw GDT_END - GDT - 1 ; GDT limit
dd 0x07C0 + GDT ; linear, physical address of GDT
should be
Code: Select all
GDTptr:
dw GDT_END - GDT - 1 ; GDT limit
dd 0x07C00 + GDT ; linear, physical address of GDT
In the same kind of idea, as your GDT has CS.base == 0, and as your code assumes to be loaded from offset 0, your jump command should not be
Code: Select all
jmp LINEAR_CODE_SEL:PMODECODE + 0x7c0
but rather
Code: Select all
jmp LINEAR_CODE_SEL:PMODECODE + 0x7c00
Re:More Probs with PMode
Posted: Thu Sep 05, 2002 11:43 am
by pskyboy
[attachment deleted by admin]
Re:More Probs with PMode
Posted: Fri Sep 06, 2002 12:09 pm
by beyondsociety
I have a bootsector that works and its set up just like yours.
I found one obsevation that might give you a problem later on.
I suggest putting the reset disk and read function before you enable the a20 gate. It will save you some head ache. If you decide to add more stuff in your bootsector, you will have to adjust the read sectors function. If not, when you enable a20 it will get wacked and halt.
Also you wont have to enable the interrupts after enabling the a20 gate and then having to then clear it again for entering protected mode.
Hope this helps!