Page fault on framebuffer access

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
torii
Posts: 14
Joined: Sun Feb 02, 2025 5:59 pm
GitHub: https://github.com/Toriiiiiiiiii
Contact:

Page fault on framebuffer access

Post by torii »

Hi!
I am currently trying to transition to a graphical terminal using flanterm and framebuffer, however I am currently getting a page fault when accessing the framebuffer.

I am using the address provided to me by the multiboot 2 information tag, so I am unsure why this is happening. Have I missed a step in getting this to work? Based on the page fault, I assume I need to first allocate some pages for the pagebuffer and then load it ther, but I am unsure how I would acheive this.

Any help or pointers in the right direction would be greatly appreciated :D
https://github.com/Toriiiiiiiiii/Solkern
fb pagefault.png
Writing bad code since 2019
Image Image
User avatar
iansjack
Member
Member
Posts: 4812
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Page fault on framebuffer access

Post by iansjack »

You don’t need to allocate any pages for the frame buffer, you just need to map its address in your page table(s). You can either map the same virtual address as the physical one or choose a new virtual address.

You need to bear in mind that, once you enable paging, almost all addresses you access have to be mapped in your page tables. There are a few exceptions - for example, the addresses used in the tables themselves are physical addresses. And certain peripherals, such as NICs need physical addresses.
Octocontrabass
Member
Member
Posts: 5873
Joined: Mon Mar 25, 2013 7:01 pm

Re: Page fault on framebuffer access

Post by Octocontrabass »

iansjack wrote: Mon Jun 30, 2025 5:21 amcertain peripherals, such as NICs
All peripherals that perform DMA, which is most of them once you've got "proper" drivers.

...Although it isn't always that simple. Some ARM platforms have more than one physical address space, so the "physical" address you use for DMA might be different from the "physical" address you use for your page table. There's also IOMMUs, which basically give you page tables for DMA, meaning you'd program your peripherals with virtual addresses instead of physical addresses.

Fortunately you can ignore all of this on x86 PCs.
User avatar
zaval
Member
Member
Posts: 675
Joined: Fri Feb 17, 2017 4:01 pm
Location: Ukraine, Bachmut
Contact:

Re: Page fault on framebuffer access

Post by zaval »

For arm, EL3 always has its own system address space, not sometimes. For EL2 and EL1 it would be the same only if stage 2 MMU is disabled. If it's enabled, then EL1 (OS) has no access to system address space at all. It accesses a so called "intermediate physical address space", that yet needs to be translated into EL2's system address space (by the mentioned stage 2 translation). This all hypervisor stuff is such a mess. Why had arm introduce this on a freaking mobile targetting platform?!! virtualization? Seriously, arm?
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).
User avatar
iansjack
Member
Member
Posts: 4812
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Page fault on framebuffer access

Post by iansjack »

We are perhaps drifting a little far from a simple question about x86_64 based computers.
Post Reply