OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:06 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Another cr0 issue
PostPosted: Sat Mar 25, 2017 10:25 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
So i know there is such a thread just a few post below, but my issue is a bit other.
Please take a look at my code:
Code:
org 0x7c00
use16
jmp 0x0000:stage2_start

    include 'INC/a20.inc'
    include 'INC/gdt.inc'
    include 'INC/vesa.inc'
    include 'INC/mmap.inc'

stage2_start:
    call a20_activation
    call zero_his
    call run_in_vesa
    call memory_map
    call create_gdt
    cli
    mov eax, cr0
    or eax, 1
    mov cr0, eax

    jmp dword 0x8:e_o_s2


zero_his:
    cld
    mov di, 0x500
    mov al, 0
    mov cx, 0x1000
    rep stosb
    ret
e_o_s2:
jmp stage3
    include 'INC/gdt64.inc'

stage3:
    use32
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov ss, ax
    mov eax, [0x500+8]
    mov ecx, 1280*720
    .l:
    mov dword [eax+4*ecx], 0x00ff00
    dec ecx
    cmp ecx, 0
    jg .l


    mov eax, PAGING_LAYER4
    mov cr3, eax

    mov eax, cr4
    or eax, 0x20
    mov cr4, eax

    mov ecx, 0xC0000080
    rdmsr
    or eax, 0x100
    wrmsr

    mov eax, cr0
    or eax, 0x80000000
    mov cr0, eax

    ;;<<------triple fault here
jmp $
    call gdt64_install
    jmp dword 0x8:longmode

align 4096
PAGING_LAYER4:
dq 0 or 10b or (PAGING_LAYER3)
times 511 dq 0
PAGING_LAYER3:
times 512 dq 0


longmode:
    use64
    jmp $
    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax
    jmp $



So the paging is at 0x9000 which is divisable by 4096 and is set up rather correctly. Whats the problem then?


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 10:33 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Presumably you are running in an emulator. Which one? What does its log tell you about the triple fault? As you know exactly where it is you have presumably done a register dump; this would be useful information.

And you say that the paging is set up correctly. What evidence do you have for that statement?

The simple answer is, use a debugger to single-step through the code in your emulator and see exactly what is happening. Also, it would be useful to implement very rudimentary exception handlers so that you can stop the code at the first exception and then inspect registers and memory contents.

In short - you really need to do a little debugging before posting code here and just saying "what's the problem?".


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 10:41 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
I of course did some debugging on my own.
I have just pasted jmp $ until it wasn't crashing and stepped as far as possible
in the code.
Triple faults both on Qemu and Bochs.

Evidence for correct paging setup is simple i think, I checked in bochs GUI debugger the address at 0x9000 and i can
see the address of paging layer 3 or'ed by 1 and 10b.
Also, when i do memory drop of the address i also see it is correct (filled with zeroes as it should be).
0x9000 is divisible by 4096 and i have checked other operations like ten times before i posted here. I also did
page 0x9000 in bochs dbg and it points to 0x9000
Also i have to mention that the code pasted before is loaded by stage1, which relocates itself to 0x7a00 and loads new code
at 0x7c00 so i can start again from that address with more memory.
Also when i do
lea eax, [PAGING_LAYER4] before i mov cr0, eax it somehow doesn't tripple fault but it should as well i guess. <-strange
I really did a lot of debugging, around 4 hours now I guess and i simply have no idea


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 10:46 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Quote:
Triple faults both on Qemu and Bochs.
Post the Bochs log for the crash. That way people have something to go on.


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 11:16 am 
Offline
User avatar

Joined: Thu Dec 29, 2016 2:06 am
Posts: 5
Read the Paging chapter of Volume 3 from the Intel manual.

_________________
Developing K4


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 11:40 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
Code:
00164491200i[BXVGA ] VBE set bpp (32)
00164491222i[BXVGA ] VBE set xres (1280)
00164491261i[BXVGA ] VBE set yres (720)
00164491299i[BXVGA ] VBE enabling x 1280, y 720, bpp 32, 3686400 bytes visible
00168181647i[CPU0  ] CPU is in compatibility mode (active)
00168181647i[CPU0  ] CS.mode = 32 bit
00168181647i[CPU0  ] SS.mode = 32 bit
00168181647i[CPU0  ] EFER   = 0x00000500
00168181647i[CPU0  ] | RAX=00000000e0000011  RBX=000000000000418f
00168181647i[CPU0  ] | RCX=00000000c0000080  RDX=0000000000000000
00168181647i[CPU0  ] | RSP=0000000000007a00  RBP=0000000000000000
00168181647i[CPU0  ] | RSI=00000000000e7e40  RDI=000000000000051b
00168181647i[CPU0  ] |  R8=0000000000000000   R9=0000000000000000
00168181647i[CPU0  ] | R10=0000000000000000  R11=0000000000000000
00168181647i[CPU0  ] | R12=0000000000000000  R13=0000000000000000
00168181647i[CPU0  ] | R14=0000000000000000  R15=0000000000000000
00168181647i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00168181647i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00168181647i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  FS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00168181647i[CPU0  ] |  GS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00168181647i[CPU0  ] |  MSR_FS_BASE:0000000000000000
00168181647i[CPU0  ] |  MSR_GS_BASE:0000000000000000
00168181647i[CPU0  ] | RIP=000000000000824c (000000000000824c)
00168181647i[CPU0  ] | CR0=0xe0000011 CR2=0x0000000000000080
00168181647i[CPU0  ] | CR3=0x00009000 CR4=0x00000020
00168181647p[CPU0  ] >>PANIC<< exception(): 3rd (14) exception with no resolution
00168181647i[CPU0  ] CPU is in compatibility mode (active)
00168181647i[CPU0  ] CS.mode = 32 bit
00168181647i[CPU0  ] SS.mode = 32 bit
00168181647i[CPU0  ] EFER   = 0x00000500
00168181647i[CPU0  ] | RAX=00000000e0000011  RBX=000000000000418f
00168181647i[CPU0  ] | RCX=00000000c0000080  RDX=0000000000000000
00168181647i[CPU0  ] | RSP=0000000000007a00  RBP=0000000000000000
00168181647i[CPU0  ] | RSI=00000000000e7e40  RDI=000000000000051b
00168181647i[CPU0  ] |  R8=0000000000000000   R9=0000000000000000
00168181647i[CPU0  ] | R10=0000000000000000  R11=0000000000000000
00168181647i[CPU0  ] | R12=0000000000000000  R13=0000000000000000
00168181647i[CPU0  ] | R14=0000000000000000  R15=0000000000000000
00168181647i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00168181647i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00168181647i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00168181647i[CPU0  ] |  FS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00168181647i[CPU0  ] |  GS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00168181647i[CPU0  ] |  MSR_FS_BASE:0000000000000000
00168181647i[CPU0  ] |  MSR_GS_BASE:0000000000000000
00168181647i[CPU0  ] | RIP=000000000000824c (000000000000824c)
00168181647i[CPU0  ] | CR0=0xe0000011 CR2=0x0000000000000080
00168181647i[CPU0  ] | CR3=0x00009000 CR4=0x00000020
00168181647d[PCI   ] Exit
00168181647i[CMOS  ] Last time is 1490463461 (Sat Mar 25 18:37:41 2017)
00168181647i[XGUI  ] Exit
00168181647i[SIM   ] quit_sim called with exit code 1

last lines from bochsrc

And i managed to get this out of the debugger
Code:
(0).[168181647] ??? (physical address not available)
(0).[168181648] ??? (physical address not available)
bx_dbg_read_linear: physical address not available for linear 0x000000000000824c
PML4: 0x000000000000a002    ps         a pcd pwt S W p
physical address not available for linear 0x0000000000009000
bx_dbg_read_linear: physical address not available for linear 0x000000000000824c


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 12:08 pm 
Offline
User avatar

Joined: Thu Dec 29, 2016 2:06 am
Posts: 5
The first entry in your PML4 (PAGING_LAYER4) doesn't have the present bit set, causing a pagefault.
Also, your PDPT (PAGING_LAYER3) is filled with 0, which will also cause a pagefault.
Both of these will result in a triplefault, as you don't have an IDT setup.
So you'll have to set the present bit in your first PML4E and properly initialize your PDPT.

_________________
Developing K4


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 12:58 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
You haven't set the write-protect bit in CR0. This leads to a GP fault when you enable paging, which leads to a triple fault as you have no handler for the exception.


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sat Mar 25, 2017 1:19 pm 
Offline
User avatar

Joined: Thu Dec 29, 2016 2:06 am
Posts: 5
iansjack wrote:
You haven't set the write-protect bit in CR0. This leads to a GP fault when you enable paging, which leads to a triple fault as you have no handler for the exception.


The WP bit in CR0 merely enforces write protect on pages with the R/W bit cleared. It will only generate a GP if the WP bit is set, the R/W bit cleared and whenever that page is being written to. However, this only applies in kernel mode, it will always cause a GP in usermode.

_________________
Developing K4


Last edited by DropDemBits on Sun Mar 26, 2017 11:21 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Sun Mar 26, 2017 2:18 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
I'm sure that you are correct, in which case the Wiki is incorrect.

Anyway, what the OP needs to do is to implement rudimentary exception handlers (all they have to do is halt the processor) so that they can see what the first exception is and can inspect any error code associated with it.


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Mon Mar 27, 2017 2:37 pm 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
I have tried again without exceptions using this guide:
http://wiki.osdev.org/Setting_Up_Paging_With_PAE
My code now looks like this:
Code:
if screen gets green - we are in real mode!
    ;;setting up paging
    ;;We have to set address of page directory to first page dir ptr tab, and or it with 1
    lea eax, [PageDir]
    or eax, 1b
    mov [PageDirPtrTab+4], eax
    ;;now we set address of page tab to page dir and or it by 3
    lea eax, [PageTab]
    or eax, 3
    mov [PageDir+4], eax
    ;;lets map 100MiB of memory
    mov ecx, 0;counter
    mov ebx, 0;address
    .map:
        lea eax, [PageTab + 4 + ecx*8]
        mov [eax], ebx
        or dword [eax], 3
        add ebx, 0x1000
        inc ecx
        cmp ecx, 25600
        jl .map
    ;; 100MiB should be mapped now
    ;; let's set PAE bit and load page directory pointer
    lea eax, [PageTab]
    mov eax, cr4
    bts eax, 5
    mov cr4, eax

    lea eax, [PageDirPtrTab+4]
    mov cr3, eax

    ;;now lets activate paging

    mov eax, cr0
    or eax, 0x80000000
    mov cr0, eax


    jmp $

    ;;<<------triple fault here
    call gdt64_install
    ;;TODO: paging
    ;;not working yet
    ;;-------------
    jmp dword 0x8:longmode

align 0x20
    PageDirPtrTab: dq 4 dup(0)
align 0x1000
    PageDir: dq 512 dup(0)
align 0x1000
    PageTab: dq 512 dup(0)


Sadly, still triple faults
Any help?


Top
 Profile  
 
 Post subject: Re: Another cr0 issue
PostPosted: Mon Mar 27, 2017 2:59 pm 
Offline
User avatar

Joined: Thu Dec 29, 2016 2:06 am
Posts: 5
You're on the right track, but I see a few problems.

1) I don't see a PML4, those are required in long mode paging.
2) Your PDPT isn't page aligned (0x1000).
3) CR3 points to the base address of your PML4.

Other than that, I don't see any other problems.

_________________
Developing K4


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 71 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group