Return of the triplefaulting paging - this time with atttach

[Crazed123]

I AM zeroing out the page directory and table manually, and those are the only two data structures I know I am relying on the make paging work that could possibly need zeroing out (ie: they are the only fresh memory at that point).

Enabling paging as I have coded it triplefaults a real computer, but works perfectly on Bochs. I have been unable to figure out what's going on, as I am used to having some form of either debug output or a real debugger to work with.

This time the entire Pascal unit is attached, as a .txt file (Can we please be able to attach .pas files? Please?!) so that the spaces used for indentation will show up.

On that note, I apologize for my reaction to being told my code has no identation in the other thread. As it turns out the code tags weren't displaying the spaces I put in, they must be used to tab indentation. I failed to see this and took offense where I shouldn't have.

[Kim]

Can you please give the declare part of SegmentationVirtualBase + the value.

[Crazed123]

Sure.

Code: Select all

var
 SegmentationVirtualBase: longword; external name 'SEGMENTATION_VIRTUAL_BASE';

and the assembler code says:

Code: Select all

global SEGMENTATION_VIRTUAL_BASE

SEGMENTATION_VIRTUAL_BASE equ 0x40000000

For some reason the linker calls that value the symbols address (this is only supposed to be done for linker symbols, I thought) and so I use @SegmentationVirtualBase to equal 0x40000000.

[Kim]

Code: Select all

pascal:
var
SegmentationVirtualBase: longword; external name 'SEGMENTATION_VIRTUAL_BASE_PTR';

asm:
global SEGMENTATION_VIRTUAL_BASE_PTR

SEGMENTATION_VIRTUAL_BASE equ 0x40000000

section .data
SEGMENTATION_VIRTUAL_BASE_PTR:
   dd SEGMENTATION_VIRTUAL_BASE

[Crazed123]

OK, thanks, but how will that cure the triplefaulting?

[distantvoices]

after loading the pagedir, you should do a ret to some label to flush tlb and other caches. Further, you won't need a patched gdt after enabling paging. (I'd add a constant to the addresses ere activating paging)

That's how it looks like in asm:

write_cr3:
push ebp
mov ebp,esp
mov eax,[ebp+8]
mov cr3,eax
push .1
ret
.1
pop ebp
ret

Hope this helps. If not, it might be useful to get hold of the approx. pos. in code where it triple faults. Place some print statements and getch()'s to trace throu the code.

[Kim]

I never read in the intel doc's about doing a ret to flush the tlb i thoughed using mov cr3 would flush it...

And why do a ret to a label when your function will ret to the caller.

[distantvoices]

That ret is used for the tlb flush.

As for intel docs: Need to check that. I can't comment on it currently as I don't know it by heart. Just this: the code I've posted is from an actually very well working OS. *gg* Guess which one.

[Pype.Clicker]

That ret is used for the tlb flush.

That sounds weird to me too ...
- first you don't have to flush the TLB after a "mov CR3,eax", since reloading CR3 *do* flush the TLB (you can easily check out that we were suggested to use "mov eax,CR3 ; mov CR3,eax" to flush them before "INVLPG" instruction appeared on 486)
- i don't see how the cpu could guess that *this precise* 'RET' should flush TLBs and why other 'RETs' at the end of other functions don't do it. Imho, all it does is flushing the pipelines, forcing further instructions to be re-interpreted along new MMU rules if any effective address or fetch address has already been computed.

[distantvoices]

well, I've given it an empirical verification, and this gives the following results:

the ret-thing is needed after enabling paging and loading a page dir for the first time - as far as I can tell. have tested it here with vmware - and without the ret thing it simply refuses to work further.

all following cr3 loads need not be followed by a ret-thing. Tested too. OS boots up and runs pretty fine.

regrding the tlb stuff: Silly me, claiming something ere looking up stuff. Sorry for that.

[Colonel Kernel]

The "ret" thing probably serves the same purpose as the "jmp ecx" does here:

Code: Select all

_loader:
    mov ecx, (BootPageDirectory - KERNEL_VIRTUAL_BASE)
    mov cr3, ecx

    mov ecx, cr4
    or ecx, 0x00000010    ; Set PSE bit in CR4 to enable 4MB pages.
    mov cr4, ecx

    mov ecx, cr0
    or ecx, 0x80000000    ; Set PG bit in CR0 to enable paging.
    mov cr0, ecx

    ; Start fetching instructions in kernel space.
    lea ecx, [StartInHigherHalf]
    jmp ecx                     ; NOTE: Must be absolute jump!

StartInHigherHalf:
    ; Unmap the identity-mapped first 4MB of physical address
    ; space. It should not be needed anymore.
    mov dword [BootPageDirectory], 0
    invlpg [0]

I had to add that because otherwise EIP was still in the lower half when I unmapped it with invlpg.

[Crazed123]

OK, the assembler portion of my SetPaging() function is now:

Code: Select all

asm
 mov eax,reg
 mov cr0,eax
 push dword offset flush
 ret
flush:
 nop
end;

Hopefully that'll show up correctly, cause I can't type tabs inside this posting box to replace the spaces that might not get displayed.

Where reg is a variable containing the new value of cr0. I added ret'ing to a label here, and... it still triplefaults. Getting closer though, as traces show that the kernel gets up to setting the page directory in cr3 and THEN dies.

[Kim]

Works fine for me without using ret to force a eip update.
Tested on bochs and some old pentium mmx. Could it be a vmware bug, or I am just lucky that for some strange reason it works for me.

[Crazed123]

OK, then how are you enabling paging?

[Kim]

I attached my init section code. Its just some code linked at 1MB that enables paging and jumps to the kernel linked at 3GB.