> On Feb 13, 2015, at 3:24 PM, Edward Chicopee <[email protected]>
> wrote:
>
> After finding out OVMF doesn't do SMM (on the EDK2-devel list), I decided to
> try working on a MinnowboardMax (hello minnow list too!)
>
> I can see with the MinnowboardMax serial port debug output that if I write
> 0x01 to port 0xB2, it prints some things like
> "PiSmmCommunicationHandler Enter"
> "PiSmmCommunicationHandler CommunicateHeader - 0"
> etc
> But when I search through the source code such lines don't seem to be present.
>
> Eventually I found that they exist in a binary-only package,
> MinMAX076\Vlv2BinaryPkg\IA32DEBUG\IA32\PiSmmCommunicationSmm.efi
> Running strings on the binary seems to imply that it was linked against
> things like MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c
>
> As I did with OVMF, I just put a "DebugPrint (0xFFFFFFFF, "Hi from SMM\n");
> into PiSmmCore.c. I see printout at boot time, but not at runtime upon
> forcing an SMI. I assume this is because it's just using some DXE DebugPrint
> which goes away at runtime? And I assume the reason the binary package can
> continue to DebugPrint into runtime is because it has (static?) linked
> against the DebugLib.c and so it contains all the code it needs internally?
> Or maybe the serial port configuration gets screwed up at runtime? But then I
> would expect after the first PiSmmCommunicationHandler print for it to be
> reconfigured properly.
>
> I can see that PiSmmCode.inf says MdePkg/MdePkg.dec is under [Packages], and
> DebugLib is under [LibraryClasses], so maybe it's some other reason I can't
> see my DebugPrint in PiSmmCore.c at runtime only?
>
Ed,
The INF defines the Library Class (think API) that the driver consumes. There
is not a 1:1 mapping between a Library Class (API) and a Library Instance
(Implementation).
The DSC defines the which Library Instance is linked against the driver. The
idea is the library choices are pushed into the platform build, and don’t exist
in the INF. So for example if you get Reference Code for the Silicon you don’t
need to modify it to use a different debug scheme.
> So any help on how to see the print and/or (static?) link against the
> DebugLib.c that so
All linking in the edk2 is static linking. Dynamic stuff is all done in code
via Protocols.
> I can keep printing at runtime would be very appreciated.
>
I don’t know the specifics of your platform but the best way to see what is
going on is to generate a build report. You do this by adding a -y build.log to
the build command. You can lookup the driver you care about and it will show
you what libraries where used. If those libraries depended on libraries it will
show you that too.
A quick way to figure out the different DebugLib instances is to do something
like:
~/work/src/edk2(master)>git grep DebugLib -- *.inf | grep LIBRARY_CLASS
ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf:24: LIBRARY_CLASS
= DebugLib|BASE SEC DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER
DXE_SAL_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf:24:
LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE
UEFI_APPLICATION UEFI_DRIVER
IntelFspPkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort.inf:21:
LIBRARY_CLASS = DebugLib
MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf:23: LIBRARY_CLASS
= DebugLib
MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf:24:
LIBRARY_CLASS = DebugLib
MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf:25: LIBRARY_CLASS
= DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER
DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf:25: LIBRARY_CLASS
= DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER
DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf:24:
LIBRARY_CLASS = DebugLib
This will show you the set of Library Instances that produce the DebugLib
LibraryClass, and what module types they support.
Good luck,
Andrew Fish
> Ed
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
