Page 1 of 1
Another cr0 issue
Posted: Sat Mar 25, 2017 10:25 am
by Szustarol
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: Select all
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?
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 10:33 am
by iansjack
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?".
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 10:41 am
by Szustarol
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
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 10:46 am
by iansjack
Triple faults both on Qemu and Bochs.
Post the Bochs log for the crash. That way people have something to go on.
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 11:16 am
by DropDemBits
Read the Paging chapter of Volume 3 from the Intel manual.
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 11:40 am
by Szustarol
Code: Select all
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: Select all
(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
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 12:08 pm
by DropDemBits
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.
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 12:58 pm
by iansjack
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.
Re: Another cr0 issue
Posted: Sat Mar 25, 2017 1:19 pm
by DropDemBits
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.
Re: Another cr0 issue
Posted: Sun Mar 26, 2017 2:18 am
by iansjack
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.
Re: Another cr0 issue
Posted: Mon Mar 27, 2017 2:37 pm
by Szustarol
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: Select all
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?
Re: Another cr0 issue
Posted: Mon Mar 27, 2017 2:59 pm
by DropDemBits
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.