Pentium 3 reboots

[shahzad]

my protected mode small kernel runs well on my PC which is Pentium 2 .But when i ran the same kernel on Petium 3 ,system rebooted.
please tell me whats causing the P3 system to reboot.

[FlashBurn]

At which position does the kernel reboot? Without that anyone can help you! But may be you have look at menuetos, because I think that they had the same problem and solved it!

[Pype.Clicker]

there are a lot of things that may change from one computer to another that may make hobby-os crash:

• whether the A20 gate is enabled by the BIOS or not
• whether you used delay tricks that will no longer work or not (i used to have some "jmp $+5" to insert I/O waits on my P120, which of course did no longer work on a 300MHz AMD system that does no longer cause a pipeline flush in case of predictable jump ...
• whether the newer BIOS performs less or more error recoveries on disk transfers (well, it should do none, actually)
• whether the new chipset emulates completely or only partially the PIC (people tends to forget a few bits in initialisation which is fine on Intel systems, but not on some AMD-based systems ...)

see why a widely tested bootloader like GRUB is your friend when starting OS Dev ?

[shahzad]

the following code works well on P2 but when ran on P3
,system reboots.

Code: Select all

 

1: [ORG 0x7c00]
2: [BITS 16]
3: start:
4:       xor ebx,ebx
5:   mov bx,ds                       
6:   shl ebx,4                       
7:   mov eax,ebx
8:       lea eax,[gdt + ebx]             
9:        mov [gdtr + 2],eax
10:   cli
11:
12:        lgdt [gdtr]
13:   mov eax,cr0
14:   or al,1
15:   mov cr0,eax
16:   jmp SYS_CODE_SEL:do_pm          
17: [BITS 32]
18: do_pm:
19:   mov ax,SYS_DATA_SEL
20:   mov ds,ax
21:   mov ss,ax
22:   mov ax,LINEAR_SEL
23:   mov es,ax
24:        mov byte [es:dword 0xB8000],'P'
hang:
    jmp hang   



gdtr:   dw gdt_end - gdt - 1   ; GDT limit
   dd gdt                  ; (GDT base gets set above)

gdt:   dw 0         
   dw 0         
   db 0         
   db 0         
   db 0         
   db 0         


LINEAR_SEL   equ   $-gdt
   dw 0xFFFF      
   dw 0         
   db 0
   db 0x92         
        db 0xCF                 
   db 0


SYS_CODE_SEL   equ   $-gdt
gdt2:   dw 0xFFFF               
   dw 0         
   db 0
   db 0x9A         
        db 0xCF                 
   db 0


SYS_DATA_SEL   equ   $-gdt
gdt3:   dw 0xFFFF               
   dw 0         
   db 0
   db 0x92         
        db 0xCF                 
   db 0



gdt_end:

pype actually we've wriiten an architecture of new filesystem after extensive study of almost 7 months.
thats why i'm also doing bootloader stuff too.
soon i'll post our file system on this forum for comments.
please let me know if grub cab be used for any new filesystem.


if i add following code on line 11 in above code.everything goes smoothly.

Code: Select all

xor ax,ax
mov ds,ax

please let me know whats causing the problem.

[Curufir]

The problem is that you've assumed that DS is set to 0 at startup.

There are very few values you can rely on at bootime. You know for instance that the address formed by CS:EIP equals 0x7c00, but the actual contents of EIP and CS are indeterminate since there are a few ways of making that address. Likewise the value of DS is indeterminate, and as such shouldn't be relied on until it has been set to something sensible.

Hence on one system DS might be set to 0, on the other it might be set to 0x07c0. Now in your code you use the value of DS to calculate the physical address of the GDT, but rely on the system setting DS equal to 0. If DS isn't 0 then the base address in GDTR is wrong and the GDT is not properly loaded. In this scenario the computer falls over on the first attempt to load in a selector (The far jump).

***

Note:
Since you use the assembler directive org 0x7c00 all labels will have 0x7c00 added to them at assembly time. This means that in any reference to one of those labels you are already assuming DS to be set to 0, therefore it makes perfect sense for you to explicitly set it to 0 in your code rather than relying on the system to do it for you.

Second Note ( ;D):
The fact that you can set ds at line 11 and have everything work smoothly is not surprising.

Code: Select all

4:      xor ebx,ebx
5:   mov bx,ds                      
6:   shl ebx,4                      
7:   mov eax,ebx
8:      lea eax,[gdt + ebx]            
9:        mov [gdtr + 2],eax
10:   cli
11:

That entire section of code does absolutely nothing if DS=0. More interestingly if DS=0x07c0 then thanks to the ORG instruction it will be working with values at 0x07c0:0x7c00+gdt/gdtr, which still means it will be doing nothing useful since that isn't the real location of those labels.