OSDev.org

can my os be in real mode or i better do it in protected mode?

Of course you can do it in real mode (theoretically you can even do multitasking in real mode), however, don't except to be able to implement ANY protection in terms of memory, hardware access and similiar.

cause i made a boot and a kernel and the kernel enters protected mode and restarts :\

So you have a triple fault!
In most cases, check your GDT!

Hi,

pp wrote: cause i made a boot and a kernel and the kernel enters protected mode and restarts :\

I just spent 6 hours searching and rewriting stuff because my code was playing up on multi-cpu computers (but not Bochs). Turns out I was using "lock btc [foo],1" instead of "lock btr [foo],1", (thinking "btc" was "bit test and clear")

Triple faults are easy to fix as they triple fault Bochs too.


Cheers,

Brendan

this my kernel :

main:
cli ; Disable interrupts, we want to be alone

xor ax, ax
mov ds, ax ; Set DS-register to 0 - used by lgdt

lgdt [gdt_desc] ; Load the GDT descriptor

mov eax, cr0 ; Copy the contents of CR0 into EAX
or eax, 1 ; Set bit 0
mov cr0, eax ; Copy the contents of EAX into CR0

jmp 08h:clear_pipe ; Jump to code segment, offset clear_pipe


[BITS 32] ; We now need 32-bit instructions
clear_pipe:
mov ax, 10h ; Save data segment identifyer
mov ds, ax ; Move a valid data segment into the data segment register
mov ss, ax ; Move a valid data segment into the stack segment register
mov esp, 090000h ; Move the stack pointer to 090000h

mov byte [ds:0B8000h], 'P' ; Move the ASCII-code of 'P' into first video memory
mov byte [ds:0B8001h], 1Bh ; Assign a color code

hang:
jmp hang ; Loop, self-jump


gdt: ; Address for the GDT

gdt_null: ; Null Segment
dd 0
dd 0

gdt_code: ; Code segment, read/execute, nonconforming
dw 0FFFFh
dw 0
db 0
db 10011010b
db 11001111b
db 0

gdt_data: ; Data segment, read/write, expand down
dw 0FFFFh
dw 0
db 0
db 10010010b
db 11001111b
db 0

gdt_end: ; Used to calculate the size of the GDT



gdt_desc: ; The GDT descriptor
dw gdt_end - gdt - 1 ; Limit (size)
dd gdt ; Address of the GDT

Hi,

pp wrote: this my kernel :

There's nothing really wrong with any of that, but where is your ORG statement, and where is this code loaded in memory?

Your code had better be in the first 64 Kb of physical memory. Also your real mode segments should have base = 0 too. In this case you'd need to have "org NNNN" where NNN is above the BIOS stuff (above 0x600?) and below 0x10000.


Cheers,

Brendan

Brendan wrote: Hi,

pp wrote: cause i made a boot and a kernel and the kernel enters protected mode and restarts :\

I just spent 6 hours searching and rewriting stuff because my code was playing up on multi-cpu computers (but not Bochs). Turns out I was using "lock btc [foo],1" instead of "lock btr [foo],1", (thinking "btc" was "bit test and clear")

Triple faults are easy to fix as they triple fault Bochs too.


Cheers,

Brendan

What were btc and btr in the end Brendan?

srg

oops, no wonder it didn't work hehe

It's also just these sorts of simple mistakes that we all make, it's also the simple ones that are the hardest to debug IMHO.



srg

Hi,

srg wrote: It's also just these sorts of simple mistakes that we all make, it's also the simple ones that are the hardest to debug IMHO.

Some bugs are harder to notice than others. I find that if a bug causes Bochs/Qemu to have problems it's much easier to find. Also the more complex the OS gets the harder it is to find bugs.

My BTC/BTR problem was in the code that starts other CPUs in a multi-CPU system (used to make sure the BSP and AP CPUs do things in the correct order). On Bochs it worked perfectly, and on my dual PIII it also worked fine until I started messing with it. I got a dual PII (Compaq Proliant) on Friday which didn't work and early attempts to find/fix the problem seemed to make things worse.

In the end I rewrote a pile of code to handle the local APIC, plus the AP CPU startup code and rewrote the code for all the time delays a few times (BIOS timer tick -> keyboard clock/IO port 0x61 -> reprogramming the PIT).

Now it works properly, the time delays are much more accurate, there's better error reporting during the AP CPU startup code and the local APIC code handles some CPU bugs that the previous version didn't. I guess I'm lucky I bought the new machine, otherwise I wouldn't have noticed


Cheers,

Brendan