VESA: requesting framebuffer with GRUB

[sernico]

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?

Code: Select all

.set MAGIC, 0x1badb002
.set FLAGS, 7
.set CHECKSUM, -(MAGIC + FLAGS)
.set MODE_TYPE, 0
.set WIDTH, 1024  /* requested width */
.set HEIGHT, 768  /* requested height */
.set DEPTH, 32    /* requested bits per pixel BPP */

.set HEADER_ADDR, 0
.set LOAD_ADDR, 0
.set LOAD_END_ADDR, 0
.set BSS_END_ADDR, 0
.set ENTRY_ADDR, 0

and on the kernel:

Code: Select all

int kernel_main(struct multiboot *m){
// m-->framebuffer_address;
}

[Octocontrabass]

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

It's definitely not 0.

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.

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.

[sernico]

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

[sounds]

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

[sernico]

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

[iansjack]

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.

[sernico]

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.