OS using UEFI driver?

[PeterX]

Can a normal OS use (U)EFI drivers?
(I think an UEFI application can do so, but that is before booting has finished; so that doesn't matter for an OS.)

Greetings
Peter

[zaval]

Can a normal OS use (U)EFI drivers?
(I think an UEFI application can do so, but that is before booting has finished; so that doesn't matter for an OS.)

Greetings
Peter

No! read the spec. this question is plain nonsense.

[Octocontrabass]

Can a normal OS use (U)EFI drivers?

Maybe, if you can figure out how to extract them from whichever ROM they're in, but they won't work very well.

Which drivers are you interested in?

[PeterX]

Can a normal OS use (U)EFI drivers?

Maybe, if you can figure out how to extract them from whichever ROM they're in, but they won't work very well.

Which drivers are you interested in?

I was interested in very simple and generic drivers. Or USB, which is not so simple. I thought I could access a device with an UEFI application. But that's probably wrong. Better leave driver-writing and device-using for the kernel.

[Octocontrabass]

I was interested in very simple and generic drivers. Or USB, which is not so simple.

For common hardware like USB, you're better off writing your own driver. You're going to be using that driver a lot, after all.

I thought I could access a device with an UEFI application. But that's probably wrong. Better leave driver-writing and device-using for the kernel.

As long as the firmware has an appropriate driver, you can access a device with a UEFI application. But you can't run a UEFI application in an OS.

[zaval]

Can a normal OS use (U)EFI drivers?

Maybe, if you can figure out how to extract them from whichever ROM they're in, but they won't work very well.

Which drivers are you interested in?

extracting them from their storage is the least obstacle. UEFI Driver Model drivers do rely on the UEFI Boot Services - not available in the OS. so you need to write them - that is - recreate the core of UEFI - BS. the most enjoyable one would be ConnectController(), I believe. they run in polling mode only. they expect UEFI would call them when needed, based on the timer interrupt handling (the only one processed by the FW). there are also DXE drivers. needless to say, that their using in OS is even more impossible.

Maybe the author meant using source code of drivers as a reference? then maybe - edk2 is open sauce. but again - the OS environment and FW one are very different.

UEFI applications can "use" drivers by using protocol interfaces the latter produce. A UEFI app can even launch such a driver (for example you, like bzt, devised a terrific FS and want to share this marvel with the world instead of just using it in your loader logic, so you go "hey, do you want to extend UEFI on your machine with my brilliant FS? wink wink if there are people agreeing on that, your FS would be available for every UEFI loader. of course, not just launch, the installation of the driver is needed).

[eekee]

I intend to implement a Forth which uses UEFI for everything & never calls ExitBootServices, just to see if it's a reasonable idea.

[zaval]

I intend to implement a Forth which uses UEFI for everything & never calls ExitBootServices, just to see if it's a reasonable idea.

You can have that idea by writing (in C) a UEFI application, because UEFI is created to be used with C - it would be easiest - using C, I mean*. that app would try to do what an OS would do, never calling ExitBootServices, of course. GUI, storage, networking, anything UEFI can, you can try. I mean this way, having the idea would come faster. then, multiply this with the complexity of developing the Forth runtime environment atop of that - you need to provide some transition layer between your Forth OS and UEFI "library" that you ask to do stuff. I don't exactly know why one would want that, but it's personal. Don't only say that you are lazy to switch that virtual memory on! UEFI was made for loading OSes in a not sucky way. but only for that.

* - here, I have in my archive, this thing, that is one of the first screenshots of an UEFI OS Loader, yeah, it didn't do much at the time, but writing it was quick as well. GOP, load options, file access and stuff. of course, I have my own UEFI headers and used msvc, so I was free of all of those hassles of dealing with inappropriate tools, like gnu-efi, but the point was about another thing - try to do it in C and then decide if you are on the right path. Or maybe, if you are so inclined on using Forth and UEFI, then write a Forth "extension" to UEFI. the app, that would run FCode or whatever form it is in, a UEFI app interpreter for Forth. that would be kind of cool.

[eekee]

You can have that idea by writing (in C) a UEFI application, because UEFI is created to be used with C - it would be easiest - using C, I mean*.

I once read an article by a C++ library developer - a professional - who tested his C++ libraries in Forth because it was quicker and easier than writing & compiling C++ test code! But I'm mostly saying that to wind you up. Your boot code is cool enough. I love the trollface! I admit that my interests are odd; I'd like to develop a runtime library but not so much virtual memory. Interfacing Forth to C is less odd, it can be trivial to write foreign function interfaces in Forth.

What is the actual situation with virtual memory before ExitBootServices? I gather x64_64 requires it to be enabled, but is the memory organized linearly or identity mapped or what?

[bzt]

What is the actual situation with virtual memory before ExitBootServices? I gather x64_64 requires it to be enabled, but is the memory organized linearly or identity mapped or what?

Should be identity mapped according to the spec, and in practice extremely fragmented, and full of memleaks. Never trust EFIMemoryMap to be in order or to be contiguous at all. Always run a sanitizer (put it in order, merge adjacent blocks of the same type, exclude your own memory structs etc.)

Can a normal OS use (U)EFI drivers?

In theory yes, in practice no. The most common problem is, they allocate memory in a way that's not usable after the loader calls EFIExitBootServices(). I've tried to access GOP's SetMode function for example, it did not work on real hardware.

Cheers,
bzt

[zaval]

What is the actual situation with virtual memory before ExitBootServices? I gather x64_64 requires it to be enabled, but is the memory organized linearly or identity mapped or what?

it's an identity mapped linear space. on ARM, MMU is on (for making D-cache available), but still, numerically, addresses are 1:1 all the time and on all architectures.

In theory yes, in practice no. The most common problem is, they allocate memory in a way that's not usable after the loader calls EFIExitBootServices(). I've tried to access GOP's SetMode function for example, it did not work on real hardware.

in what "theory", bzt? it's not possible neither in theory nor in practice. or, another way, it's as possible as say using DOS drivers on iOS.

Just adding this for those, who seem to get confused about this over and over - neither GOP nor any protocol are available after the ExitBootServices() call. it's because it's "boot services" protocols - drivers, providing them not only use memory services, but also event services, protocol services. all this invalidates after leaving Boot Services. only Runtime Services are available at the OS runtime. this is said very clearly in the spec. the only thing, provided by GOP, that can be legitimately used after ExitBootServices() is the readonly MODE_INFO structure. again, this is said clearly in the specification. with it, one can know such things like framebuffer address and metrics (and also a very important thing as PixelsPerScanline), so it can implement its own BitBlt() or just show simple graphics, during the early OS boot phase, until the full display driver takes control over. setting the mode is not possible. using ConIn/Out/Error is not possible, using serial protocol is not possible. none protocol can be used after leaving Boot Services. neither on real hardware nor on unreal one!

Memory map is very clearly described in the GetMemoryMap() function description. it's not required to be ordered, moreover - contiguous, it's only required to be valid and not contain "holes" - that is not have descriptors for non populated ranges.

[eekee]

Thanks guys.

zaval, you've got me wondering how a memory space might not be linear, but I think that might be off topic. Oh... I suppose 8086-style segmentation could be described as non-linear. I tend to reduce it to linear addresses in my head, so it's all linear to me.

[bzt]

in what "theory", bzt? it's not possible neither in theory nor in practice.

Yes, it is possible. In theory an EFI driver could provide a RunTime service. Too bad that in practice 99.9% that your kernel ever wants to use from EFI will turn out to be implemented as a BootTime service.

With BIOS, your kernel could switch screen resolution, read disks, get USB keystrokes, send data over network etc. (okay, for non-real mode kernels you had to switch to real mode temporarily or implement vm86, but at least there WAS a conform way to access the firmware). You can't do any of that with EFI BootTime services, and almost nothing is implemented as a RunTime service. So it is utterly useless from a kernel's point of view, and it is extremely overcomplicated for a boot environment. But we have to cook with what we got

Cheers,
bzt