Page 1 of 1

Paging - Mapping the VESA LFB to 0xE0000000

Posted: Sun Jun 12, 2016 12:19 pm
by CrafterMan24
Hello forum :D

When I run my os in some computers (usually that have 1 GB of RAM), VESA LFB gets overwritten by heap and something else (of course resulted by disortion on video)

0xE0000000 is always free in my os, how can I map the LFB address to 0xE0000000? (Actually I can map, but I don't how can I calculate the frame address)

Paging code is a mix of JamesM's paging code and my paging code.

Thanks.

Re: Paging - Mapping the VESA LFB to 0xE0000000

Posted: Sun Jun 12, 2016 12:50 pm
by heat
Hello,

You just need to call a function like map_phys_to_virt

Code: Select all

map_phys_to_virt(VIRT_ADDRESS, framebuffer, PAGE_READ | PAGE_WRITE);

Re: Paging - Mapping the VESA LFB to 0xE0000000

Posted: Sun Jun 12, 2016 3:06 pm
by BrightLight
CrafterMan24 wrote:Actually I can map, but I don't how can I calculate the frame address).
If you're using GRUB to set the mode for you, the information is passed in the multiboot information structure.
If you're setting the mode manually, you can use VESA function 0x4F02, which returns a huge amount of information on the mode, including the framebuffer address.

Re: Paging - Mapping the VESA LFB to 0xE0000000

Posted: Sun Jun 12, 2016 3:34 pm
by CrafterMan24
omarrx024 wrote:
CrafterMan24 wrote:Actually I can map, but I don't how can I calculate the frame address).
If you're using GRUB to set the mode for you, the information is passed in the multiboot information structure.
If you're setting the mode manually, you can use VESA function 0x4F02, which returns a huge amount of information on the mode, including the framebuffer address.
I'm using GRUB to set mode, and get my framebuffer address from it. But sometimes heap and video memory overwrites themself, I'm trying to page framebuffer address to 0xE0000000 to fix that. (For example 0xA000000 -> E0000000, 0xA000001 -> E0000001, ...)

Re: Paging - Mapping the VESA LFB to 0xE0000000

Posted: Sun Jun 12, 2016 5:53 pm
by neon
You should have a way to manage the kernel address space. Regions in kernel space can then be reserved for use by the kernel heap allocator and other regions may be reserved for mapping I/O space or extended memory pools. If you don't already have a method, I'd advise against going any farther until you do. Some people use bit maps, some people use lists, we use a free list of PTEs, there are lots of options.

After you have a way to reserve regions of kernel space, have the kernel heap allocator reserve space for the initial system pool to allocate from, and there you go. You can map the VBE region to any kernel mode address (don't hard code it -- reserve the space and use the virtual address of the free area) and you will never run into problems with one overwriting the other.