> On Jul 22, 2015, at 12:56 AM, Saiprasad Chavali <[email protected]> wrote: > > Hi Andrew, > > The Dxe Driver is based on UEFI driver model, that has Support/Start/Stop, > not a bus driver.
You are not really giving enough information. You have a DXE driver that consumes and produces unknown protocols in a Start() routine? > To this driver model installed a custom protocol for application interface. > The application interface has routines which the shell app invokes to install > the Simple text protocol. > If the DXE Driver is producing the Simple Text protocol, all the application needs to do is gBS->ConnectController() to connect the driver. > The simple description you have added below, pasted for convenience (to avoid > any non-technical/EFI jargon) is exactly what I have. > > > “If by DXE driver handle you mean the handle that was created when your > driver was loaded, and contains the Loaded Image protocol. The answer is yes > you can add protocols to this handle. You only need to uninstall these > protocols if your driver is unloaded.” > > ***Q: Is it valid to use any of the custom protocol routines, to install the > SimpleText protocol? > If the Simple Text Protocol is produced by the driver model driver you need to call gBS->ConnectController() to connect it. This is the only way to establish the correct parent child relationship with the handles. > If this is valid, I will investigate? If not valid, I have to use UEFI driver > model “Start” routine to install , then will change the design. > Again you should never call Start(), only gBS->ConnectController() is allowed to call Supported()/Start(). > FYI: What I noticed based on the drivers in the packages either UEFI/EFI > driver model based, are calling install protocol from the driver Start > routine. > And the Stop() routine uninstalls the protocol. > So please clarify my Question? Don’t worry about the rest , crash, leaked > handles etc … will take care of that. > What problem are you trying to solve? Maybe that is an easier question to answer? Thanks, Andrew Fish > Thanks > Sai > > From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, July 21, 2015 11:06 PM > To: Saiprasad Chavali <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [edk2] Simple text protocol- Help > > > On Jul 21, 2015, at 7:28 PM, Saiprasad Chavali <[email protected] > <mailto:[email protected]>> wrote: > > Hi Andrew, > > Looks like you haven’t understood what I am trying here? > > > Sorry you are not using all the terminology correctly so it is hard to answer > the questions. > > > Questions: > 1) Can I install my own custom protocol on to the Dxe driver handle > under test ? Yes or No > > If by DXE driver handle you mean the handle that was created when your driver > was loaded, and contains the Loaded Image protocol. The answer is yes you can > add protocols to this handle. You only need to uninstall these protocols if > your driver is unloaded. > If you are talking about the controller handles produced by bus driver > following the EFI Driver Module (Driver Binding Protocol), then NO it is not > legal for you to directly add protocols to these handles. You need to add > protocols via the Driver Binding Start() routine, and remove them via the > Stop() routine. > > > 2) If Yes, to point 1) Can the custom protocol define routines? Yes or > No. > 3) If yes to both (1 & 2) , can I write a test app that can locate this > custom protocol interface. > 4) If yes, can the test app call these routines? > > > In it’s simplest form a protocol is a C structure defined by a GUID/UUID. You > can do anything you want if you create the handles. > > The (U)EFI driver model was introduced in the EFI 1.10 specification. So > there are things like register protocol notify, and install protocol that > pre-date the EFI driver model. > The basic way the EFI Driver module works is a DXE driver just produces a > protocol, that does not follow the EFI Driver Model. You need a protocol to > test for Supported() and to Start() on. This driver just installs a new > handle with the HW abstraction protocol, gEfiPciRootBridgeIoProtocolGuid for > PCI, and an EFI Device Path. > Then EFI Driver Module drivers are connected to this handle. EFI Driver Model > bus drivers produce child handles, device drivers layer on existing handles. > The driver model is followed all the way to leaf handles. > > Applications, like the EFI shell, may grab the leaf handles directly (not > following the driver model). This works as long as no one is doing a > gBS->DisconnectController(), and things can change with > gBS->ConnectController() too. Thus the shell tries to manage things when > these APIs are called. But the shell could still crash on a surprise hot > removal of a device (USB unplug). Thus to be pedantically correct the shell > should follow the EFI driver model too, but that is too complex of a topic to > bring up right now. > > > > If yes to all the questions above, can any of these custom protocol routines, > Install “Simple Text” protocol interface. I believe can install, as I am > stepping (Efi routine “Install multiple protocol interfaces” returns > EFI_SUCCESS) through the code. > > > As I mentioned before it is really a BAD idea to layer on top of a driver > model protocol, like USB IO, and not follow the driver model. > > > In this case when I hit on a key why the Simple Text call back routines are > not called? > > ****From the beginning it is the same question, if I Install the “Simple > Text” protocol interface from “EFI Driver Binding start” Routine, the key and > its Call backs works. Why not in the above case? > > > As I mentioned you are inserting your self in the middle of the stack, but > not using the driver model. > > So I think the answer to your question is: > 1) If you load your USB driver and follow the EFI Driver model it works, the > stack is all following the driver model (that is what I’ve been saying all > along). > So lets say you hot plug your USB device at the shell. > a) The usb bus driver detects the hot plug and calls > gBS->ConnectController() recursively on the handle that was added. > b) More child handles can get add, as there could be a USB hub etc. > c) Your device is connected. > d) The ConsoleSpliter driver gets connected so you device becomes an active > console. > > 2) You randomly install a protocol NOT following the driver model. The code > is NOT listening to see if a Simple Text In protocol is installed in the > system so no one cares that your protocol got added. The console is waiting > to get connected to your device, that is how boot devices work in UEFI. > > Thus in case 2, again this is kind of a bad idea you should really use the > EFI driver model, you might be able to fake it out by calling > gBS->ConnectController() on the handle you added the Simple Text protocols on > to get the console to work. This is not really correct per the UEFI > specification but it works due to the implementation of the Conspliter driver > that produces the EFI Consoles in a lot of systems. > > Depending on how you OpenProtocol the USB IO protocol, you are either going > to force the USB stack to leak handles (that will show up in the Shell) if > USB devices are removed, or if you just grabbed the protocol your Simple Txt > driver is going to exist, and it is going to call a USB IO protocol that no > longer exists and crash if the USB device was removed. And remember you are > hooked into the conspliter, so it is going to keep calling your Simple Text > In, so a crash is very likely. If you followed the driver model then the > disconnect controller from the USB bus driver would start at the leaf and > work backwards calling driver Stop() functions. So the Conspliter would get > Stopped 1st, and take your device out of the active console list, then your > driver would get stopped, then any hub between you and the mother board would > get stopped, etc. So in the case of console protocol the ConSpliter driver is > following the driver model, and then producing protocols that never go away. > So the console protocols are hot remove safe if you follow the EFI driver > model, it is things like BlockIo that can cause issues (if you are not in the > middle of a command you can rsync the shell with map -r). > > Thanks, > > Andrew Fish > > > > Thanks > Sai > > From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, July 21, 2015 7:14 PM > To: Saiprasad Chavali > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [edk2] Simple text protocol- Help > > > On Jul 21, 2015, at 6:59 PM, Saiprasad Chavali <[email protected] > <mailto:[email protected]>> wrote: > > Comments Inline >>> > > From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, July 21, 2015 6:49 PM > To: Saiprasad Chavali > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [edk2] Simple text protocol- Help > > > On Jul 21, 2015, at 6:29 PM, Saiprasad Chavali <[email protected] > <mailto:[email protected]>> wrote: > > Thanks Andrew, sorry to say this I am not confused, as well understood the > role of events. > (OR) I am not properly communicating,. > > 1) Installing the driver as a standalone, not attached to any device. > > What is the difference between installing the driver and Load the driver? We > don’t install drivers, we load drivers. We install protocols. > > [SAI] Yes it is Load: > > load “XX_DXE.efi” > > > > > 2) Installed the app protocol interface for an app to call the custom > routines defined > > You are talking about standard routines, this is the 1s mention of custom > stuff so it just makes things more confusing. > > [SAI] Custom Routines inside the Dxe driver, not the standard EFI call. > > > > > 3) Load the driver. > > What driver? > > [SAI] Same driver as in point 1). > > Ø load “XX_DXE.efi” > > > > > 4) Initiate the app to call the custom routines for example: start, > connect, stop etc.. > > No one EVER calls Start()/Stop() directly. The code calls gBS-> > ConnectConrtoller() or gBS->DIsconnectController()? What is this code doing? > > [SAI] Custom Routines inside the Dxe driver, not the standard EFI call. > “XX_start”., “ XX_Connect” etc … > > Test Application calls these routines, after loading the driver. > > > > > 5) If I Install the “Simple Text” inside a routine say “connect”, I > don’t see the event (“WaitForKey”) or not breakpoint inside the associated > event routine irrespective of whether you hit the key or not. > > What is a connect routine? That is not part of the EFI driver model? > > [SAI] The routine is NOT part of the standard API. It is a custom routine I > defined for the test application to call. > > > > > 6) Instead If I Install the “Simple Text” from the Driver start routine, > as soon as I load the driver, > > I forgot to mention that hot plug devices are different. Is this a USB > device? If so then you need to gBS->ConnectController() to have the console > splitter driver bind on the device. > > [SAI] yes it is a hot plug device, USB. > > > > > 7) I hit the breakpoint inside the “WaitForKey” event routine. Doesn’t > have to press any key. > > That is how WaitForKey works? WaitForKey is the event that gets signaled when > a key is pressed. As I corrected in the other mail you only signal the event > when a key is pressed. Thus it is your code that signals the event. > > I am trying to understand the behavior and accordingly change my design. I > hope I am clear. If the behavior has to be consistent, there should not be > any variations between point 5 & 6, will investigate. > > [SAI] Is a USB device. > > If this is a USB device you have to follow the EFI driver model to make it > work. > > > > Yea so you should just follow the EFI driver model and it will work. If you > make up your own driver model things like xx_start() xx_connect() lots of > stuff is going to break, as you found out the hard way. > > FYI if you are a USB Device this code can get you added in without the > variables. For example this make the hot plug of a USB keyboard work: > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c > > <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c> > /** > Check if the device supports hot-plug through its device path. > This function could be updated to check more types of Hot Plug devices. > Currently, it checks USB and PCCard device. > @param DevicePath Pointer to device's device path. > @retval TRUE The devcie is a hot-plug device > @retval FALSE The devcie is not a hot-plug device. > **/ > BOOLEAN > IsHotPlugDevice ( > IN EFI_DEVICE_PATH_PROTOCOL *DevicePath > ) > { > EFI_DEVICE_PATH_PROTOCOL *CheckDevicePath; > CheckDevicePath = DevicePath; > while (!IsDevicePathEnd (CheckDevicePath)) { > // > // Check device whether is hot plug device or not throught Device Path > // > if ((DevicePathType (CheckDevicePath) == MESSAGING_DEVICE_PATH) && > (DevicePathSubType (CheckDevicePath) == MSG_USB_DP || > DevicePathSubType (CheckDevicePath) == MSG_USB_CLASS_DP || > DevicePathSubType (CheckDevicePath) == MSG_USB_WWID_DP)) { > // > // If Device is USB device > // > return TRUE; > } > if ((DevicePathType (CheckDevicePath) == HARDWARE_DEVICE_PATH) && > (DevicePathSubType (CheckDevicePath) == HW_PCCARD_DP)) { > // > // If Device is PCCard > // > return TRUE; > } > > CheckDevicePath = NextDevicePathNode (CheckDevicePath); > } > return FALSE; > } > > > > > Thanks, > > Andrew Fish > > > > > > Thanks > Sai > > > From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, July 21, 2015 6:09 PM > To: Saiprasad Chavali > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [edk2] Simple text protocol- Help > > > On Jul 21, 2015, at 5:52 PM, Saiprasad Chavali <[email protected] > <mailto:[email protected]>> wrote: > > Hi Andrew, > > I do install the device path protocol. What I am trying is, to install the > Text Protocol Interface at later stage rather during Start routine. > > > That does not make any sense. The Start() routine is called vary late in boot > as the drivers are connected in the BDS, a long long time after your driver > has returned? I think you are confused on how the EFI driver model works. > > > > > > The Question I have is "WaitForKey" is triggered when I call during start > routine, not at a later stage. So wondering all has to be initialized inside > the start routine. > > > WaitForKey is not triggered via Start(). WaitForKey is an event that is > published by your driver. The UI code, like the EFI Shell, is going do to a > gBS->WaitForEvent() and pass in a WaitForKey event to know when a key has > been pressed. In most systems the console device is the ConSpliter driver, > and the WaitForKey event just companies the WaitForKey events of the active > console. Your driver needs to get added to the list of active consoles or it > will never get called. Basically the Con* variables defined is 3.2 Global > Defined Variables, in the UEFI spec, need to get set. > > Generally the BDS will use a PlatformBdsLib to set the list of supported > consoles: > https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Library/EmuBdsLib/EmuBdsLib.inf > > <https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Library/EmuBdsLib/EmuBdsLib.inf> > > https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Library/EmuBdsLib/PlatformData.c > > <https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Library/EmuBdsLib/PlatformData.c> > Look at gPlatformConsole > > Your device will need to be in this list. Or if your BDS is different it > should have some similar concept. > > Thanks, > > Andrew Fish > > > > > > Thanks > Sai > > -----Original Message----- > From: Andrew Fish [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, July 21, 2015 5:43 PM > To: Saiprasad Chavali > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [edk2] Simple text protocol- Help > > > > > > > On Jul 21, 2015, at 5:28 PM, Saiprasad Chavali <[email protected] > <mailto:[email protected]>> wrote: > > Hi, > > I am facing an issue while installing the Simple text protocol (or) Simple > text ex protocol outside the "DriverBindingStart" routine? The API > "InstallMultipleProtocolInterfaces" succeeds but there is no call to the > "WaitForKey" Event routine. > > > Did you install a device path protocol on the handle? Did you update the BDS > to list that device path as an active console? > > > > > > Any idea what could be the cause? (Or) it is mandatory we have to install all > the protocols in the driver start routine. > > > In general it is better to use the EFI Driver Binding protocol so that you > only have to connect the devices involved in booting. Also if your down > stream hardware device is following the driver binding module, you have to > follow it. Thus most things PC are children of the PCI bus driver. > > Thanks, > > Andrew Fish > > > > > > Thanks > Sai > > > _______________________________________________ > edk2-devel mailing list > [email protected] <mailto:[email protected]> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
