Kernel Developing using UEFI Booloader

[albus95]

So given the fact that now I can load a PE file in a uefi enviroment now the fun start!
So I'm loading the kernel PE file using UEFI.
But I arleady have the a couple of problem.
How the hell, when I start my kernel image and call BS->ExitBootServices, access the video memory for print/Draw the screen?
I imagine a need to write a vga driver, right? But how?
Any way reading the 2.5 specification, it said: "The EFI_GRAPHICS_OUTPUT_PROTOCOL also exports enough information about the current
mode for operating system startup software to access the linear frame buffer directly" but than it not write nothigh else about it. How you do that as it seem what I want?
Do I need to create a buffer for the Blt and write it on my kernel image?

Than I access the interrupt table?
Please help me!
Thanks, Alberto

[Brendan]

Hi,

So given the fact that now I can load a PE file in a uefi enviroment now the fun start!
So I'm loading the kernel PE file using UEFI.
But I arleady have the a couple of problem.
How the hell, when I start my kernel image and call BS->ExitBootServices, access the video memory for print/Draw the screen?
I imagine a need to write a vga driver, right? But how?
Any way reading the 2.5 specification, it said: "The EFI_GRAPHICS_OUTPUT_PROTOCOL also exports enough information about the current
mode for operating system startup software to access the linear frame buffer directly" but than it not write nothigh else about it. How you do that as it seem what I want?

For UEFI; typically an OS sets up a video mode during boot using GOP (for normal 80x86) or the older UGA (mostly only for Apple hardware) before it calls ExitBootServices; and then has a generic "raw frame buffer" video driver it uses afterwards (until/unless its replaced later during boot by a native video driver); where that generic "raw frame buffer" video driver uses the information provided by GOP/UGA (frame buffer address, pixel format, resolution, etc). You'll find this information in the "EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE" structure that is returned by GOP's "QueryMode()" function.

Of course GOP and UGA are boot services (not runtime services); which means that you can't use them after calling ExitBootServices and therefore can't use them to change video modes after boot. For this reason you'd want to choose a good video mode during boot (e.g. the monitor's native/preferred resolution if possible) because it's likely that the user will be stuck with it for everything (until/unless the OS starts a native video driver).

Note that for BIOS you'd probably want to do similar (e.g. use VBE during boot to setup a video mode, and use the information provided by VBE for that generic "raw frame buffer" video driver) so that the majority of the OS (including the generic "raw frame buffer" video driver) doesn't need to care whether the boot loader was using BIOS or UEFI or something else.

You should be able to find plenty of information about drawing things in a raw frame buffer (e.g. like this).

Do I need to create a buffer for the Blt and write it on my kernel image?

You don't need to, but most people do have a buffer in RAM for performance and/or other reasons. Don't forget that GOP's "Blt()" function is also a boot-time service and can't be used after calling ExitBootServices (which means that it might not be worth bothering with GOP's "Blt()" function before calling ExitBootServices because you're going to have code that works without it anyway).

Than I access the interrupt table?

After calling ExitBootServices (after you can be sure you're not going to mess up the firmware) you'd create your own interrupt table and load it (LIDT instruction). You'd never need to access UEFI's interrupt table.


Cheers,

Brendan

[albus95]

Hi,

So given the fact that now I can load a PE file in a uefi enviroment now the fun start!
So I'm loading the kernel PE file using UEFI.
But I arleady have the a couple of problem.
How the hell, when I start my kernel image and call BS->ExitBootServices, access the video memory for print/Draw the screen?
I imagine a need to write a vga driver, right? But how?
Any way reading the 2.5 specification, it said: "The EFI_GRAPHICS_OUTPUT_PROTOCOL also exports enough information about the current
mode for operating system startup software to access the linear frame buffer directly" but than it not write nothigh else about it. How you do that as it seem what I want?

For UEFI; typically an OS sets up a video mode during boot using GOP (for normal 80x86) or the older UGA (mostly only for Apple hardware) before it calls ExitBootServices; and then has a generic "raw frame buffer" video driver it uses afterwards (until/unless its replaced later during boot by a native video driver); where that generic "raw frame buffer" video driver uses the information provided by GOP/UGA (frame buffer address, pixel format, resolution, etc). You'll find this information in the "EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE" structure that is returned by GOP's "QueryMode()" function.

Of course GOP and UGA are boot services (not runtime services); which means that you can't use them after calling ExitBootServices and therefore can't use them to change video modes after boot. For this reason you'd want to choose a good video mode during boot (e.g. the monitor's native/preferred resolution if possible) because it's likely that the user will be stuck with it for everything (until/unless the OS starts a native video driver).

Note that for BIOS you'd probably want to do similar (e.g. use VBE during boot to setup a video mode, and use the information provided by VBE for that generic "raw frame buffer" video driver) so that the majority of the OS (including the generic "raw frame buffer" video driver) doesn't need to care whether the boot loader was using BIOS or UEFI or something else.

You should be able to find plenty of information about drawing things in a raw frame buffer (e.g. like this).

Do I need to create a buffer for the Blt and write it on my kernel image?

You don't need to, but most people do have a buffer in RAM for performance and/or other reasons. Don't forget that GOP's "Blt()" function is also a boot-time service and can't be used after calling ExitBootServices (which means that it might not be worth bothering with GOP's "Blt()" function before calling ExitBootServices because you're going to have code that works without it anyway).

Than I access the interrupt table?

After calling ExitBootServices (after you can be sure you're not going to mess up the firmware) you'd create your own interrupt table and load it (LIDT instruction). You'd never need to access UEFI's interrupt table.


Cheers,

Brendan

So at the end I not get what you have to do if you want to draw after call ExitBootServices, how you write, as you call it, a native driver?
Any way just to clarify what I need to set up, interrupt table, and what?
What is the first thinghs that the kernel should do?
Thanks, Alberto

[Brendan]

Hi,

So at the end I not get what you have to do if you want to draw after call ExitBootServices, how you write, as you call it, a native driver?

To draw, you write your pixels to the frame buffer.

Native video drivers are insanely complex (and the documentation you need is often impossible to obtain); and you'd need one for each different video card. It's the sort of thing that's best left until much much later (e.g. until after you've got things like web browsers and office apps finished), although I would recommend researching them (and things like 3D pipelines, shaders and GPGPU) before designing your OS's video device driver interface (just to make sure you can implement a native driver eventually without changing the video driver API and breaking everything).

Any way just to clarify what I need to set up, interrupt table, (I don't think GDT and IDT) as I'm arleady in real mode.

Are you in real mode, or are you using UEFI? Have you looked for any information about IDTs in the wiki and/or the CPU's manual?

What is the first thinghs that the kernel should do?

That depends on things like what sort of kernel/OS it is, what the design goals are, etc. The first thing my micro-kernels typically do is take control of physical memory management from previous boot code.


Cheers,

Brendan

[albus95]

I'm using uefi.
I have make a booloader that load a uefi image that than load a PE file.
So I suppose I'm in real mode after I call ExitBootServices, right?
I call ExitBootServices and than launch my PE image.

[albus95]

By the way I find this article
http://forum.osdev.org/viewtopic.php?f=1&t=26796 and I have followed the code for graphics and for get the memory map.
but when I call exit boot services it failed by saying invalid paramater.
What I'm doing wrong/what is the problem in the code.

[Brendan]

Hi,

So I suppose I'm in real mode after I call ExitBootServices, right?

Most likely, you're in long mode using 64-bit code (and not in real mode, and not using 16-bit code).

http://forum.osdev.org/viewtopic.php?f=1&t=26796 and I have followed the code for graphics and for get the memory map.
but when I call exit boot services it failed by saying invalid paramater.
What I'm doing wrong/what is the problem in the code.

Given that it's impossible for me to even see your code; I'd have to assume that ExitBootServices fails because there's an invalid parameter.


Cheers,

Brendan

[albus95]

Hi,

So I suppose I'm in real mode after I call ExitBootServices, right?

Most likely, you're in long mode using 64-bit code (and not in real mode, and not using 16-bit code).

http://forum.osdev.org/viewtopic.php?f=1&t=26796 and I have followed the code for graphics and for get the memory map.
but when I call exit boot services it failed by saying invalid paramater.
What I'm doing wrong/what is the problem in the code.

Given that it's impossible for me to even see your code; I'd have to assume that ExitBootServices fails because there's an invalid parameter.


Cheers,

Brendan

Ya I fixed the ExitBootService mode error.
Ok Thanks.

[albus95]

Just because I want not read all the 3000 pages of the standard, what I can do with the memory Map that I get from GetMemoryMap()?
What is mapped inside?
Any way as far as I read the documnentation, the os can still use the runtime services, do they reside inside the memory map?

[BASICFreak]

I just typed GetMemoryMap into this thing called Google... Here is the first result. Look at section 5.12...

[albus95]

I just typed GetMemoryMap into this thing called Google... Here is the first result. Look at section 5.12...

Ya but my comment is not waht GetMemoryMap does is if someone have arleady work with it and explain how the memory map is!
Any way now I can draw on the screen after ExitBootServices is called so I decide the first think I will implement is a font renderer.
I think is the best to start doing so later I can debug the kernel. What is the point of have the interrupt table set up if than I can't see/write when interupt is triggered!

[BASICFreak]

The memory map is described in http://wiki.phoenix.com/wiki/index.php/ ... DESCRIPTOR which is linked to 8 (counted) times on the page (section) I linked you to.

[albus95]

SO I made some, little, progress. I'm setting up a basic graphics driver for, at some point, drawing test.
As I set before I won't start thinking about exception handlers, GDT and IDT tables and all associate code because how the hell I can print error If I can't print text on the screen.
Anyway I have a problem, my code work on hyper-v but not on my real PC unfortuanally!
I'm following the code by this forum entry that I found: http://forum.osdev.org/viewtopic.php?f=1&t=26796
I have a function that put a pixel:

Code: Select all

VOID RdPutPixel(UINT32 X, UINT32 Y, UINT32 Color)
{
	UINT32 *At = (UINT32 *)GlobalLdrAddressPointer;

	//RdMoveDrawPointTo(&At, X, Y);
	At += (GlobalScreenInformation.HorizontalRes * Y + X);

	*At++ = Color;
}

I use the PutPixel function in a draw rect function:

Code: Select all

VOID RdDrawRect(UINT32 X, UINT32 Y, UINT32 Size, UINT32 Color)
{
	UINT32 *VidMem = (UINT32 *)GlobalLdrAddressPointer;
	UINT32 X0, Y0;

	//TODO: Validate the X,Y location.
	VidMem += (GlobalScreenInformation.HorizontalRes * Y + X);

	for (X0 = 0;  X0 < Size; X0++)
	{
		for (Y0 = 0; Y0 < Size; Y0++)
			*VidMem++ = Color;

		VidMem += (GlobalScreenInformation.HorizontalRes - Y0);
	}
}

Than I call it in a grid draw function, that seem easy but take me a day to make (Ah Ah).
I use a extern global variable to maintai the video information passed by my uefi boot loader and.

Code: Select all

VOID DrawTestGrid(UINT32 Size, UINT32 Spacing,
	             UINT32 CellPerRow, UINT32 CellPerCol,
	             UINT32 Offset, UINT32 Color)
{
	UINT32 X; 
	UINT32 Y;

	for (UINT32 Row = 0; Row < CellPerRow; Row++)
	{
		X = Y = Offset;
		Y += Row * Spacing;

		for (UINT32 Col = 0; Col < CellPerCol; Col++)
		{
			RdDrawRect(X + Col*Size, Y + Row*Size, Size, Color);
			X += Spacing;
		}
	}
}

If use the drawTriangle function of the article I'm able to draw also on the real hardware but for some reason my code not working.
What I'm doing wrong?

[albus95]

I fixed the problem.
I've a bug in my boot code that if more than one disk with
Some run image in it it rin the wrong disk.

[albus95]

Any one have some idea on how i can implement text rendering? Using my code posted above?