OSDev.org

i read : http://www.mega-tokyo.com/osfaq/HigherHalfKernel, then the linked thread.

So my question becomes:

If my kernel is loaded in its page tables at two points,
e.g. in lower half, 1-to-1 , so that after switching to paging, the next instruction in the IP reg is still valid, or am i wrong?

Also, now the kernel is in two places in the virtual memory. If i jump to some subroutine in my kernel, that subroutine is twice in the memory. To which one will the jump go?

The gdt only has base 0 entries.

Gr

i have another question.

Why would someone want to delay paging?

You can do the same things after paging is enabled or not?

MTermi wrote: Why would someone want to delay paging?
You can do the same things after paging is enabled or not?

Yes, unlike the switch to pmode, activating paging does not prevent you from doing things (calling BIOS, anyone?) you could do before. The reasons why you might want to "delay" paging setup could include the fact that you want to set up interrupts/exceptions first (debugging paging setup without a proper page fault exception is a nightmare, imho), or because you want the page tables to be allocated by your memory manager (though aftertoughts, i should let the linker script care about those alignment constraints), etc.

Im using the example higher-half kernel from the osFacwiki,
the compilation is no problem, but grub gives a kernel stack fault.
Before, i was not using paging, and another linker script, and everyhting was ok. Someone sees something stupid this code? I can't see anything anymore after so many hours
Any help welcome.

kernel_asm.asm:
--------------------------------------------------------------

USE32 ;32 bits

; Multiboot constants
MULTIBOOT_PAGE_ALIGN equ 1<<0
MULTIBOOT_MEMORY_INFO equ 1<<1
MULTIBOOT_HEADER_MAGIC equ 0x1BADB002
MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_MEMORY_INFO
MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)

STACKSIZE equ 0x4000

extern kernel_main
global   start, _start

segment .text
; Multiboot header (needed to boot from GRUB)
align 4 ;
multibootheader:
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_CHECKSUM

start:
_start:
lgdt [trickgdt]
mov ax, 0x10
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax

; jump to the higher half kernel
jmp 0x08:higherhalf

higherhalf:
mov esp, kernel_stack

;Reset EFLAGS
   ;push 0
   ;popf

   ;Push the pointer to the Multiboot information structure
   ;push ebx
   ;Push the magic value
   ;push eax

call kernel_main ; jump to our C kernel


segment .setup

trickgdt:
dw gdt_end - gdt - 1 ; size of the GDT
dd gdt ; linear address of GDT

gdt:
dd 0, 0
db 0xFF, 0xFF, 0, 0, 0, 10011010b, 11001111b, 0x40
db 0xFF, 0xFF, 0, 0, 0, 10010010b, 11001111b, 0x40
gdt_end:

segment .bss
resb STACKSIZE
kernel_stack:

-------------------------------------------------------------

And here is the linker script :

OUTPUT_FORMAT("elf32-i386")
ENTRY(_start)

SECTIONS
{
. = 0x00100000;

.setup ALIGN (0x1000) :
{
*(.setup)
}

. += 0xC0000000;

.text ALIGN (0x1000) : AT(ADDR(.text) - 0xC0000000)
{
*(.text)
}

.data ALIGN (0x1000) : AT(ADDR(.data) - 0xC0000000)
{
*(.data)
*(.rodata*)
}

.bss ALIGN (0x1000) : AT(ADDR(.bss) - 0xC0000000)
{
*(COMMON*)
*(.bss*)
}
}

what do you have in SS and in GDTR when the fault occurs ?

Hi Pype Clicker,

i just started writing a kernel, and am a bit low on a debugging environment. But here is what i did, i made in the setup section a temporary stack for the lower half, since that seems to be the problem, and i need a stack to call printing routines. I first init esp, then init video, and dump ss and the gdtr. With the ld script of the higherhalf faq, which i will need eventualy , vmware states
Error 13 : invalid or unsupported format
So i used a temp, but normal ld sript. This only helped when i renamed the .setup section to a .data section. I'm also using a cross compiler, just that u know.

The changed code is (besides adding a temp stack to .setup, and making it a .data section):

segment .text

; Multiboot header (needed to boot from GRUB)
align 4 ; or 0x1000?
multibootheader:
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_CHECKSUM

start:
_start:
mov esp, kernel_stacktrick
; here's the trick: we load a GDT with a base address
; of 0x40000000 for the code (0x08) and data (0x10) segments

call HAL_init_video

call dump_check
sgdt [gdt_dump]
call dump_gdt
;call regs_dump
mov ax, 0x10
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax

; jump to the higher half kernel
jmp 0x08:higherhalf


And the used ld script, since the other gives a code 13 error in vmware:

OUTPUT_FORMAT("elf32-i386")
ENTRY (_start)

SECTIONS
{
. = 0x00100000;

.text ALIGN (0x1000):
{
*(.text)
}

.rodata ALIGN (0x1000) :
{
*(.rodata)
}

.data ALIGN (0x1000) :
{
*(.data)
}

.bss ALIGN (0x1000):
{
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}

The outcome is :
SS : 0x10
GDT: base: 0x9010
GDT: limit: 0x27 (so it seems 5 entries are loaded)

But should these values not be some know values, because grub loads them. So the problem is, if i just load the trick gdt and jump to the higher half i get a kernel stack fault. How come?
In order to run , i have to use this simple ld script, use a data segment instead of a .setup segment, and have to use a temporary stack at the sart immideately. Isn't this strange? The higherhald faq code hsould just work right?

i had code that works perfectly everywhere else, including on dozen of test machines, and that makes some version of VMware hickup about a stack fault. It also involves GDT switching...

For your initial tests (bootloaders, exception handlers, ...), you're strongly advised to use bochs with the internal debugger (bxdebug.exe iirc) rather than any other emulator/hardware. That will save you weeks.

If you're accustomed with GDB, you may also want to try QEMU and its "remote debugging", but personnally, i couldn't make it work with Clicker.