Hi Rui, Yes, I can use this solution as a work around and it resolves the issue.
But I feel it is not the correct way to resolve the issue. Thanks, Naresh -----Original Message----- From: Sun, Rui [mailto:[email protected]] Sent: Thursday, July 19, 2012 3:29 PM To: Naresh Kollu.; [email protected] Subject: RE: . Re: Edk2 FAQ - INF SMM dependency Naresh, You may define an additional empty protocol (no protocol interface but used for dependency only) with a new GUID. Let the SMM driver produce both the common protocol and this empty protocol. The other SMM driver can depend on both protocols. Does this solve your issue? -----Original Message----- From: Naresh Kollu. [mailto:[email protected]] Sent: Thursday, July 19, 2012 5:52 PM To: [email protected] Cc: Sun, Rui Subject: . Re: Edk2 FAQ - INF SMM dependency Hi Rui, Thanks for the reply. Having different guilds for DXE and SMM solves my issue but in the specification only one guid was mentioned and the protocol should be available in both SMM and DXE modes. In such case, I can use only the GUID which is mentioned in the specification for both DXE and SMM. Is there any solution from EDKII point of view for such kind of issues ? Thanks, Naresh -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Thursday, July 19, 2012 12:14 PM To: [email protected] Subject: edk2-devel Digest, Vol 31, Issue 48 Send edk2-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/edk2-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of edk2-devel digest..." Today's Topics: 1. Re: Edk2 FAQ - INF SMM dependency (Sun, Rui) 2. Re: SMM Driver question in EDKII (Sun, Rui) 3. Reg : : GDB for ARM (Satheesh B R) ---------------------------------------------------------------------- Message: 1 Date: Thu, 19 Jul 2012 02:26:58 +0000 From: "Sun, Rui" <[email protected]> Subject: Re: [edk2] Edk2 FAQ - INF SMM dependency To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Message-ID: <7584c2c1a1745b4ca9e83c53cf180a960e5...@shsmsx101.ccr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Hi, Naresh, Let's clarify the usage of <SMM_DEPEX> and <DXE_DEPEX>. They are intended to be used for DXE/SMM Combined drivers. <SMM_DEPEX> specifies the dependency expression when a combined driver is dispatched as a SMM driver by the SMM Driver Dispatcher. <DXE_DEPEX> specifies the dependency expression when the combined driver is dispatched as a DXE driver by the DXE Driver Dispatcher. Please refer to the EDK II INF File Specification. It is possible for a SMM driver to have dependency on SMM or UEFI protocols. Current implementation of the SMM Driver Dispatcher will attempt to locate a dependency GUID in the SMM handle database, if failed, then attempt to locate it in the UEFI handle database. See the following code piece in SmmIsSchedulable() under MdeModulePkg/Core/PiSmmCore: Status = SmmLocateProtocol (&DriverGuid, NULL, &Interface); if (EFI_ERROR (Status)) { // // For SMM Driver, it may depend on uefi protocols // Status = gBS->LocateProtocol (&DriverGuid, NULL, &Interface); } For your case, you have to assign different GUIDs to the protocol in DXE and SMM. -----Original Message----- From: Naresh Kollu. [mailto:[email protected]] Sent: Wednesday, July 18, 2012 7:09 PM To: [email protected]; [email protected] Subject: Re: [edk2] Edk2 FAQ - INF SMM dependency Hi Andrew, Thank you very much for the reply. I am using driver type as DXE_SMM_DRIVER and SMM_DEPEX is created. You can refer the attached TestSmmDriver.inf and TestSmmDriver_output.inf(Output inf generated in build directory) files. TestSmmDriver_Output.inf has SMM_DEPEX included under [Binaries.X64] section. [Depex] <SMM_DEPEX> gSmmProtocolToDependOn <DXE_DEPEX> gDxeProtocolToDependOn I have tried to use like above but I was getting build errors saying that "<SMM_DEPEX> is not present under any .dec file". I also feel that information on Depex is not clearly mentioned in INF specification. They should have given some example for this. Can you please give your suggestions on it ? Thanks, Naresh -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, July 18, 2012 4:06 PM To: [email protected] Subject: edk2-devel Digest, Vol 31, Issue 43 Send edk2-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/edk2-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of edk2-devel digest..." Today's Topics: 1. Re: Edk2 FAQ - INF SMM dependency (Andrew Fish) 2. Re: Debug UEFI Bootable with virtualbox (Rafael Machado) 3. Announcing Update to Signing document (Jarlstrom, Laurie) 4. Re: MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path (Ni, Ruiyu) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Jul 2012 09:49:04 -0700 From: Andrew Fish <[email protected]> Subject: Re: [edk2] Edk2 FAQ - INF SMM dependency To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" I think what you are asking is how to create an EFI_SECTION_SMM_DEPEX in the FV image for your module? The DXE dispatcher uses the EFI_SECTION_DXE_DEPEX for dispatch, while SMM used EFI_SECTION_SMM_DEPEX. The Smst name space is totally independent in regards to the DXE/EFI protocol database. So I would imagine if your driver is of type DXE_SMM_DRIVER and you have a [Depex] in your INF that an EFI_SECTION_SMM_DEPEX should be created. If you are not using that driver type then I think you need to use <SMM_DEPEX> sub-section tag. I've not tried this, and it is not totally clear from the documentation, but I think it should look like: [Depex] <SMM_DEPEX> gSmmProtocolToDependOn <DXE_DEPEX> gDxeProtocolToDependOn You should be able to use the VolInfo tool to dump out the FV and see what type of depex sections get created. Andrew Fish On Jul 17, 2012, at 2:03 AM, Naresh Kollu. wrote: > Hi, > > If same protocol guid is installed in both DXE(using pbs->InstallProtocol()) and SMM(using Smst->InstallProtocol()), when we try to add the same guid dependency in other SMM driver, the dependency is evaluated with DXE instance not SMM instance. Because of this, the dependent SMM driver is getting dispatched before the SMM driver which produces the the protocol GUID. > > Is there any other way by which we can refer to SMM instance for the same GUID ? > > I think this should be supported by EDKII INF component but do not know exactly how to use this. If EDKII INF supports, can you please give an example ? > > Please give your suggestions on it. > > Thanks, > Naresh > > ---------------------------------------------------------------------- > -------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_____________ > __________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 2 Date: Tue, 17 Jul 2012 14:30:27 -0300 From: Rafael Machado <[email protected]> Subject: Re: [edk2] Debug UEFI Bootable with virtualbox To: [email protected] Message-ID: <CACgnt7_hj_SWaXSpNMKenwXo=vochuuoizk1eth-laoawye...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi Denis I've tried this too, but no success. Rafael Machado 2012/7/16 Denis Alberto Silverio <[email protected]> > Hi, > i am learning about UEFI, and i would like to debug my uefi bootable > iso in virtual box. It's possible? > Thank you! > > -- > D?nis Alberto Silverio > > > ---------------------------------------------------------------------- > -------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 3 Date: Tue, 17 Jul 2012 18:40:40 +0000 From: "Jarlstrom, Laurie" <[email protected]> Subject: [edk2] Announcing Update to Signing document To: "[email protected]" <[email protected]> Message-ID: <10380531df222b45964be3e93efe5f0448b90...@fmsmsx110.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Update to the Documentation on Signing UEFI Applications and Drivers for UEFI Secure Boot. Signing UEFI Images.pdf V1.2.1<http://sourceforge.net/projects/edk2/files/General%20Documentatio n/SigningUefiImages%20-v1dot21.pdf/download> This document describes how to sign UEFI images for the development and test of UEFI Secure Boot feature using the UDK2010.SR1.UP1 release and also provides an overview of the UEFI Secure Boot feature of UEFI 2.3.1C See SecurityPkg<https://sourceforge.net/apps/mediawiki/tianocore/index.php?t itle=SecurityPkg> for more documentation on security features with UDK2010 and UEFI. thanks, Laurie [email protected]<mailto:[email protected]> EFI / Framework Technical Marketing Engineering Team (503) 712-9395 -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 4 Date: Wed, 18 Jul 2012 10:35:36 +0000 From: "Ni, Ruiyu" <[email protected]> Subject: Re: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path To: "[email protected]" <[email protected]> Cc: 'Tim Lewis' <[email protected]> Message-ID: <734d49ccebeef84792f5b80ed585239d14e...@shsmsx101.ccr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Olivier, The reason of the hang can easily be seen due to the ASSERT(). And I intended to only do the check in DEBUG mode because the PCD for count of device path node in a device path is hard to define. The 3rd party UEFI OpROMs can create their own device path. Spec doesn't restrict the device path node count. Thanks, Ray -----Original Message----- From: Olivier Martin [mailto:[email protected]] Sent: Thursday, July 12, 2012 5:41 PM To: [email protected] Cc: 'Tim Lewis' Subject: Re: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path Sorry Ray, I missed your email. The issue with your patch is you do not handle the error in your code. You only have 'ASSERT()'. It means if the DevicePath is corrupted your platform still hang (in this case due to the ASSERT()). And if you have disabled ASSERT() macro in your DSC file it will still lock. Olivier -----Original Message----- From: Ni, Ruiyu [mailto:[email protected]] Sent: 05 July 2012 04:06 To: [email protected] Cc: 'Tim Lewis' Subject: Re: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path Olivier, I read your patch and comes with a refined one. Could you please check whether it meets your needs? The patch aligns to the current checking pattern in LinkedList.c and it only does the check in DEBUG mode as well. Thanks, Ray -----Original Message----- From: Olivier Martin [mailto:[email protected]] Sent: Thursday, July 05, 2012 2:22 AM To: [email protected] Cc: 'Tim Lewis' Subject: Re: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path Ray, Please find the patch I submitted in a different thread of the EDK2 development mailing-list. Regards, Olivier -----Original Message----- From: Ni, Ruiyu [mailto:[email protected]] Sent: 21 June 2012 02:32 To: [email protected] Subject: Re: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path Olivier, I agree with your concern. Do you have any suggestion? Thanks, Ray -----Original Message----- From: Olivier Martin [mailto:[email protected]] Sent: Wednesday, June 20, 2012 10:03 PM To: [email protected] Subject: [edk2] MdePkg/UefiDevicePathLib: Potential lock in the loop to go to the end of a EFI Device Path Hello, The loop is this one: Start = DevicePath; while (!IsDevicePathEnd (DevicePath)) { DevicePath = NextDevicePathNode (DevicePath); } This loop exists in different forms in these functions: GetNextDevicePathInstance (), GetDevicePathSize (), IsDevicePathMultiInstance (). For some reasons, my EFI environment variables have been corrupted. And the Device Path attached to one of the variables did not make sense anymore. One of the functions above was scanning for the end of the Device Path (type: END_DEVICE_PATH_TYPE). Unfortunately, the corrupted EFI Device Path Node has the length '0'. So the function NextDevicePathNode() always returns the same Node (and locked the UEFI firmware). How should we fix the manipulation of a corrupted Device Path Node ? Should we introduce a function to check the validity of Device Path (eg: by checking the length of a Device Path is valid against a maximum size) ? Or should we modify the loops above to avoid a lock ? Regards, Olivier ------------------------------------------------------------------------ ---- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------ ---- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------ ------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------ ------------------------------------------------------------------------ ------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel End of edk2-devel Digest, Vol 31, Issue 43 ****************************************** ------------------------------ Message: 2 Date: Thu, 19 Jul 2012 02:32:40 +0000 From: "Sun, Rui" <[email protected]> Subject: Re: [edk2] SMM Driver question in EDKII To: "[email protected]" <[email protected]> Message-ID: <7584c2c1a1745b4ca9e83c53cf180a960e5...@shsmsx101.ccr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Garrett, Currently, the EDKII build system does not support build a DXE/SMM combination driver, although the DXE Dispatcher and SMM Driver Dispatcher support loading such a driver image from FV. There is an alternative way to work-around this issue. That is, have two INF files in the same directory, one is for DXE driver, the other is for SMM driver. The disadvantage is size impact (some common code is duplicated in two driver images). From: Kirkendall, Garrett [mailto:[email protected]] Sent: Wednesday, July 18, 2012 9:55 PM To: [email protected] Subject: [edk2] SMM Driver question in EDKII Can the EDKII build tools support generating a combination DXE and SMM driver of type EFI_FV_FILETYPE_COMBINED_SMM_DXE like the PI 1.2.1 specification suggests? >From what I have found and seem to have confirmed with VolInfo.exe, the INF file MODULE_TYPE = DXE_SMM_DRIVER creates a file of type EFI_FV_FILETYPE_SMM and an EFI_SECTION_SMM_DEPEX. If this is true, what are other developers doing when they have two pieces of code that are closely related that would have been developed as a single driver in EDK? Two separate drivers? Or am I missing something? Thanks, Garrett Kirkendall -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 3 Date: Thu, 19 Jul 2012 12:12:25 +0530 From: "Satheesh B R" <[email protected]> Subject: [edk2] Reg : : GDB for ARM To: <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Hi All I am trying to debug the DXE driver remotely. I use X-86 GDB of my host machine(Ubuntu) to debug the target(BeagleBoard Rev C4) connected by serial port. I have done the following : Connect the host and target using serial cable. Booting to the shell in the target machine(GdbStub has been added in the boot file). In host establishing the connection by command "target remote /dev/ttyUSB0" in gdb. "cd" to the directory where the 'dll' of DXE driver present. Adding symbol file using the command "file DRIVER_NAME.dll " Now on giving the "run" command I get <workroot>/DRIVER_NAME.dll : cannot execute binary file <workroot>/DRIVER_NAME.dll : Success During startup program exited with code 126. Am I following the correct procedure.Please help me with the same. Thanks and Regards Satheesh.B.R -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ ------------------------------------------------------------------------ ------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ------------------------------ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel End of edk2-devel Digest, Vol 31, Issue 48 ****************************************** ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
