Not getting GRUB magic number

[lwinkenb]

I'm following the bare bones tutorial, and I've modified it a little bit to do a higher half kernel. The problem is that instead of getting 0x2BADB002 as the magic number, I get 0x2BAD0010. I'm using Bochs to run my kernel.

My loader file looks like:

Code: Select all

global loader           ; making entry point visible to linker
extern kmain            ; kmain is defined elsewhere

; setting up the Multiboot header - see GRUB docs for details
MODULEALIGN equ  1<<0                   ; align loaded modules on page boundaries
MEMINFO     equ  1<<1                   ; provide memory map
FLAGS       equ  MODULEALIGN | MEMINFO  ; this is the Multiboot 'flag' field
MAGIC       equ    0x1BADB002           ; 'magic number' lets bootloader find the header
CHECKSUM    equ -(MAGIC + FLAGS)        ; checksum required

section .text
align 4
MultiBootHeader:
    dd MAGIC
    dd FLAGS
    dd CHECKSUM

; reserve initial kernel stack space
STACKSIZE equ 0x4000                  ; that's 16k.

loader:
    ; load a temporary GDT
    lgdt [tempgdt]
    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:
    ; The CPU will now translate every address by adding
    ; the base 0x40000000

    mov esp, stack+STACKSIZE           ; set up the stack
    push eax                           ; pass Multiboot magic number
    push ebx                           ; pass Multiboot info structure

    call  kmain                       ; call kernel proper

    cli

hang:
    hlt                                ; halt machine should kernel return
    jmp   hang

[global gdt_flush] ; make gdt_flush accessible from C code
[extern gp]        ;

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

;
; Code to load the interrupt descriptor table
;
[global idt_load]
extern idtp
idt_load:
    lidt [idtp]
    ret

[section .setup]

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

gdt:
    dd 0, 0
    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
align 32
stack:
   resb STACKSIZE                     ; reserve 16k stack on a quadword boundary

Thanks guys.

[xenos]

The magic is passed in EAX. Now look at your code:

Code: Select all

    mov ax, 0x10

You don't save the contents of EAX before writing to it. Any questions left?

[lwinkenb]

Thanks XenOS. I'm very new to assembly; I actually thought that ax and eax were different registers

It's working now though. Thank you

[Love4Boobies]

You don't know the difference between EAX and AX and you're developing an OS...?

[lwinkenb]

Hey, everybody's got to start somewhere.

[Love4Boobies]

Agreed but working on an OS is not just 'somewhere', it's the most difficult thing you will probably do as a programmer. Perhaps you should learn assembly and learn more about the architecture you are developing for. Stuff like design and theory can come later, when you actually start learning OSDev'ing. That's just a friendly advice.

[Coty]

You don't know the difference between EAX and AX and you're developing an OS...?

actually I started trying to make an OS before I new anything but the slim basics of C++
EAX 32bit version of AX

[Solar]

EAX 32bit version of AX

True, but not the whole truth.

Please do take a step back, and don't write OS related code before you are confident in your main language of choice, and have read at least one Assembler tutorial (not a bootloader howto, but a "real" Assembler tutorial) and at least book 3 of the Intel Manuals in full.

Anything less will only lead to pain and desaster.

[Coty]

Well every thing I have read only describes EAX as a 32 bit register nothing more, same with all the others like ECX, EDX, ect.

[Solar]

Then you have had lousy sources for your Assembly knowledge, indeed.

Try The Art of Assembly, PC ASM or Assembly Language step by step.

[Coty]

Well, I am still reading my IBM PC assembly language and programing by Peter Able and I am about half way through, But I do allot more exercises, so I can grasp it more, I am not very far into it

Besides it I use the OS-dev wiki and mini DOS

[Solar]

Just for the records, and those poor sods who will google this thread in two years or so...

eax is 32 bits. The lower 16 bits of eax can be accessed as ax. The lower 8 bits of ax can be accessed as al, the higher 8 bits as ah.

All of this takes place in the same register, i.e. a write to al changes eax and vice versa.

[Brendan]

Hi,

eax is 32 bits. The lower 16 bits of eax can be accessed as ax. The lower 8 bits of ax can be accessed as al, the higher 8 bits as ah.

All of this takes place in the same register, i.e. a write to al changes eax and vice versa.

For the sake of completeness, RAX is the 64-bit version of the same register. Unlike writing to AX, AH or AL (which doesn't effect the highest 16-bits of EAX), writing to EAX does cause the highest 32-bits of RAX to be zeroed.

The same relationships apply to all general registers: RAX/EAX/AX/AH/AL, RBX/EBX/BX/BH/BL, RCX/ECX/CX/CH/CL, RDX/EDX/DX/DH/DL, RSI/ESI/SI/SIL, RDI/EDI/DI/DIL, RBP/EBP/BP/BPL, RSP/ESP/SP/SPL, then R8/R8D/R8W/R8B to R15/R15D/R15W/R15B. Note that for some registers you can't access bits 8 to 15 on it's own (there is no SIH, DIH, BPH, SPH or R8H to R15H), and only 64-bit code can use some of these (SIL, DIL, BPL, SPL, and all variations of R8 to R15).

In addition, RFLAGS is the 64-bit version of EFLAGS (which is the 32-bit version of FLAGS); and RIP is the 64-bit version of EIP (which is the 32-bit version of IP). Writing to EIP (e.g. with a 32-bit JMP) clears the highest 32 bits of RIP, and writing to IP (e.g. a 16-bit JMP) also clears the highest 16 bits of EIP (and the highest 48 bits of RIP). Writing to FLAGS doesn't effect the highest 16-bits of EFLAGS. The highest 32 bits of RFLAGS can't be modified and are always zero (as they're not used for anything).


Cheers,

Brendan