OSDev.org

Hi everyone, I am a newbie with os dev programming. I was wondering a question about VESA mode. So let's say I have developed my own osdev experiment that has: gdt, and idt implemented, physical memory management, paging enabled, interrupts working and keyboard working. I'd like to move on, playing with a GRUB framebuffer address.

I read the wiki page about drawing in protected mode, and at the moment I """"""""implemented""""""""""" a really stupid way to get the VESA framebuffer address. In the file that manages the starting of the system (boot.S), I managed to request a framebuffer via multiboot structure (I do not know how, but GRUB understands if I ask mode 1024x768, 32bit depth).

I actually get a pointer (address: 0) and I can write on it and display some pixels. However as soon as I enable physical memory manager (or probably gdt), the framebuffer address is useless. I guess the space allocated for the screen by GRUB is totally overwritten by physical memory manager..

What would your procedure be to request a framebuffer from GRUB and then actually use it, considering I have enabled physical memory managment?
and on the kernel:

sernico wrote:I actually get a pointer (address: 0) and I can write on it and display some pixels.

It's definitely not 0.

sernico wrote:I guess the space allocated for the screen by GRUB is totally overwritten by physical memory manager..

It shouldn't be, since the framebuffer is not inside ordinary usable memory.

sernico wrote:What would your procedure be to request a framebuffer from GRUB and then actually use it, considering I have enabled physical memory managment?

GRUB gives you the physical address of the framebuffer. You need to choose a virtual address, update the page tables for that virtual address to point to the framebuffer's physical address, and then use the virtual address to access the framebuffer.

I did not enable the virtual memory yet, at the moment my OS is 1:1 with physical memory. Thanks for the feedback though!

Would you be willing to post some info about your page tables?

I'm stupid, there was a sort of deadlock on heap memory (memset on -14 GB takes time... ). Sorry closing the thread.

It’s really important that you should understand why no software should ever treat 0 as a valid value for a pointer. The fact that you think that multiboot gives you a 0 pointer to the frame buffer means that you are misinterpreting what it is telling you. That will certainly come back to bite you later.

Thanks iansjack. I investigated more and I also padded wrongly the structure of multiboot header. The value 0 was of a reserved field and thus my kernel had some problems. I totally agree on zero pointer, I just thought that framebuffer could be a sort of an exceptional case (but it's not!).

I'm going to implement more checks and asserts to ensure that my kernel can halt and report more clearly these problems.

By the way, OSDEV is amazing! I'm really thankful for this community.