OSDev.org

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

SECTIONS
{
. = 0x100000;

.setup :
{
*(.setup)
}

. += 0xC0000000;

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

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

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

.text : AT(0x10 00 00)

.text : AT(ADDR(.text) - 0xC0000000)

JAAman wrote: you have to load 2 entries in the page tables because the code is executing at the lower address until you jump to the higher address, therefore both must be paged in (at the same physical address) because the code is run at both addresses (after your jump, you can then remove the lower mapping)

[BITS 32]      ; 32 bit code
[global start] ; make 'start' function global
[extern kmain] ; our C kernel main

; 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)

; Multiboot header (needed to boot from GRUB)
ALIGN 4
multiboot_header:
        dd MULTIBOOT_HEADER_MAGIC
        dd MULTIBOOT_HEADER_FLAGS
        dd MULTIBOOT_CHECKSUM

; the kernel entry point
start:
        ; here's the trick: we load a GDT with a base address
        ; of 0x40000000 for the code (0x08) and data (0x10) segments
        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:
        ; from now the CPU will translate automatically every address
        ; by adding the base 0x40000000

        mov esp, sys_stack ; set up a new stack for our kernel

        call kmain ; jump to our C kernel ;)

        ; just a simple protection...
        jmp $

[global gdt_flush] ; make 'gdt_flush' accessible from C code
[extern gp]        ; tells the assembler to look at C code for 'gp'

; this function does the same thing of the 'start' one, this time with
; the real GDT
gdt_flush:
        lgdt [gp]
        mov ax, 0x10
        mov ds, ax
        mov es, ax
        mov fs, ax
        mov gs, ax
        mov ss, ax
        jmp 0x08:flush2

flush2:
        ret

[section .setup] ; tells the assembler to include this data in the '.setup' section

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

gdt:
        dd 0, 0                                                 ; null gate
        db 0xFF, 0xFF, 0, 0, 0, 10011010b, 11001111b, 0x40      ; code selector 0x08: base 0x40000000, limit 0xFFFFFFFF, type 0x9A, granularity 0xCF
        db 0xFF, 0xFF, 0, 0, 0, 10010010b, 11001111b, 0x40      ; data selector 0x10: base 0x40000000, limit 0xFFFFFFFF, type 0x92, granularity 0xCF

gdt_end:

[section .bss]

resb 0x1000
sys_stack:
        ; our kernel stack

void kmain()
{
        // FIRST enable paging and THEN load the real GDT!
        init_paging();
        gdt_install();

        // We clear the screen and print our welcome message
        cls();
        helloworld();

        // Hang up the computer
        for (;;);
}

YeXo wrote: 1. The linker script is not for the loader, but for the linker It tells the linker to link your kernel to be loaded at that address.

3. I thought it generates the logical address by just adding eip to cs. If you're still in 16 bit mode, it generates the logical address by doing cs<<4+ip

YeXo wrote: The first .=0x00100000 makes sure the linker links that code to run at address 1mb (or 0x00100000). The second .=+0xC0000000 makes the linker link the code after there to run at the address before + 3gb. So the meaning of the second .+=0xC0000000 is to let the kernel run at address 3gb+1mb+the length of startup code.

.text : AT(0x10 00 00)
 

.text : AT(ADDR(.text) - 0xC0000000)
 

bkilgore wrote: It's not really about telling the loader anything. It's the linker. It translates all of the addresses so that the code is suitable to run at the specified address. Basically, the linker script is saying that the code in the startup section is going to run at the 1MB mark, and that the rest of the kernel is going to run at an address above 0xc0000000. Thus the startup code can run before paging is enabled, and the rest of the code can run at a high virtual address.

[section .setup] ; tells the assembler to include this data in the '.setup' section

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

gdt:
dd 0, 0 ; null gate
db 0xFF, 0xFF, 0, 0, 0, 10011010b, 11001111b, 0x40 ; code selector 0x08: base 0x40000000, limit 0xFFFFFFFF, type 0x9A, granularity 0xCF
db 0xFF, 0xFF, 0, 0, 0, 10010010b, 11001111b, 0x40 ; data selector 0x10: base 0x40000000, limit 0xFFFFFFFF, type 0x92, granularity 0xCF

gdt_end:

[section .bss]

start:
        ; here's the trick: we load a GDT with a base address
        ; of 0x40000000 for the code (0x08) and data (0x10) segments
        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

Solar wrote: ??

Your first code block is in section .setup because you told the assembler so ([tt][section .setup][/tt]). Your second code block is in section .text because that's the default and there's nothing telling the assembler otherwise.

Have you understood that the linker script is not telling the loader anything? The assembler turns your ASM source into object code, in which symbols (like [tt]start[/tt] or [tt]gdt[/tt]) don't have an absolute address yet. The linker joins all the object files you feed to it, and gives the final, absolute addresses to the symbols. What these addresses are is determined by the linker script.

This still has nothing to do with the code that, upon booting, loads the binary into memory. In fact, if the linker didn't link the binary in the way the loader expects, execution will fail because a jump to symbol [tt]start[/tt] will not end up in the intended position.

One more hint: There is a social technique called "mirroring". If someone tells you something you didn't know, repeat what you understood using your own words. This tells the other person whether you understood correctly, and gives the chance to nail down misunderstandings.

 . += 0xC0000000;

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

asmboozer wrote:
I haven't read the docs on linker script, so I have tons of question of it.
where could I have the docs on the linker script?

• "when will the eip be 0x c0 10 00 00" - You are confused about the .text section starting at 0xc0100000 instead of 0xc0000000, right? (I am wondering about this, too.)
• "may i subsititute..." - I have no idea where you got the "AT(0x10 00 00)" from. You don't have to substitute that with ".text : AT(ADDR(.text) - 0xC0000000)" because the latter is already what is in the original code.
• "what's usage of .text here?" - are you asking about how to use .text (a question that doesn't make sense to me), or are you asking why .text is used that way (no idea myself, perhaps any of the linker script gurus knowing this)?
• "when CS:(E)IP adds the base address in the selector and the eip(offset)? when CS:(E)IP generate the logical address as
  CS<< 4 + (E)IP?" - Google for the DOS edition of "The Art of Assembly", which explains this rather nicely. In short, when the CPU starts (at boot) it is in 16bit "Real Mode", which uses CS<<4 + IP. When you switch to 32bit "Protected Mode", this becomes (selector base) + EIP.

<<<<<<< before paging enabled ,it jumps into higher half address >>>>>>>>

Solar wrote:
Binutils homepage at http://www.gnu.org/software/binutils/ links to the binutils documentation including the ld docs containing a section on linker scripts.

As I was still confused on what you are talking about, I jumped back to your first post. I think I figured out some of the misunderstandings here:

• "when will the eip be 0x c0 10 00 00" - You are confused about the .text section starting at 0xc0100000 instead of 0xc0000000, right? (I am wondering about this, too.)

[*] "may i subsititute..." - I have no idea where you got the "AT(0x10 00 00)" from. You don't have to substitute that with ".text : AT(ADDR(.text) - 0xC0000000)" because the latter is already what is in the original code.

[*] "what's usage of .text here?" - are you asking about how to use .text (a question that doesn't make sense to me), or are you asking why .text is used that way (no idea myself, perhaps any of the linker script gurus knowing this)?

[*] "when CS:(E)IP adds the base address in the selector and the eip(offset)? when CS:(E)IP generate the logical address as
CS<< 4 + (E)IP?" - Google for the DOS edition of "The Art of Assembly", which explains this rather nicely. In short, when the CPU starts (at boot) it is in 16bit "Real Mode", which uses CS<<4 + IP. When you switch to 32bit "Protected Mode", this becomes (selector base) + EIP.

[/list]

I hope this does nail it down a bit.

JAAman wrote: im surprised no one corrected this misleading statement:

<<<<<<< before paging enabled ,it jumps into higher half address >>>>>>>>

you are at higher half logical but still at lower half linear

you cannot switch halves before paging is enabled -- because paging is where the translation happens

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

higherhalf:
        ; from now the CPU will translate automatically every address
        ; by adding the base 0x40000000

        mov esp, sys_stack ; set up a new stack for our kernel

        call kmain ; jump to our C kernel ;)

void init_paging()
{
        // Pointers to the page directory and the page table
        void *kernelpagedirPtr = 0;
        void *lowpagetablePtr = 0;
        int k = 0;

        kernelpagedirPtr = (char *)kernelpagedir + 0x40000000;  // Translate the page directory from
                                                                // virtual address to physical address
        lowpagetablePtr = (char *)lowpagetable + 0x40000000;    // Same for the page table

        // Counts from 0 to 1023 to...
        for (k = 0; k < 1024; k++)
        {
                lowpagetable[k] = (k * 4096) | 0x3;     // ...map the first 4MB of memory into the page table...
                kernelpagedir[k] = 0;                   // ...and clear the page directory entries
        }

        // Fills the addresses 0...4MB and 3072MB...3076MB of the page directory
        // with the same page table

        kernelpagedir[0] = (unsigned long)lowpagetablePtr | 0x3;
        kernelpagedir[768] = (unsigned long)lowpagetablePtr | 0x3;

        // Copies the address of the page directory into the CR3 register and, finally, enables paging!

        asm volatile (  "mov %0, %%eax\n"
                        "mov %%eax, %%cr3\n"
                        "mov %%cr0, %%eax\n"
                        "orl $0x80000000, %%eax\n"
                        "mov %%eax, %%cr0\n" :: "m" (kernelpagedirPtr));
}

you use an altered GDT to make the addresses appear to be at high addresses (a high logical address, but still a low linear address) you cannot have a high linear address before paging is enabled

then you enable paging -- you are still running in low page, not high page (high logical, but low linear) -- so page in low memory must be mapped

then you change the GDT (reasign it to a 0 base) -- this essentially skips the segmentation, and makes logical==linear
which will require the pages to be valid at the top of linear address space -- only now is the trasition to upper half complete, and the lower half page mapping can be removed


if you are confused about the relationship between logical and linear, check Intel vol3 section 3.1