Page 1 of 1
can anyone this grub problem
Posted: Fri Feb 20, 2004 4:46 am
by 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:
Re:can anyone this grub problem
Posted: Fri Feb 20, 2004 10:39 am
by 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)
Re:can anyone this grub problem
Posted: Fri Mar 19, 2004 5:20 am
by nil
Pype.Clicker wrote:
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
Re:can anyone this grub problem
Posted: Sun Mar 21, 2004 12:06 am
by 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
Re:can anyone this grub problem
Posted: Mon Mar 22, 2004 6:05 am
by 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.
Re:can anyone this grub problem
Posted: Mon Mar 22, 2004 6:33 am
by Solar
bkilgore wrote:
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.
)
Re:can anyone this grub problem
Posted: Mon Mar 22, 2004 6:38 am
by Solar
That being said, the multiboot specification says lots about physical addresses, but nothing about virtual ones, so Pype is probably right.