OSDev.org

Posted: **Sat Apr 21, 2007 7:25 pm**

I am having a problem getting the physical pointer for the LFB.

I am using the following code in 16bit realmode, but after I enable the a20:

Code: Select all

unsigned long getLFB(int mode)
{
	union REGS in,out;
	struct SREGS segs;
	char far *modeInfo = (char far *)&ModeInfoBlock;
	if (mode < 0x100) return 0; /* Ignore non-VBE modes */
	in.x.ax = 0x4F01;
	in.x.cx = mode;
	in.x.di = FP_OFF(modeInfo);
	segs.es = FP_SEG(modeInfo);
	int86x(0x10, &in, &out, &segs);
	if (out.x.ax != 0x4F) return -1;

	printf("Res X: %u\r\n" , ModeInfoBlock.XResolution);
	printf("Res Y: %u\r\n" , ModeInfoBlock.YResolution);
	printf("ModeInfoBlock.PhysBasePtr: %u\r\n" , ModeInfoBlock.PhysBasePtr);
	return ModeInfoBlock.PhysBasePtr;

}

The X and Y resolutions come back right... but the PhysBasePtr is printed as 0. The mode I am passing is 0x4101 so I am telling it to you LFB.

This is a head scratcher... Ive wasted a couple of hours tweaking and googling and coming up empty handed.

Thanks in advance,
Rich

Posted: **Sat Apr 21, 2007 8:25 pm**

Hi,

astrocrep wrote:The X and Y resolutions come back right... but the PhysBasePtr is printed as 0.

Did you check the ModeAttributes field of the ModeInfoBlock to see if the hardware actually supports the mode (or if it's telling you about a mode that the video card supports but the monitor can't handle, for e.g.), and if the mode supports the linear frame buffer at all?

astrocrep wrote:The mode I am passing is 0x4101 so I am telling it to you LFB.

I don't think VBE function 0x4F01 cares whether additional bits are set or not, and only cares about bits 0 to 8 (i.e. the mode number itself, but not the flags that tell it to use LFB, different refresh rates or to preserve display memory).

The general idea is that code gets a list of modes (function 0x4F00), then checks each mode in that list to see what it supports (function 0x4F01), then initialises a mode using options that VBE said were supported. Basically you should be using function 0x4F01 to find out if a mode supports LFB or not, rather than assuming all modes support LFB.

Cheers,

Brendan

Posted: **Sat Apr 21, 2007 8:54 pm**

Arg...

According to this one spec I saw if you

Code: Select all

(ModeInfoBlock.ModeAttributes & 0x80)

And it comes back true then you have LFB... apparently, I do not... however, I could have SWORN Qemu support Full VBE 2.0...

Thanks,

-Rich

Posted: **Sat Apr 21, 2007 9:12 pm**

Sorry for the double post but I wanted to see if I could get an answer to this.

I run the kernel on real hw and it tells me that there is LFB (*great*) but I still cannot print out the address...

I've tried

Code: Select all

printf("ModeInfoBlock.PhysBasePtr: %x\r\n" , &ModeInfoBlock.PhysBasePtr);
printf("ModeInfoBlock.PhysBasePtr: %u\r\n" , &ModeInfoBlock.PhysBasePtr);
printf("ModeInfoBlock.PhysBasePtr: %u\r\n" , ModeInfoBlock.PhysBasePtr);

and nothing seems right, or that I would expect. I want to make sure I have the right value to bring into pmode.

Thanks,
Rich

Posted: **Sat Apr 21, 2007 10:49 pm**

Hi,

astrocrep wrote:And it comes back true then you have LFB... apparently, I do not... however, I could have SWORN Qemu support Full VBE 2.0...

It's possible to fully comply with the VBE 2.0 specification without supporting optional features....

astrocrep wrote:and nothing seems right, or that I would expect. I want to make sure I have the right value to bring into pmode.

I'd assume this line is the right one:

Code: Select all

printf("ModeInfoBlock.PhysBasePtr: %u\r\n" , ModeInfoBlock.PhysBasePtr);

What does it display?

I'd assume a correct value would look something like 3758096384 (or 0xE0000000 in hex), or 3556769792 (or 0xD4000000 in hex). To be honest, all addresses look strange to me when they're displayed as decimal numbers....

Also, if there's another OS on the computer you might be able to use it to find the address to expect - for example (for Windows) have a look at the memory ranges in used by the video card via. the "Device Manager".

For Linux you could see what the MTRRs are programmed for (e.g. on my system "cat /proc/mtrr" shows a 4 MB area at 0xFA000000 that is using the "write-combining" memory type - almost guaranteed to be the video card's).

On the same system typing in "lspci -v" lists the following information for the video card:

Code: Select all

00:02.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] (rev 7a) (prog-if 00 [VGA])
        Subsystem: Intel Corporation Unknown device 4756
        Flags: bus master, stepping, medium devsel, latency 66, IRQ 19
        Memory at fa000000 (32-bit, prefetchable) [size=16M]
        I/O ports at 1000 [size=256]
        Memory at f9000000 (32-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at 30040000 [disabled] [size=128K]
        Capabilities: [5c] Power Management version 1

Here I would assume the prefetchable memory at 0xFA000000 is display memory (where the LFB would be), while the non-prefetchable area at 0xF9000000 is likely to contain memory mapped control registers used for hardware acceleration or something.

Cheers,

Brendan

OSDev.org

Vesa issue.

Vesa issue.

Re: Vesa issue.