Help! I can't write at 0xFE000000

[nifanfa]

Under the menu labeled 视图, can you select "compatmonitor0", enter the command "info tlb", and post the results?

[klange]

It does look like you are successfully mapping 0xFD000000, but I suspect that QEMU is ignoring either your writes or your reads to the region since you don't actually have a framebuffer set up. It's also possible something is going wrong with your pointer code - native C# stuff is a mysterious black box to me.

[nifanfa]

It does look like you are successfully mapping 0xFD000000, but I suspect that QEMU is ignoring either your writes or your reads to the region since you don't actually have a framebuffer set up. It's also possible something is going wrong with your pointer code - native C# stuff is a mysterious black box to me.

no it just my compiler converted the c# to nasm not c# native things

[nifanfa]

It does look like you are successfully mapping 0xFD000000, but I suspect that QEMU is ignoring either your writes or your reads to the region since you don't actually have a framebuffer set up. It's also possible something is going wrong with your pointer code - native C# stuff is a mysterious black box to me.

I also tried pmemsave to make a memory dump. The value is true zero.

[linuxyne]

Is the frame buffer mapped as cached, write-back? What if you try to write to it before/without enabling the paging?

Edit: The top-left corner of the VM display, before and after "set {char}0xfd000000=0xaa" from gdb:

Before:


After:

[nifanfa]

Is the frame buffer mapped as cached, write-back? What if you try to write to it before/without enabling the paging?

Edit: The top-left corner of the VM display, before and after "set {char}0xfd000000=0xaa" from gdb:

Before:


After:

if you disable paging you are no longer in long mode

[nifanfa]

It does look like you are successfully mapping 0xFD000000, but I suspect that QEMU is ignoring either your writes or your reads to the region since you don't actually have a framebuffer set up. It's also possible something is going wrong with your pointer code - native C# stuff is a mysterious black box to me.

when i enable qemu debug and write to 0xe0000000 it displays

Code: Select all

Invalid access at addr 0xE0000000, size 8, region '(null)', reason: rejected

[Octocontrabass]

when i enable qemu debug and write to 0xe0000000 it displays

Code: Select all

Invalid access at addr 0xE0000000, size 8, region '(null)', reason: rejected

This error means you have mapped that address correctly in your page tables, but QEMU is ignoring your reads and writes because there's nothing at that address.

It sounds like your code to map the page tables works fine. You don't see anything appear when you write to the linear frame buffer because there is no linear frame buffer in text mode.

[nifanfa]

when i enable qemu debug and write to 0xe0000000 it displays

Code: Select all

Invalid access at addr 0xE0000000, size 8, region '(null)', reason: rejected

This error means you have mapped that address correctly in your page tables, but QEMU is ignoring your reads and writes because there's nothing at that address.

It sounds like your code to map the page tables works fine. You don't see anything appear when you write to the linear frame buffer because there is no linear frame buffer in text mode.

[nifanfa]

when i enable qemu debug and write to 0xe0000000 it displays

Code: Select all

Invalid access at addr 0xE0000000, size 8, region '(null)', reason: rejected

This error means you have mapped that address correctly in your page tables, but QEMU is ignoring your reads and writes because there's nothing at that address.

It sounds like your code to map the page tables works fine. You don't see anything appear when you write to the linear frame buffer because there is no linear frame buffer in text mode.

0xC0000000 - 0xFFFFFFFF are inaccessible

[Octocontrabass]

What happens if you use the framebuffer address provided by your bootloader instead of 0xFD000000?

[nifanfa]

What happens if you use the framebuffer address provided by your bootloader instead of 0xFD000000?

The address which provided by boot loader is 0xFE000000 but it still not work

[Octocontrabass]

Are you halting the CPU after you write to the framebuffer? Some versions of QEMU will not display screen updates that happen shortly before the CPU halts.

What type of framebuffer did you request in your multiboot header?

[nifanfa]

Are you halting the CPU after you write to the framebuffer? Some versions of QEMU will not display screen updates that happen shortly before the CPU halts.

What type of framebuffer did you request in your multiboot header?

forget about the framebuffer. the real problem is that it can't access 0xc0000000-0xffffffff
i just tried to map the bar0 that provided by a pci device. it occured the same problem

Code: Select all

Invalid access at addr 0xFD000000, size 8, region '(null)', reason: rejected

[nifanfa]

Are you halting the CPU after you write to the framebuffer? Some versions of QEMU will not display screen updates that happen shortly before the CPU halts.

What type of framebuffer did you request in your multiboot header?

i can access 0xFD000000 before entering long mode