> On May 20, 2016, at 12:36 AM, Iru Cai <[email protected]> wrote: > > It's a good idea, but I still have some problems. My ccidboot driver has > different behaviors depending on whether a CCID card is plugged in, so I > think I also need a timer event to check if gEfiCcidProtocolGuid is > installed to a handle in time.
No that is a bad idea. It sounds to me like you have some kind of fundamental design flaw. If I had to guess it has to do with understanding the EFI Driver Model. This is a good reference on writing an UEFI Driver: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer's-Guide > However, I need the code executed before > the boot manager starts. Why? > In my case in OVMF, if I set a time too long in > the timer event, its notification function will run after the EFI shell > starts, and this is not what I want. > > So now I need this in my ccidboot: when a CCID card is plugged in, it can > wait for gEfiCcidProtocolGuid installed to a handle, and if no card is > plugged in before BDS phase, it'll run other code. > I'm guessing the issue is you are trying to mix UEFI Driver Model code with non UEFI Driver Model code. A UEFI Driver Model driver registers a Driver Binding Protocol. So basically when a driver is loaded all it does is install a few protocos and returns. This is very different than the legacy BIOS as the option ROM basically takes over the system. When we designed EFI we got a lot of feedback from option ROM writers that they had to put in work arounds for the BIOS, the BIOS vendors mentioned they had to put in work arounds for option ROMs, and the big OEMs complained all these work arounds caused chaos, and at times to make the platforms work correctly, or follow the correct platform policy, they would have to get a custom version of the option ROM produces. Given the state of BIOS we decided the best approach would be to make the option ROM (UEFI Driver) as simple as possible, and move all the policy into the platform. The BDS (Boot Manager in UEFI Spec speak, BDS is a PI Spec thing) is executing the platform policy and it is the one Starting the drivers (via gBS->ConnectController()). What devices gets started is platform policy, so for a fast boot only boot devices may be started. The devices are connected recursively so if you connect a Block IO device, that partition driver will get connected and produce child Block Io handles, and the file system driver will also get connected. I'd also point out given the UEFI design is to concentrate the the policy in platform you may need to customize the BDS if you are trying to change some kind of fundamental platform policy. Thanks, Andrew Fish > Thanks > Iru > > On Thu, May 19, 2016 at 3:22 PM, Gao, Liming <[email protected]> wrote: > >> You can create ProtocolNotification function for gEfiCcidProtocolGuid in >> ccidboot driver. If so, you don't need add it into [Depex]. >> UefiLib EfiCreateProtocolNotifyEvent() API can help to create it. >> >> Thanks >> Liming >>> -----Original Message----- >>> From: edk2-devel [mailto:[email protected]] On Behalf Of >> Iru >>> Cai >>> Sent: Thursday, May 19, 2016 2:35 PM >>> To: [email protected] >>> Subject: [edk2] Driver dependency on boot >>> >>> Hi, >>> >>> I'm having some dependency problem when developing on edk2. I've >>> written a >>> CCID device driver which provides a protocol EFI_CCID_PROTOCOL with GUID >>> gEfiCcidProtocolGuid. And I have another application called ccidboot to >> be >>> run on boot that uses gEfiCcidProtocolGuid, I set the module type as >>> DXE_DRIVER. >>> >>> If I add gEfiCcidProtocolGuid to the [Depex] of ccidboot, it works good >>> when I have my CCID card plugged, but it'll not run if the card is >>> unplugged. If I don't add this dependency, the ccidboot module will run >>> before the driver starts the card. I don't know what I should do to solve >>> this problem. >>> >>> Thanks, >>> Iru >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel >> > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
