[MinnowBoard] [edk2] How to DebugPrint in SMM at runtime?

Sat Feb 14 06:19:44 UTC 2015

inline

On Fri, Feb 13, 2015 at 7:23 PM, Andrew Fish <afish at apple.com> wrote:

>
> On Feb 13, 2015, at 3:24 PM, Edward Chicopee <edward.chicopee at gmail.com>
> 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.
>

That makes sense, and is a good point. Thanks for setting me straight
there, lest I keep thinking about it wrong.

>
> 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.
>

Anyone know how to pass this -y build.log through to the MinnowMax
Build_IFWI.bat so that it generates that log file?

>
> 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
>

For the MinMAX076 folder that yields

IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf:
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:
LIBRARY_CLASS = DebugLib

MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf: LIBRARY_CLASS =
DebugLib

MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf:
LIBRARY_CLASS = DebugLib

MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf: 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: LIBRARY_CLASS =
DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER
DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER

So if I'm following you correctly, you're saying that if I look at
something like the PiSmmCore.inf, first it confirms that it consumes the
DebugLib Library Class (API), and then I look at the
C:\MinMAX076\Vlv2TbltDevicePkg\PlatformPkgIA32.dsc that the target.txt
points at, it tells me that if it's a debug build, it links against the
code created by the
"DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf"
file.
And based on that grep command, I know that this supports basically all the
module types.

Did I interpret that correctly?

Thank you

Ed

>
> 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
> edk2-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20150214/d3a67983/attachment.html>