pmode: jmp 8:offset triple faulting: need help

[dronkit]

[attachment deleted by admin]

[Pype.Clicker]

i think the lgdt function do use a logical address and not a physical one, thus you should not have

Code: Select all

  lgdt gdtptr+0x7c00

but rather
lgdt gdtptr (to be read according to DS value)

however, the +7c00 is fine and must be kept in GDTPTR: dd gdt+7c00 if you have an ORG 0 command ... (because it is expected to be a physical address)

just a trick: do a sgdt after your lgdt and display the result on screen, so that you'll have the confirmation you put the proper values in the GDT register before you start using it

[dronkit]

thanks for your reply.

I tried that, it didn't work :(

Ayway, I also did the sgdt thing, and it is ok. lgdt is
loaded with absolut address 7fb7 and gdt limit is
17 = (3 * 8) -1. sgdt corroborates this.

so everything seems fine there. Could the problem be anything else in the code?

I also tried commenting everything out until the lgdt and the jmp into pmode, didn't work either.

[Pype.Clicker]

maybe you should try to see what code is assembled for your ljmp instruction. this instruction will be 16-bits decoded (thus imho, the .code32 is not a good idea) as you haven't entered a 32-bits segment yet when you execute it ...

the bytes you should see are:

[0x66] [0x67] [0xea]
[offset to start32 from code32 base] = 1 dword
[code32 selector ] = 1 word

[dronkit]

ok, here are the opcodes:

D32 ljmp $0x08, $start32 + 0x7c00 // 66EA2D7E0800EBFE

D32 A32 ljmp $0x08, $start32 + 0x7c00 //6667EA2E7E0800EBFE

However, with .code32, these are the opcodes:
D32 ljmp $0x08, $start32 + 0x7c00 //66EA2F7E00000800

D32 A32 ljmp $0x08, $start32 + 0x7c00
// 6667EA307E00000800

also tried doing by hand:
   .byte 0x66
   .byte 0x67
   .byte 0xEA
   .long start32 + 0x7c00
   .word 0x08

which is decoded as: 6667EA307E00000800

neither of them work...

what do you think about my gdt?

[dronkit]

[attachment deleted by admin]

[Pype.Clicker]

except that this code is obviously assembled in pure .code32 mode with explicit 66/67 opcodes to enforce 32 bits operations to be properly decoded in 16bits interpretation ...

also note that, with a GDT.limit value of 17, your third descriptor is invalid:
00 = null
08 = code
10 = data
18 = oops .. out of the GDT range :-@

[dronkit]

that's ok, i'm not using that descriptor yet.

[Pype.Clicker]

won't fix the problem, but your code might be more clear if you use

Code: Select all

out 0x20,al

rather than

Code: Select all

mov dx,0x20
out dx,al

all the time

[Pype.Clicker]

Code: Select all

i think your "A32" stuff is wrong before LGDT command :

you wrote:

A32 lgdt gdtptr + 0x7c00
movl %cr0, %eax
D32 orl $1, %eax

Code: Select all

but what the assembler actually encode is
db 67 
lgdt [GDTPTR + 0x7c00]
mov eax,cr0
db 66 
or eax,1

and when the CPU decodes this, what it see (from ndisasm) is

Code: Select all

000001D5  670F0116          lgdt [esi]
000001D9  6E                outsb
000001DA  7F0F              jg 0x1eb
000001DC  20C0              and al,al
000001DE  666683C801        or eax,byte +0x1
000001E3  0F22C0            mov cr0,eax

The problem is that parts of your code comes from a crappy bootsector written in "pure" 32 bits assembler with A/D32 opcodes to enforce 32 bits processing ...
as YOU have set ".code16" at the start of your code (which is from far more clean and easier to understand) you *must* remove those crappy .byte stuffs.

I think that, by having a look at 1D5 .. 1E3 you now know why you have a reset ...

[Pype.Clicker]

a last suggestion:
try to use asm-comments combined with C comments so that gcc -E on your code will only leave the informations needed to follow what your code does (like "enabling A20 gate", etc.) but removes all the theory about it ;*)

Assembly literate programming ... funny have you heard about "Web" by D.E. Knuth earlier ? i think you could love that :-p

[dronkit]

man... i haven't been so grateful to anyone in my whole life

IT WORKED ;D

thanks a lot. great tips!

i did the "out 0x20,al" thing. I usually do things that way. Strange thing this time i coded it this way

Anyway, I took a look at the "WEB" thing too... hehe i'm doing this as a tutorial, so that's why it is *heavily* commented. My regular code is much more clean and
with just the needed commented However, it is interesting, but I prefer simple things like vi or anjuta, which are simple text 80x25 editors (i'll try the gcc -E thing)

and you were absolutely right about the opcodes. I *really* missed that ::)

I'm working on the ISR's now and will be posting the final code soon in this thread

thanks again, you're already in the "thans to" list

take care!

[dronkit]

[attachment deleted by admin]