On 2019/3/1 23:27, Laszlo Ersek wrote:
+Peter, for the last few paragraphs
On 02/28/19 13:10, Ard Biesheuvel wrote:
On Thu, 28 Feb 2019 at 09:06, Heyi Guo <guoh...@huawei.com> wrote:
Serial port output is useful when debugging UEFI runtime services in OS runtime.
The patches are trying to provide a handy method to enable runtime serial port
debug for ArmVirtQemu.
Cc: Jian J Wang <jian.j.w...@intel.com>
Cc: Hao Wu <hao.a...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Julien Grall <julien.gr...@arm.com>
Heyi Guo (3):
MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug
ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib
ArmVirtQemu: enable runtime debug by build flag
Hello Heyi,
We have had this discussion before, and IIRC, the proposed solution
was to use status codes.
I'm not sure how that is supposed to work though - hopefully Laszlo or
one of the MdeModulePkg maintainers can elaborate.
Here's the basic idea.
Status Code reporting and routing are defined by the PI spec for OS
runtime as well, not just boot time.
Recently we added status code *routing* to ArmVirtPkg, in commit
5c574b222ec2, via the generic runtime driver
"ReportStatusCodeRouterRuntimeDxe". We also added the library resolution
ReportStatusCodeLib -->
MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
(for some module types). As a result, when modules of those types report
status codes, they now reach the ReportStatusCodeRouterRuntimeDxe
driver, which "routes" the status codes.
In the same series, we also modified ArmVirtPkg's PlatformBootManagerLib
(built into BdsDxe) to register a status code *handler* callback with
ReportStatusCodeRouterRuntimeDxe -- but only for boot time (not
runtime), and only for a very specific group of status codes. As a
result, when a module of suitable type reports a status code,
ReportStatusCodeRouterRuntimeDxe "routes it" to BdsDxe, and then BdsDxe
"handles it" (in our implementation, we simply format it to the UEFI
console), assuming the status code is the kind we are interested in.
Now we come to the current series. First, the series adds the following
DebugLib class resolution:
DebugLib -->
MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
This will cause modules to publish their DEBUG messages as status codes
via ReportStatusCodeLib, rather than log them via SerialPortLib. (I'm
too lazy to check the exact status code classes etc that
PeiDxeDebugLibReportStatusCode embeds the DEBUG messages into.) As a
result, DEBUG messages will reach ReportStatusCodeRouterRuntimeDxe for
"routing". As another result, until we reach a late enough stage in the
boot, those messages will not be printed by anything (because there's
not going to be any "handling" for them).
(The present series also updates the ReportStatusCodeLib resolution so
it can be used at runtime too, but that's quite auxiliary to this
discussion.)
Second, this series includes the generic Status Code *handling* driver
(also a runtime driver): "StatusCodeHandlerRuntimeDxe". Independently of
the particular handling that we already have in BdsDxe via the earlier
series, this generic status handler driver registers a handler callback
that simply prints status codes to the serial port (dependent on a PCD
setting), via SerialPortLib.
With the modification from the first patch, this generic status code
*handler* driver is extended to runtime serial port operation. And, the
second patch in the series provides a SerialPortLib instance for it that
can work at runtime.
All in all, when a runtime driver calls DEBUG, this happens:
runtime driver calls DEBUG
-> PeiDxeDebugLibReportStatusCode
-> RuntimeDxeReportStatusCodeLib
[status code reporting]
=> ReportStatusCodeRouterRuntimeDxe
[status code routing]
=> StatusCodeHandlerRuntimeDxe
[status code handling, such as SerialPortWrite():]
-> FdtPL011SerialPortLibRuntime
This is actually a good idea, but it would be nice if:
- QEMU had two PL011 ports,
- the boot time firmware log, and the OS log, went to one port
- the runtme firmware log went to the other port.
This makes sense. I'll try the 2nd serial port.
Thanks,
Heyi
Given that this series provides the SerialPortLib instance for
StatusCodeHandlerRuntimeDxe anyway, we could implement it so that it
locate a "special" PL011 in QEMU's DTB -- the port that we'd only use
for runtime firmware logging.
I don't insist that this series implement all of that, but it should
either prevent a conflict on the one PL011 between the firmware and the
OS, or else be very explicit about the possible conflict in the commit
messages.
Thanks
Laszlo
.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
