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.
UEFI and BIOS are completely different. And neither care, per se, or should care what OS is running atop them. Somehow, I suspect that you have not spend anytime working at the firmware level if you are asking these questions.
My knowledge has nothing to do in this case. I am just trying to tell you, that my solution must works under BIOS machines and UEFI machines.
Are on the market drivers to any hardware (e.g. sound cards, graphics cards, network cards, etc.) that uses hardware's flash memory?
If yes I may probably look at the code and find out some tricks.
UEFI doesn't work in machines that aren't UEFI, and I don't have that kind of magic to give you a solution to it.
You know by now that expecting UEFI to work in non-UEFI machines doesn't make sense, nor does expecting UEFI to do anything inside an operating system. You also have a few thousand pages of standards to pore through, plus several open-source UEFI using things to examine, and suggestions of alternative means of accomplishing your goal that make more sense than expecting UEFI to operate in kernel-mode. So, you're faced with the choice between rewriting Linux from the ground up or creating your own private operating system. Where you go from here is up to you.
Well, that is what I was thinking about - big misunderstanding. It is difficult to precise and discuss well such things only in few sentences on forum.
I have never expected UEFI to work on BIOS machine. From the begining (see post on 3rd site - 'big picture') I try to explain it.
In scenarios presented in 'big picture' I have never mentioned neither UEFI nor BIOS.
The trick is that I would like to take advantage of UEFI Driver placed in Newtork Interface Card's flash memory. Maybe I should not call it UEFI Driver (which it exactly is) for better understanding of whole project. I do not need to use UEFI by itself nor BIOS!
What I got is only:
Network Interface Card with driver in flash (it is actually UEFI driver, but forget it for a while - let's say it is just some DRIVER)
RedHat
MyLinuxDriver
What I want? I want to run internet connection on RedHat using MyLinuxDriver that uses DRIVER's functions. That is all. Please do not mix UEFI or BIOS to that. It is absolutely something different.
It has no matter what machine I use - projects assumes only mentioned three things (NIC, RedHat, MyLinuxDriver).
I hope that it became clear now.
PS.
Maybe that proposal of solution:
deceived us - but my response was 'no, because of such things:'
it should work only for RedHat - not for all OSes
it should work under BIOS machines and UEFI machines - not only UEFI machines
If I described it wrong - sorry. It is really not so easy to show somebody one's thinking way.
I understand. I also understand that you've been trying to avoid explaining your whole plan to us for fear that we'll realize what you're actually trying to do and explain that it's genuinely not feasible.
You don't seem willing to accept that the UEFI driver is useless without a UEFI system, and even when you do, the UEFI driver is still useless inside a running operating system! Three quarters of the machinery that makes it go, the UEFI system firmware, is either missing or inoperable. Should you hack up a convincing enough imitation of UEFI inside the kernel somehow you'll still have the problem that the environment the kernel operates in is just too different from the environment the UEFI driver expects to still work.
I'm retiring from this topic before I get any snarkier.