Page 1 of 1

Code triple faulting on loading of DS

Posted: Thu Jul 09, 2020 7:37 am
by nexos
Hello,
In my trampoline, it is loaded and gets to PMode, but but triple fault as soon as I load a data segment. Here is the code

Code: Select all

; ApStart.asm - contains AP startup code
; Distributed with NexOS, licensed under the AGPL v3.0
; See LICENSE

section .text

global realModeAP
global realModeAPend
global pmodeAP
global pmodeAPend

bits 16                 ; We are in real mode

realModeAP:
    mov ax, 0
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax
    cli
    mov si, 0x500
    lgdt [ds:si]
    mov eax, cr0
    or eax, 1
    mov cr0, eax
    jmp 0x08:0x10000
    
realModeAPend:
bits 32
pmodeAP:
    mov ax, 10h
    mov ds, ax       ; Triple faults here
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax
    hlt
pmodeAPend:
The core starting code on the BSP relocates the PMode code to 0x10000, the RMode code to 0x9000, the GDT to 0x600, and the GDT pointer to 0x500.
Thanks,
nexos

Re: Code triple faulting on loading of DS

Posted: Thu Jul 09, 2020 9:36 am
by Octocontrabass
nexos wrote:In my trampoline, it is loaded and gets to PMode, but but triple fault as soon as I load a data segment.
How did you figure out it's triple-faulting there and not somewhere else?
nexos wrote:

Code: Select all

    mov si, 0x500
    lgdt [ds:si]
You can just do "lgdt [0x500]".
nexos wrote:

Code: Select all

    jmp 0x08:0x10000
Doesn't NASM complain that the operand is too big? You need the "dword" keyword to specify offsets above 0xFFFF.
nexos wrote:The core starting code on the BSP relocates the PMode code to 0x10000, the RMode code to 0x9000, the GDT to 0x600, and the GDT pointer to 0x500.
Those are physical addresses, right?

You didn't include your data segment descriptor, so I can't tell you if there are any problems there.

Re: Code triple faulting on loading of DS

Posted: Thu Jul 09, 2020 12:53 pm
by nexos
I added the dword keyword to the far jump and it works fine now. I wonder why NASM didn't flag this. Thanks for your help!