OSDev.org

[attachment deleted by admin]

i think the lgdt function do use a logical address and not a physical one, thus you should not have 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

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.

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

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?

[attachment deleted by admin]

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 :-@

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

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

A32 lgdt gdtptr + 0x7c00
movl %cr0, %eax
D32 orl $1, %eax and when the CPU decodes this, what it see (from ndisasm) is 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 ...

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

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!

[attachment deleted by admin]