Can't use VESA linear framebuffer in long mode?

[scippie]

Hi,

I am trying to access the linear framebuffer in long mode. I have written my own boot code and the video mode (vesa 0118 - linear mode) is queried and initialised in real mode. I use Parallels on my mac to test the code.
After entering 32-bit protected mode, I can use the dword address in [vesa query buffer + 40] to write directly to video memory. This seems to work fine.
But after entering 64-bit long mode, if I try to access that same address (in lower dword of rdi, upper dword is zeroed first), no pixels show up on screen.

I had expected as such because I see the possible problems, but I don't know what they are and how to fix them. Meanwhile, I see several texts on the internet talking about using linear framebuffer mode with vesa. They are all aimed at 32-bit protected mode but lots of them seem to tell that long mode should work just fine, although they never explicitly do it.

Can anyone help me get it right?
Here's some assembler-code:

Code: Select all

org	   7C00h
USE16

boot_code:
	... move to 9000h ...
	... read sectors to 1600h ...
	... enable A20 ...
	... jump to 1600h ...
org	1600h
kernel_start:
	; get the info from VESA
	mov ax, 0x8000
	mov es, ax
	mov ax, 0x4F01
	mov cx, 0x0118 + 0100000000000000b
	xor di, di
	int 10h
	
	; initialise VESA 1024x768x24-bit
	mov ax, 0x4F02
	mov bx, 0x0118 + 0100000000000000b
	xor di, di
	int 10h

	lgdt [cs:GDTR]
	; Switch to protected mode
	mov eax, cr0
	or al, 1
	mov cr0, eax

	jmp CODE_SELECTOR:protectedmode_start

USE32

protectedmode_start:
	; Load 4 GB data descriptor to all data segment registers
	mov eax, DATA_SELECTOR
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
	
	; Store some pixel data in the VESA linear framebuffer, this works perfectly
	mov edi, [0x80000 + 40]	
	mov eax, 0xFFFF0000
	mov ecx, 65536 / 4
	rep stosd

	... do some switching to long mode stuff, enable paging (2MB pages), make the
	first 512MB addressable, ...
	jmp LONG_SELECTOR:longmode_start

USE64
longmode_start:
	... do some PIC, interrupts, whatever initialisations ...
	... I have already tested, I can use textmode fine, I can address my memory
	fine, everything seems to be initialized correctly ...
	xor rdi, rdi
	mov edi, [0x80000 + 40]
	
	mov eax, 0xFFFFFFFF
	mov rcx, 65536 / 4
	rep stosd

	; Nothing (changes) on screen...
	
  ...

Please don't answer with stuff like "use grub", it needs to be clean zero-dependency (well of course the hardware needs to be there).

Dirk.

[shikhin]

Have you identity mapped the VESA linear framebuffer - as far as I can see, you've only mapped the first 512MiB - what if the framebuffer is outside that region?

[gerryg400]

There's no difference in the 2 modes. The linear frame buffer remains in the same place. Are you sure that the physical memory that contains the frame buffer (often up near the 4GB mark) is mapped correctly ?

[bluemoon]

I have not go thru' your code but I'm sure you can at least access BGA's LFB in long mode, which address as reported from PCI.

note that LFB reported as physical address, you need to make sure you properly mapped it into your paging system.

[Combuster]

You've only mapped the first 512MiB - what if the framebuffer is outside that region?

With LFBs almost universally being located between 3G and 4G, I can pretty much assure you it's not there.

[scippie]

Have you identity mapped the VESA linear framebuffer - as far as I can see, you've only mapped the first 512MiB - what if the framebuffer is outside that region?

Of course, that must be it! And by being in a graphical video mode, I didn't see the word "exception" show up on the screen. How stupid of me. By seeing parallels take 100% CPU, which I explicitly generate on an exception, there is no doubt that this will be the problem.

I will adapt my code to make sure that the address is mapped correctly and I will report back.

Thanks.

[shikhin]

You've only mapped the first 512MiB - what if the framebuffer is outside that region?

With LFBs almost universally being located between 3G and 4G, I can pretty much assure you it's not there.

Which is what I meant - was just stating it like a question.

Regards,
Shikhin

[scippie]

You've only mapped the first 512MiB - what if the framebuffer is outside that region?

With LFBs almost universally being located between 3G and 4G, I can pretty much assure you it's not there.

Which is what I meant - was just stating it like a question.

Regards,
Shikhin

Yea, I know, thanks. KUDOS

[scippie]

Ok, that was it.
The first pile of pixels is now white.

I have now mapped the entire 4GB instead of just 512MB. I assume that since the VESA linear buffer address is 32-bits (and is made for 32-bit protected mode), that it can't go beyond 4GB.

It makes me wonder though, how one can access the memory at that physical address for real if it is available.

Thanks for the help guys.

[gerryg400]

It makes me wonder though, how one can access the memory at that physical address for real if it is available.

I don't understand what you mean.

[shikhin]

It makes me wonder though, how one can access the memory at that physical address for real if it is available.

You are accessing the physical memory for real - are you sure you understand paging well enough?

Regards,
Shikhin

[scippie]

It makes me wonder though, how one can access the memory at that physical address for real if it is available.

I don't understand what you mean.

Well, suppose that VESA puts the linear framebuffer at 0xC000000, which is at 3GiB. If your system has 4GiB installed, and you need to use the physical memory at 3GiB because for some reason all your processes have used up everything under 3GiB. Your OS should then "reserve" this part of the memory so that it does not get allocated, because otherwise, well... C64 anyone?

I mean: the linear framebuffer address is in my opinion (am I wrong?) some internal virtual mapper to the graphics adapter's physical video memory, right? So the real physical memory installed on the mother board at that address can 't be addressed that way...

(@Shikhin: yes I do understand paging well enough )

[bluemoon]

modern machine handle physical address with 48/52/64 bit, and the BIOS/EFI/chipset's job is to coordinate the devices (memory module, video LFB, etc) responds to different physical address.

In OS level, 32 bit PAE and 64-bit paging system take 48/52/64 bit physical address already.

[gerryg400]

It makes me wonder though, how one can access the memory at that physical address for real if it is available.

I don't understand what you mean.

Well, suppose that VESA puts the linear framebuffer at 0xC000000, which is at 3GiB. If your system has 4GiB installed, and you need to use the physical memory at 3GiB because for some reason all your processes have used up everything under 3GiB. Your OS should then "reserve" this part of the memory so that it does not get allocated, because otherwise, well... C64 anyone?

I mean: the linear framebuffer address is in my opinion (am I wrong?) some internal virtual mapper to the graphics adapter's physical video memory, right? So the real physical memory installed on the mother board at that address can 't be addressed that way...

(@Shikhin: yes I do understand paging well enough )

There won't be any memory at the 3GB mark if the LFB is there. The LFB is as real as real RAM. If you install 4GB of RAM most motherboards will present some of that RAM above the 4GB line and leave holes below 4GB. Those holes will contain things like LFB, APICS and such.

[scippie]

The LFB is as real as real RAM. If you install 4GB of RAM most motherboards will present some of that RAM above the 4GB line and leave holes below 4GB. Those holes will contain things like LFB, APICS and such.

Ok, that seems plausible. So you mean, the motherboard will give you an address like 0xC000000, but will actually internally be using a position above the memory you have installed?

So if you have a 32-bit system, install 4GiB on it, you will not be able to fully use it? (is that why windows only supports 3.? GiB on 32-bit?)