Higher half kernel

kiwipresse · Post by **kiwipresse** » Sun Nov 04, 2007 9:03 am

Hi,

I'm currently trying to write a higher half kernel based on this http://www.osdev.org/osfaq2/index.php/HigherHalfWithGdt.

However, everytime when I want so change segment selectors a triple fault occurs.

Here is the code:

Code: Select all

        .globl  start, _start
start:
_start:
	lgdt gdtr
	movw $0x10, %ax
	movw %ax, %ds

        hlt
	
multiboot_entry:
        movl    $(stack + STACK_SIZE), %esp
	
        pushl   $0
        popf
	
        pushl   %ebx
        pushl   %eax
	
        call    EXT_C(cmain)
	
     
loop:   hlt
        jmp     loop

	.section .setup
gdtr:
	.word gdt_end - gdt - 1
	.long gdt

gdt:
	.long 0, 0
	.byte 0xFF, 0xFF, 0, 0, 0, 0x9A, 0xCF, 0x40
	.byte 0xFF, 0xFF, 0, 0, 0, 0x92, 0xCF, 0x40
gdt_end:

nm output:

Code: Select all

c010002c T _start
00100006 n gdt
0010001e n gdt_end
00100000 n gdtr
...
c010002c T start

qemu output:

qemu: fatal: triple fault
EAX=00000010 EBX=0002daa0 ECX=00000001 EDX=00000001
ESI=00054729 EDI=0005472a EBP=00067eac ESP=00067e8c
EIP=00100039 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300
CS =0008 00000000 ffffffff 00cf9a00
SS =0010 00000000 ffffffff 00cf9300
DS =0010 00000000 ffffffff 00cf9300
FS =0010 00000000 ffffffff 00cf9300
GS =0010 00000000 ffffffff 00cf9300
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT= 00000000 00000000
IDT= 00000000 000003ff
CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000
...

kiwipresse · Post by **kiwipresse** » Mon Nov 05, 2007 11:01 am

Any hints?

Combuster · Post by **Combuster** » Mon Nov 05, 2007 4:50 pm

Any hints?

1:

GDT= 00000000 00000000

2:
Try using Bochs - It is by far easier for debugging.

3:
You bumped the thread after only one day. That not the right way of How To Ask Questions. If you can't bring up the patience to wait for an answer, you are statistically likely to not be able to bring up that same patience to thoroughly debug your code.

[edit]I can't read[/edit]

Candy · Post by **Candy** » Tue Nov 06, 2007 12:09 am

Combuster wrote:3:
You bumped the thread after only 2 hours. That not the right way of How To Ask Questions. If you can't bring up the patience to wait for an answer, you are statistically likely to not be able to bring up that same patience to thoroughly debug your code.

Unless I'm missing something, that was 26 hours.

JackScott · Post by **JackScott** » Tue Nov 06, 2007 12:20 am

/me grabs out graphing calculator.
/me taps furiously for three minutes.

Yeah. It was 26 hours.

pcmattman · Post by **pcmattman** » Tue Nov 06, 2007 12:35 am

Nov 5 07 1 am was the first post, Nov 6 07 3 am was the second. 26 hours.

I'd say that's an alright time to wait to bump a thread.

os64dev · Post by **os64dev** » Tue Nov 06, 2007 2:35 am

ok, the bumping of the thread is ok but still he has no answer. so i will give it a try. In your code a don't see any paging setup. did you do that? Where is cmain implemented. In short: can you provide more sources and information?

kiwipresse · Post by **kiwipresse** » Tue Nov 06, 2007 5:36 am

@os64dev: yes, your are right. no paging setup yet. paging is handled within the kmain function, however, to call this procedure I first need to jump to the 'higherhalf' symbol or something similiar.

Perhaps I made any mistakes when transforming from Intel -> AT&T syntax?

os64dev · Post by **os64dev** » Tue Nov 06, 2007 8:07 am

keep in mind that a higher half kernel needs to have paging as in general there is no memory available at the higher location.

I do it slightly different my bootloader loads the kernel.elf in the lower memory, sets up the paging for the highhalf kernel. Next parse the kernel.elf and copies the segments and then executes the kernel.