More Probs with PMode

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
pskyboy

More Probs with PMode

Post by pskyboy »

[attachment deleted by admin]
crazybuddha

Re:More Probs with PMode

Post 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.
Tom

Re:More Probs with PMode

Post by Tom »

doesn't A20 have to be done after pmode?
Schol-R-LEA

Re:More Probs with PMode

Post 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).
pskyboy

Re:More Probs with PMode

Post 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
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More Probs with PMode

Post by Pype.Clicker »

Code: Select all

mov ax, 0
mov cs, ax
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
pskyboy

Re:More Probs with PMode

Post by pskyboy »

Tryed the Jmp LINEAR_CODE_SEL:PMODECODE + 0x7c00 with little luck still triple faults teh CPU, God PMode is a pain.

Peter
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More Probs with PMode

Post by Pype.Clicker »

Code: Select all

[org 0x0000] 

jmp BOOT
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.

Code: Select all

   jmp LINEAR_CODE_SEL:PMODECODE
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
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More Probs with PMode

Post by Pype.Clicker »

now, if - as crazybuddah wisely suggested - you turn into

Code: Select all

[ORG 0x7c00] 
and thus assuming that you'll be loaded with CS = 0 and IP = 7C00, you should

Code: Select all

jmp 0x0000:BOOT
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

Code: Select all

BOOT:
     mov ax,0
     mov ds,ax
so that you use the proper data segment ;-)
pskyboy

Re:More Probs with PMode

Post 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
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More Probs with PMode

Post by Pype.Clicker »

it would be nice if you also post the *working* code after all these debugging sessions ;)
pskyboy

Re:More Probs with PMode

Post by pskyboy »

[attachment deleted by admin]
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More Probs with PMode

Post 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
pskyboy

Re:More Probs with PMode

Post by pskyboy »

[attachment deleted by admin]
beyondsociety

Re:More Probs with PMode

Post 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!
Post Reply