Page 2 of 2
Re: Protected Mode problem
Posted: Sun Feb 26, 2012 1:41 am
by bluemoon
The first exception(06) is undefined opcode, it suggest that you might have jumped to bogus address.
Instead of trial and error, patching here and there to fix that issue,
bluemoon wrote:You should read more of different addressing methods and their transformation formula.
Re: Protected Mode problem
Posted: Sun Feb 26, 2012 4:09 am
by brain
Yes you should set up an idt anyway, or keep interrupts disabled or the first one to occur has no place to go except to fail city
keeping them disabled forever though would be really impractical for obvious reasons
Re: Protected Mode problem
Posted: Sun Feb 26, 2012 4:12 am
by Combuster
Disabling interrupts doesn't help for a crashing kernel, only for avoiding crashes by external peripherals.
Re: Protected Mode problem
Posted: Mon Feb 27, 2012 10:45 am
by sumanx
Invalid opcode? How?
Re: Protected Mode problem
Posted: Mon Feb 27, 2012 10:17 pm
by sumanx
But my address is right, right?
FirstBootloader.asm
Code: Select all
[BITS 16]
[ORG 0x7C00]
jmp start
start:
mov ax,0x1000
mov es,ax
mov bx,0x0000
xor ax,ax
mov ah,2
mov al,1
mov ch,0
mov cl,2
mov dh,0
mov dl,0
int 0x13
jmp 0x1000:0x0000
TIMES 510-($-$$) db 0
db 0x55
db 0xAA
Second Stage:
Code: Select all
[ORG 0]
jmp main
gdt_t:
;----------------
dd 0
dd 0
;----------------
dw 0xFFFF
dw 0
db 0
db 10011010b
db 11001111b
db 0
;----------------
dw 0xFFFF
dw 0
db 0
dw 10010010b
db 11001111b
db 0
end:
gdt:
cli
mov ax,cs
shl eax,4
add eax,gdt_t
mov [base],eax
mov ax,0
mov ds,ax
lgdt [addr]
ret
addr:
dw end - gdt_t -1
base dd 0
main:
call gdt
mov eax,cr0
or eax,1
mov cr0,eax
jmp 0x08:begin
bits 32
begin:
cli
hlt
Code descriptor is at 0x08, it should work??
Re: Protected Mode problem
Posted: Mon Feb 27, 2012 10:40 pm
by VolTeK
sumanx wrote:Code descriptor is at 0x08, it should work??
Your emulator will answer that question
Re: Protected Mode problem
Posted: Mon Feb 27, 2012 11:34 pm
by neon
it should work??
Welcome to kernel land: What you see isn't what the machine sees. If it crashes, your code has a bug. Stop looking for reasons why it "should" work and look for why it doesn't. This is through debugging. If you don't have a debugger, get one.
There are a few problems:
1. No stack;
2. Relying on CS on start instruction of VBR (your "jmp start"). It is preferred to use a far jump;
3. Segments used before initialized;
4. No check for disk read error;
5. Improper use of ORG in "Second stage" when CS=0x1000, DS=?
The general rule of thumb I personally go by is to either set segments=0 with a valid ORG offset, or set ORG to 0 with segments properly set up. ie; in your case your "Second stage" can use ORG 0 with CS=DS both set to 0x1000 (meaning the program is loaded at 0x1000:0, or 64k)