OSDev.org

Posted: **Tue Jan 15, 2008 3:09 pm**

hi, I am running into a problem with my bootloader ( i think ). The basic workings of this is that the bootloader loads a binary kernel to 0x100000 and jumps to it. Bochs makes it into 32-bit PMODE but then goes into a continuous reset, as it does on real PC's as well. I will post my bochs debugging and part of the boot code. Any help would be much appreciated, I just can't seem to figure this one out.

BOCHS Output:

Code: Select all

00001796618i[BIOS ] Booting from 0000:7c00
00002595114i[CPU0 ] LOCK prefix unallowed (op1=0xff, attr=0x0, mod=0xc0, nnn=7)
00002595114i[CPU0 ] CPU is in protected mode (active)
00002595114i[CPU0 ] CS.d_b = 32 bit
00002595114i[CPU0 ] SS.d_b = 32 bit
00002595114i[CPU0 ] EFER   = 0x00000000
00002595114i[CPU0 ] | RAX=0000000000000010  RBX=0000000000002210
00002595114i[CPU0 ] | RCX=0000000000000000  RDX=00000000000003f2
00002595114i[CPU0 ] | RSP=000000000000ffff  RBP=0000000000000000
00002595114i[CPU0 ] | RSI=00000000ffff7c5e  RDI=0000000000087c5e
00002595114i[CPU0 ] |  R8=0000000000000000   R9=0000000000000000
00002595114i[CPU0 ] | R10=0000000000000000  R11=0000000000000000
00002595114i[CPU0 ] | R12=0000000000000000  R13=0000000000000000
00002595114i[CPU0 ] | R14=0000000000000000  R15=0000000000000000
00002595114i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af PF cf
00002595114i[CPU0 ] | SEG selector     base    limit G D
00002595114i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00002595114i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  ES:0010( 0002| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00002595114i[CPU0 ] |  MSR_FS_BASE:0000000000000000
00002595114i[CPU0 ] |  MSR_GS_BASE:0000000000000000
00002595114i[CPU0 ] | RIP=0000000000100000 (0000000000100000)
00002595114i[CPU0 ] | CR0=0x00000011 CR1=0x0 CR2=0x0000000000000000
00002595114i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00002595114i[CPU0 ] >> lock (invalid)  : F0FFFF
00002595114e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting

start of PMODE in boot.asm:

Code: Select all

cli
mov eax,cr0
or al,1
mov cr0,eax

;load gdt
lgdt[GDTR]

jmp CODESEL:FLUSH        ; set cs to CODESEL

[bits 32]
FLUSH:

mov eax,DATASEL
mov ds,eax
mov es,eax
mov fs,eax
mov gs,eax
mov ss,eax
mov esp,0xffff

;jump to init.asm
jmp CODESEL:0x100000
hlt

and the above jumps to init.asm:

Code: Select all

[bits 32] 
[global start]   
[extern _main]

start:     
cli            ; disable interrupts
call _main     ; jump to main() in C code
hlt

I have already put an __asm__ ("hlt"); in the beginning of the C code that this goes to. but it still reboots which means it is not making it that far right?

It is near impossible to search around for similar lock prefix issues as they are so unique.

Thanks. If you NEED to see anything else, just ask and it will be posted.

Posted: **Tue Jan 15, 2008 3:22 pm**

It looks like the bootloader has made it into protected mode and jumped to the right address:

00002595114i[CPU0 ] | RIP=0000000000100000 (0000000000100000)

But Bochs is complaining that there's not a valid instruction there. Perhaps your bootloader didn't load the kernel correctly. Have you tried using the Bochs debugger to inspect the memory at that address?

Posted: **Tue Jan 15, 2008 3:27 pm**

nope, doing that now.
Thanks.

Posted: **Tue Jan 15, 2008 3:45 pm**

after doing both an "xp 0x100000" and "x 0x100000", they both returned <bogus* etc... answers. so it does seem as though the kernel is not being properly placed into memory.

Posted: **Tue Jan 15, 2008 4:21 pm**

ok, i think i might have figured some of this out.

post-compile I can successfully run the OS in bochs from the compiled image (kernel.img), but once i put it on a floppy it fails.

my batch file looks like this:

Code: Select all

@echo off
nasm -f bin -o boot.bin boot.asm
nasm init.asm -f aout
gcc -ffreestanding -c main.c -o main.o
gcc -c scrn.c -o scrn.o
gcc -c gdt.c -o gdt.o
gcc -c idt.c -o idt.o
gcc -c isrs.c -o isrs.o
gcc -c irq.c -o irq.o
gcc -c kb.c -o kb.o
gcc -c timer.c -o timer.o
gcc -c cpu.c -o cpu.o
gcc -c pci.c -o pci.o

ld -T link.ld -o kernel.bin init.o main.o scrn.o gdt.o idt.o isrs.o irq.o kb.o timer.o cpu.o pci.o

copy /b boot.bin+kernel.bin kernel.img

the result of this is a 18k kernl.img file that can be run under bochs just fine and without error. but if i put it on a floppy with either partcopy or rawwrite it fails.

why would this happen? any ideas?

Posted: **Tue Jan 15, 2008 11:16 pm**

Because when the BIOS loads your bootsector, your bootsector uses a bad INT call to load the rest of your kernel? Like maybe it tries to load all 18K in one gulp?

Posted: **Wed Jan 16, 2008 3:06 am**

actually that was pretty close lol.
i finally figured out the stupid problem.

After I had origionally developed that bootloader, my os was half the size it is now. I needed to load another sector haha.

*kicks self*

Thanks for the help all.

Posted: **Wed Jan 16, 2008 3:40 pm**

After I had origionally developed that bootloader, my os was half the size it is now. I needed to load another sector haha.

Hm... Why not use a filesystem of sorts that will allow you to know the amount of sectors to load automatically? This way, you dont need to determin the amount of sectors it takes up, your code will always load the correct amount of sectors.

Just an idea.

Posted: **Tue Feb 05, 2008 2:13 pm**

Hi, I seem to have the same problem. But it oly happens when I run boch over a 64 bit machine! Any suggestions?

Posted: **Tue Feb 05, 2008 3:49 pm**

I ended up solving this quite a while ago.
It was the simple fact that I loaded the sectors in the wrong place, thus jumping to some garbage memory location. I decided to put "flags" in the booloader to make sure that my new location for sector 1 started with a certain value (determined by a hex editor).

OSDev.org

Vague boot error.

Vague boot error.

Re: Vague boot error.

64 bit