[SOLVED] Paging issue in Bochs

[nexos]

Hello,
I have been working on my paging code for my bootloader, and it works in QEMU but not in Bochs. Here is the relevant code:

Code: Select all

    # Set up paging structures
    mov $pageDir, %esi              # Get page directory address
    add $NBLOAD_BASE, %esi
    # Create PDE for mapping
    mov $pageTab, %ebx              # Get address of page table
    add $NBLOAD_BASE, %ebx
    or $3, %ebx                     # Set present and writable bits
    mov %ebx, (%esi)                # Put in page directory
    # Fill page table
    mov $pageTab, %edi              # Get page table address
    add $NBLOAD_BASE, %edi
    mov $1024, %ecx                 # 1024 PTEs in a page table
    mov $0, %edx                    # Start at address 0
.ptLoop:
    mov %edx, %ebx                  # Get address in EBX
    or $3, %ebx                     # Set present and writable bits
    mov %ebx, (%edi)                # Store in page table
    add $0x1000, %edx               # Move to next page
    add $4, %edi                    # Move to next PTE
    loop .ptLoop
    mov %esi, %cr3                  # Load page directory
    mov %cr0, %eax                  # Get CR0
    or $(1 << 31), %eax             # Set PG bit
    mov %eax, %cr0                  # Enable paging

The page directory and table are 4K of memory reserved and zeroed, plus they are 4K aligned. The problem in Bochs is shown in the output of info tab below:

Code: Select all

0x0000000000000000-0x00000000000fffff -> 0x000000000000-0x0000000fffff
0x0000000000100000-0x00000000001fffff -> 0x000000000000-0x0000000fffff
0x0000000000200000-0x00000000002fffff -> 0x000000200000-0x0000002fffff
0x0000000000300000-0x00000000003fffff -> 0x000000200000-0x0000002fffff

Obviously, 0x100000-0x1FFFFF should not be mapped to 0x0-0xFFFFF. What's weird is that the paging structures don't look corrupt. I used the xp command to look at the memory area containing the PTE for a page in that region, and here is what that looks like:

Code: Select all

<bochs:4> xp /1wx 0x12400
[bochs]:
0x0000000000012400 <bogus+       0>:	0x00100003

Looks valid to me. Is this a known Bochs bug?

In QEMU, all is fine. The output of info tlb shows everything mapped as it should be.

[Octocontrabass]

Did you enable A20?

[nexos]

Good suggestion, but yes, I did. I also test the A20 gate just before entering protected mode. Here is that code:

Code: Select all

    # Ensure A20 was enabled
    # NOTE: we use address wraparound here to check
    cli
    push %es
    mov $0xFFFF, %ax            # Load 0xFFFF as segment
    mov %ax, %es
    movw $0xAA55, %es:0x7E0E     # Load value to high memory
    pop %es
    cmpw $0xAA55, 0x7DFE
    je .a20failed               # If equal, A20 check failed

[nexos]

I found the problem: I had temporarily disabled my A20 code and forgot to put it back in. Now it's fixed.

[Octocontrabass]

Code: Select all

    cmpw $0xAA55, 0x7DFE

Won't this comparison always be equal?

[nexos]

I don't know. I think I ended up overwriting the sector at 0x7C00 at some point, but it might still be the same.