UEFI Drivers - lersek/edk2 GitHub Wiki
Frequently asked questions about UEFI drivers
A) Dispatching order – UEFI Driver does not have a Dependency expression this is not an EFI concept. Dependency expression is a concept from the PI spec. There are now a lot of UEFI Drivers in flash then there is an implied dependency that the DXE dispatcher must have all the Architectural protocols installed and all the boot / RT services installed before the UEFI drivers can run their init. This makes it to the level of being UEFI compliant. Therefore, it is implied that the UEFI Drivers will get deferred to last There is a difference in building the UEFI Drivers into the flash part – is that it is possible for the UEFI driver to pick libraries that are not part of the UEFI spec. For example the report status code is gives the capability to redirect messages to the serial port. This is actually a PI not a UEFI concept. Any PI spec dependencies that a UEFI driver depends on would be Anded in. If the UEFI Driver only depends on the APs then the build process will optimize out the AP dependencies to save flash.
B) DOs and DON’Ts : it is important that for UEFI Drivers that only the UEFI Protocols defined in the UEFI Spec. Otherwise you need to convert it to a DXE driver by changing the type in the .inf file to Module type=DXE_DRIVER.
UEFI Drivers are dispatched once the full complement of UEFI Boot Services and UEFI Runtime Services are available. This occurs when all the DXE Architectural Protocols described in the PI 1.2 DXE CIS are produced.
The reason is that in the UEFI Driver’s INF file it should not have a “[DEPEX]” section. A UEFI Driver does not have a Dependency expression this is not a EFI concept. Dependency expression is a concept from the PI spec. Since now there are a lot of UEFI Drivers in flash then there is an implied dependency that the DXE dispatcher must have all the Architectural protocols installed and all the boot / RT services installed before the UEFI drivers can run their init. This makes it to the level of being UEFI compliant. Therefore, it is implied that the UEFI Drivers will get deferred to last There is a difference in building the UEFI Drivers into the flash part – is that it is possible for the UEFI driver to pick libraries that are not part of the UEFI spec. For example the report status code is gives the capability to redirect messages to the serial port. This is actually a PI not a UEFI concept. Any PI spec dependencies that a UEFI driver depends on would be Anded in. The same applies for an EFI Shell application.
A UEFI driver should not have a DEPEX expression – Integrated Drivers might have DXE Library these might be UEFI Drivers with Depex. The default for a UEFI Driver dependency expression is that it is dependent on all the Architectural protocols, (matched the DXE CIS in PI spec) PLUS all the DXE Libraries that the UEFI driver is being linked against. The build process will then take the “[DEPEX]” expressions from those libraries and append them to the list of architectural protocols. If the UEFI Driver only depends on the APs then the build process will optimize out the AP dependencies to save space in the flash. If however, the UEFI driver does have a dependency on a DXE Library then your UEFI driver will have a dependency on that library. For, example, “ReportStatusCode”. This library is not an AP but to get the consistency for the platform, a Firmware developer might want to include this in the platform build.
No, UEFI Drivers are for pre-boot environment only with exception of Network Drivers, since network support needs to be available for runtime in the event of booting over then network. UNDI does support runtime use in the spec, but we have not seen it used this way by an OS yet.
I want to connect my driver(Satacontroller.efi) instead of loaded device driver in my application. I already disconnect loaded driver and connect satacontroller.efi manually using connect command in shell. But I have to excute automatically in my application . How can I connect my device driver not using shell command ?
The EFI connect controller boot service, gBS->ConnectController(), is what you need to use. You can grep the source base to see how it is used
Normally, a UEFI driver will use the instance of the PCI I/O protocol that has been installed on the controller handle by the PCI bus driver. As the PCI bus is enumerated, it creates handles for each device found. Later, when the your Supported() function detects that one of the handles can be managed by your driver, you return EFI_SUCCESS. At that point, the Start() function of your driver is called to tell it to start managing the device. Then you use PCI I/O protocol installed on that handle to deal with the config space, I/O and memory-mapped I/O assigned to your device by the PCI bus driver. In this way, you never actually know what is the bus/fn/dev of your device. Instead the PCI bus driver knows it and translates your accesses.