can anyone this grub problem

[nil]

hello,

i am beginner and i am trying to write kernel and i wrote a kernel which print hell but when i add gdt for it restart my comp i used grub loader, but i cant solve this problem from couple of week please help me, i so frustate from this problem i link 3 files asm,c and ld and make elf file i send my code with this, if any info want i ready to send thnx,
nil
[[email protected]] : :-[

Code: Select all

bits 32

extern main
global start

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   
CHECKSUM         equ   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)

    align 4

        dd      MULTIBOOT_HEADER_MAGIC
        dd      MULTIBOOT_HEADER_FLAGS
        dd      CHECKSUM
                                                                               
      
start :
      lgdt [gdt_desc]
      jmp gdt_code:hi_jump
hi_jump : 
      mov eax, gdt_data 
      mov ds, eax
      mov es, eax
      mov fs, eax
      mov gs, eax
      mov ss, eax 
      
      call main 
      jmp $
gdt_desc :
        GDTSIZE dw      gdt_end - gdt - 1
        GDTBASE dd      gdt

gdt :      

gdt_null EQU   $ - gdt   
   dd   0
   dd   0
gdt_code EQU   $ - gdt
   dw   0FFFFh
   dw   0
   db   0
   db   10011010b
   db   11001111b
   db   0
gdt_data EQU   $ - gdt
   dw   0FFFFh
   dw   0
   db   0
   db   10010010b
   db   11001111b
   db   0

gdt_end:

[Pype.Clicker]

at what address did you asked GRUB to load it ? and at what address is it supposed to be run ?

You do not ignore the GDT.base value is quite sensitive to that kind of details (while your data are DS-relative, the base address of the new GDT is not)

[nil]

at what address did you asked GRUB to load it ? and at what address is it supposed to be run ?

You do not ignore the GDT.base value is quite sensitive to that kind of details (while your data are DS-relative, the base address of the new GDT is not)

hello Pype.Clicker ,

i am loading my kernel at 1mb
in my linker script,
physical mem 1mb
virtual mem is 3mb

when i use both physical and virtual same it work properly
but when i change it cant work
is this is gdt problem ?
please reply me urgently if possible
wait for reply
i u want i again send my code

thnx,
nil

[bkilgore]

I was just looking at your question and something caught my eye... you have as the beginning of your code:

Code: Select all

bits 32

extern main
global start

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  
CHECKSUM        equ  -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)

    align 4

        dd      MULTIBOOT_HEADER_MAGIC
        dd      MULTIBOOT_HEADER_FLAGS
        dd      CHECKSUM
                                                                              
      
start :

the main problem that i see is that you stick in the multiboot header before a jump to start, so when your kernel is loaded is tries executing the header values. try:

Code: Select all

bits 32

extern main
global start

jmp start       #<------ Add this

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  
CHECKSUM        equ  -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)

    align 4

        dd      MULTIBOOT_HEADER_MAGIC
        dd      MULTIBOOT_HEADER_FLAGS
        dd      CHECKSUM
                                                                              
      
start :

and see if that helps anything.

- Brandon

[Pype.Clicker]

iirc, GRUB is not able by itself to handle virtual address/physical address stuff. If you want to have the kernel at a physical address different from the virtual address (for instance to have upper-half kernel), you need to perform the 'remapping' yourself, either by switching to another GDT that has different based-segments, or by turning on paging.

[Solar]

The main problem that i see is that you stick in the multiboot header before a jump to start, so when your kernel is loaded is tries executing the header values.

Nope. This isn't your average flat binary where offset #0 gets executed after loading - he's using GRUB, which means that he's probably using a linker script to build an ELF executable from this assembly. As long as that linker script declares "ENTRY = start" so that GRUB can find the correct entry point, everything is fine. (Or maybe "start" is even the default ENTRY? I don't know, I played it save in *my* linker script. )

[Solar]

That being said, the multiboot specification says lots about physical addresses, but nothing about virtual ones, so Pype is probably right.