Programming

You're talking about kernel modules, I think. These can be loaded whenever. Make both these things, your little loader thing and the thing which uses it, both modules, and have the main thing depend on the little thing. Whenever the main module is loaded it will try to load your loader module first. It will look for it in a specific place on the hard drive (/lib/modules/kernel-version/kernel/...).

You can also manually tell the kernel to load a module file whenever with modprobe modulename if the module's installed under /lib/..., or insmod filename.ko to point it to a specific file.

I haven't used module dependencies myself so can't be more specific, sorry. Create a dynamic library? As in convert from source code into a module? Creating a module takes gcc and dozens of megs of kernel source, all of which happens in userspace. No.

Again though -- what you do really depends on what the contents of this mysterious "block" are and where it will be and how you must get at it. Do you have any information whatsoever on what it actually is? If not, you really don't have the information you need to write a driver.

Humm, it is not as easy as refining calls.

If you and your friend are creating a UEFI emulator, I assume that you have studied all 2200 plus pages of the UEFI 2.3 specification and looked at the TianoCore reference implementation sources.

I should point out that the UDK2010 release contains a port of the emulator to OS X which was done by Andrew Fish of Apple. Andrew's port was then ported to Fedora 14 - see UEFI Emulator on Fedora 14.

I still cannot see why you are trying to load a UEFI driver binary into a Linux kernel. That makes absolutely no sense. Loading a UEFI driver into the UEFI emulator makes sense; existing UEFI emulators do that all the time. You can do this programmatically or from a UEFI shell. If you feel that you need extra functionally in the Linux kernel when you load a UEFI driver, you need to write a suitable Linux kernel driver to do the necessary and then write a suitable glue layer in the UEFI emulator.

Working on the internals of a UEFI emulator is not for the faint of heart! Good luck to you.

Well, I show you "Big picture" as you asked for.

Actors:
User
PC with preinstalled OS: RedHat from 2010year
Network Interface Card (let's call it "NIC") produced in 2011year

Usage model:
1. User plugs NIC to PCIe bus in PC
2. User turns on PC
3. User has got an internet connection

Do you got the idea? Just plug and play - no drivers, no additional installations, etc.
Of course - there are some limitations I tell about later.
If user wants to install regular drivers - he download it from vendor site and install.

- how is it possible?
There is known UEFI API for NIC before NIC is released to the market and even before silicon is created
- how many adapters it is dedicated for?
For now it is only one specific adapter model (it may changes in future).
- what functionality is to be implemented?
Only very basic options like: send packet, receive packet, obtain IP address from DHCP. It even does not has to run at full speed.
- how much resources are to do that?
It is about 8 months, few engineers
- has user to use UEFI machine?
No - he can use UEFI based machine or BIOS one

If you have another questions I try to answer but for sure I cannot tell all the details because of copyrights, and other law-connected things.

Now I have to create demos and propositions to solve some problems to set way of doing all the work (and discuss it with other people).


I show you some scenarios (at this moment I do not know exactly how UEFI Emulator presented by fpmurphy works):

1.
Actors:
RedHat with preinstalled MyLinuxDriver
NIC with UEFI Driver

On boot MyLinuxDriver copies UEFI Driver from NIC's flash to HDD/RAM
After that all calls to MyLinuxDriver are translated through UEFI Emulator to UEFI Driver.

2.
Actors:
RedHat with preinstalled MyLinuxDriver
NIC with UEFI Driver

On boot MyLinuxDriver copies UEFI Driver from NIC's flash to HDD/RAM and at the same time UEFI Emulator translates it to linux-understandable format.
All calls to MyLinuxDriver are redirected to UEFI TRANSLATED Driver.



What I need to know:
- how to load UEFI Driver from NIC's flash? (for demo purposes it could be 'how to load whatever from whenever', just to show that such operation is possible)
- where to load that driver? (RAM/HDD)
- when translate UEFI Driver to linux-understandable format (on boot, or on each call)

Thank you very much for your attention and useful information. I really apreciate your help guys!

PS.
I am not trying to do that - I am trying to find proper way to solve my problem described above.

Well that only took three entire pages of begging. THANK YOU.

I think you may be going about this the wrong way still though. The way to do this would be to add general-purpose UEFI support to Linux, not to hack one special thing that supports UEFI. And you'd probably want to use some sort of emulator, not something that converts UEFI code into whatever code your kernel uses.

But the biggest problem is I'm not sure UEFI even applies once an operating system's been loaded. Linux used to support BIOS-mode disk devices, for example, until it became clear that there were just too many corner cases where running in protected mode and controlling your own interrupts and DMA and all that jazz prevented BIOS calls from being able to work the way it was intended no matter how hard you tried to fool them. Sometimes. Very firmware-dependent. So they dropped that and added support for droves of different hard drive controllers instead, and that's how it's worked for a long time. Some coherent standards like AHCI are helping make drivers more generic again though.

You could make something like a DOS around raw UEFI devices -- a small self-contained OS which relies on system firmware to do most of the work. It could be surprisingly sophisticated with the system firmware features available now. Networking and graphics could be sufficient to run a reasonable impression of a web browser to download and save drivers with.

I added one point to my "Big Picture":
- has user to use UEFI machine?
No - he can use UEFI based machine or BIOS one

After UEFI loads regular OS it becames useless. I would like to use only UEFI Driver placed in Network Interface Card's flash - no general UEFI OS. My solution has to run on BIOS machine and works as well as on UEFI machine.

I think that "adding general-purpose UEFI support to Linux" is out of range. Such work needs much more resources.

Could you continue your tought? I have never heard about this.

And how do you propose to overcome this problem? Simply loading it in the kernel isn't enough to make it work. Once an OS loads, the environment's not right anymore. Which is unfortunate since I think that's the only way you'd get linux to do what you want -- use UEFI devices exclusively so you don't have to use your own drivers and in doing so alter the machine's environment. DOS is an extremely simple operating system. It doesn't have or need device drivers for basic functionality and it doesn't modify the system environment much at all. It relies on BIOS calls(i.e. firmware code) almost exclusively instead.

The original IBM PC BIOS calls were rather limited in function though, so raw DOS doesn't get you anything but disk+console+keyboard, and it's performance is poor compared to what real device drivers could do.

A DOS-like thing that fully utilized UEFI firmware capabilities could have much more features than DOS did. It wouldn't be anything like Linux but might be useful since you could still run many tools in it. You could check out LILO or GRUB to see how they use UEFI.

From the OS you cannot load the UEFI driver from the NIC flash because, according to you, there is no UEFI driver in place to access the NIC flash in the first place. Your NIC is unknown to UEFI if it cannot be enumerated. Chicken and egg situation. Now if you set up things so that your NIC is found when UEFI is probing devices, then you could write an UEFI app that could access the NIC flash, get driver image and store it in the ESP. It could then unload the existing driver and load the new driver in its place. All this needs to be done before the OS boots.

You cannot translate UEFI driver to "linux-understandable format." Period. UEFI using protocols and Linux uses APIs. They use different calling conventions also. A UEFI driver has no place in the Linux kernel.