WO2020145973A1

WO2020145973A1 - Event logs with firmware debug information

Info

Publication number: WO2020145973A1
Application number: PCT/US2019/012973
Authority: WO
Inventors: Valiuddin Ali; Dallas M. Barlow; Richard Bramley
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2019-01-10
Filing date: 2019-01-10
Publication date: 2020-07-16

Abstract

In example implementations, an apparatus is provided. The apparatus includes a memory, an operating system (OS) driver, a kernel debug support, and a processor. A portion of the memory is reserved to receive firmware debug information. The OS driver accesses the firmware debug information in the portion of the memory that is received. The kernel debug support receives the firmware debug information for an event log. The processor is to control execution of the OS driver and to access the memory. The processor also writes the firmware debug information into the event log.

Description

EVENT LOGS WITH FIRMWARE DEBUG INFORMATION

BACKGROUND

[0001] Computing devices execute software applications. The software applications may be written and tested on the computing device as the operating system executes the software application. Testing of the software application may include debugging. Debugging may include observing how the software operates line-by-line to detect potential errors in the software application.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 is a block diagram of an example apparatus that includes a driver to access firmware debug information in a reserved memory space of the present disclosure;

[0003] FIG. 2 is a more detailed block diagram of an apparatus that includes the driver to access firmware debug information in a reserved memory space of the present disclosure, according to an example;

[0004] FIG. 3 illustrates an example of a window of a viewer tool for viewing debugging information of the present disclosure;

[0005] FIG. 4 is a block diagram of an example non-transitory computer readable storage medium storing instructions executed by a processor to write firmware debug information to event logs of an operating system of the present disclosure; and

[0006] FIG. 5 is a block diagram of an example non-transitory computer readable storage medium storing instructions executed by a processor to write firmware debug information to event logs of an operating system.

DETAILED DESCRIPTION

[0007] Examples described herein provide a method and apparatus to write firmware debug information to event logs of an operating system (OS) of the present disclosure. As discussed above, applications can be debugged when being executed by the OS (e.g., a Windows OS) to try to detect errors.

However, when the OS makes a call to the firmware (e.g., unified extensible firmware interface (UEFI), a basic input/output system (BIOS), and the like) as part of executing the application, none of the activity of the firmware is accessible by the OS. As a result, there may be gaps of information when the event logs are created for debugging the application. The gaps may be created during time periods in which the OS pauses operation while the firmware is executing various instructions.

[0008] Currently, the firmware debug information can be accessed via external systems that can pull information stored in firmware memory.

However, using external systems to obtain the firmware debug information can be cumbersome and inefficient.

[0009] Examples herein provide a driver in the OS that can access the firmware debug information in a reserved portion of memory. The firmware debug information can be written to the reserved portion of memory. The driver may access the firmware debug information and provide the firmware debug information to a kernel debug support. The kernel debug support may then write the firmware debug information into an event log with the OS debug information. As a result, a viewer tool for viewing debugging information may display the event log that includes both firmware debug information and OS debug information.

[0010] FIG. 1 illustrates a high level block diagram of an example apparatus 100 with a driver that can access firmware debug information in a reserved memory space of the present disclosure. The apparatus 100 may be a computing device, such as a desktop computer, a laptop computer, a tablet computer, and the like. The apparatus 100 may be any type of computing device that includes an operating system (OS) and executes firmware.

[0011] In one example, firmware may be instructions that are executed to provide low-level control for hardware in the apparatus 100. The firmware may be an initial set of instructions that is executed when the apparatus 100 is turned on or initially booted. Some examples of firmware may include UEFI, BIOS, and the like.

[0012] In one example, the apparatus 100 may include a processor 102, an OS driver 104, a memory 106, and a kernel debug support 1 12. The processor 102 may be communicatively coupled to the OS driver 104, the memory 106, and the kernel debug support 1 12 to control operation of the OS driver 104, the memory 106, and the kernel debug support 1 12. In one example, the OS driver 104, the memory 106, and the kernel debug support 1 12 may be part of an OS layer of a computing system, as illustrated in FIG. 2 and discussed in further details below.

[0013] In one example, the memory 106 may be any type of non-transitory computer readable memory. The memory 106 may be system memory such as a random access memory (RAM). In some examples, the memory 106 may be a hard disk drive, or other types of non-volatile memory.

[0014] In one example, a portion of memory 108 may be reserved to store firmware debug information 1 10. In one example, the portion of memory 108 may be pre-determined. In one example, the portion of memory 108 may be dynamically set aside at boot time when the apparatus 100 is powered on. In other words, the portion of memory 108 may change in location or memory address within the memory 106 each time the apparatus 100 is powered on.

[0015] The portion of memory 108 may be reserved such that the OS of the apparatus 100 may not be able to write to the portion of memory 108. Rather, the portion of memory 108 may be reserved to receive and store the firmware debug information 1 10. The firmware debug information 1 10 may include debug output statements related to instructions or code executed by the firmware (e.g., the BIOS) in response to calls from applications that are executed in the OS. The firmware debug information 1 10 may include debug errors, debug information, debug warnings, debug tracing information, and the like.

[0016] As noted above, when performing software debugging, the firmware debug information 1 10 from the firmware may be unavailable with the debug information of applications that are executed in the OS. Rather, separate external systems may be used to read the firmware debug information 1 10 isolated from the debug information of the applications that are executed in the OS. As a result, accurate debugging of software applications can be difficult.

[0017] In one example, the OS driver 104 and the portion of memory 108 may modify the way the apparatus 100 operates to allow the OS layer to access the firmware debug information 1 10. For example, the processor 102 may cause the OS driver 104 to access the firmware debug information 1 10 from the portion of memory 108. The processor 102 may cause the OS driver 104 to provide the firmware debug information 110 to the kernel debug support 1 12.

[0018] The OS driver 104 may be triggered to access the firmware debug information 1 10 in a variety of different ways. For example, the OS driver 104 may be notified or may perform periodic polling. In one example, an interrupt process, a semaphore, and the like, may be used.

[0019] In one example, the kernel debug support 1 12 may receive debug information from various applications executed in the OS layer during debugging. For example, an application programming interface (API) call for an “output debug string” can be executed by applications to write debug

information or debug output statements to the kernel debug support 1 12.

Similarly, the OS driver 104 can execute an API call, such as“output debug string,” to write the firmware debug information 1 10 to the kernel debug support 1 12.

[0020] The kernel debug support 1 12 may create an event log 1 14. The event log 1 14 may be an OS dependent capability where events can be passed directly to listeners or discarded when a user, another application that monitors the events, and the like are not listening, buffered in a circular buffer, or written to non-volatile storage. In one example, the event log 1 14 may include the firmware debug information 1 10 and the debug information received from applications that are executed in the OS layer. The event log 1 14 may be provided to a viewer tool for viewing debugging information (as discussed in further details below). With the combination of firmware debug information 1 10 and the debug information from applications in the OS layer, the viewer tool may provide a complete view of debug errors. In other words, the event log 1 14 may be free from any gaps in the timeline that were in previous event logs due to missing information from the firmware debug information not being accessible by the OS layer.

[0021] FIG. 2 illustrates a more detailed block diagram of an apparatus 200 that includes a driver to access firmware debug information in a reserved memory space of the present disclosure. In one example, the apparatus 200 may include an OS layer 202 and a firmware layer 204. The OS layer 202 may execute any type of operating system software, such as Windows™. The firmware layer 204 may be one example of a type of firmware that can be executed at boot time by a computing device (e.g., BIOS, UEFI, and the like). However, it should be noted that any type of firmware layer can be deployed in the apparatus 200.

[0022] Although the OS layer 202 and the firmware layer 204 are illustrated as being clearly divided by a line, it should be noted that the line is provided for ease of explanation. For example, the OS layer 202 and the firmware layer 204 may be divided by process separation, memory separation, code separation, and the like, among common components within the apparatus 200.

[0023] In one example, a processor 222 may be communicatively coupled to the OS layer 202 and the firmware layer 204 to control operation of the OS layer 202 and the firmware layer 204.

[0024] In one example, the apparatus 200 may include a memory 226. The memory 226 may be any type of non-transitory computer readable memory.

The memory 226 may be system memory such as a random access memory (RAM). In some examples, the memory 226 may be a hard disk drive, or other types of non-volatile memory.

[0025] As described above, the memory 226 may include a portion of memory 228 that may be reserved to store firmware debug information 230. In one example, the portion of memory 228 may be pre-determined. In one example, the portion of memory 228 may be dynamically set aside at boot time when the apparatus 200 is powered on. In other words, the portion of memory 228 may change in location or memory address within the memory 226 each time the apparatus 200 is powered on.

[0026] In one example, when the portion of memory 228 is dynamically set aside or reserved, the location or memory address associated with the portion of memory 228 may be provided to an OS driver 224. The OS driver 224 may know where to check in the memory 226 for the firmware debug information 230.

[0027] In one example, the portion of memory 228 may function as a circular buffer. In other words, the firmware debug information 230 may be stored in the portion of memory 228 in a first in first out (FIFO) method or the oldest information may be overwritten by the newest information when the maximum memory space is exceeded. In one example, the portion of memory 228 may be cleared after each debug process is executed, at boot time when the apparatus 200 is powered up, and the like.

[0028] The portion of memory 228 may be reserved such that the OS layer 202 cannot write to the portion of memory 228. Rather, the portion of memory 228 may be reserved to receive and store the firmware debug information 230 from the firmware layer 204. The firmware debug information 230 may be information related to instructions or code executed by firmware applications 212 in response to calls from applications 208i - 208_n (hereinafter also referred to individually as an application 208 or collectively as applications 208) that are executed in the OS layer 202.

[0029] In one example, the apparatus 200 may also include a system management module (SMM) 206. The SMM 206 may include the firmware applications 212 and a firmware debug driver 210. The SMM 206 may help manage operations of the OS layer 202 and the firmware layer 204 during execution of an application 208 in the OS layer 202. For example, during execution of the application 208i the application 208i may make an API call to firmware layer 204. For example, the application 208i may request set up of certain hardware or devices within the apparatus 200. The API call may be sent to the SMM 206.

[0030] The SMM 206 may pause operation of the OS layer 202 while the firmware layer 204 executes firmware applications 212 in response to the API call. After the firmware applications 212 are completed, the SMM 206 may then pause the firmware layer 204 such that the OS layer 202 may operate. In other words, the SMM 206 may control the OS layer 202 and the firmware layer 204 such that both the OS layer 202 and the firmware layer 204 do not operate at the same time.

[0031] In one example, when debugging is initiated in the OS layer 202, the SMM 206 may also provide the API call to the firmware debug driver 210. The firmware debug driver may record debug output statements associated with instructions or calls executed by the firmware applications 212. The debug output statements may be provided as the firmware debug information 230 to the portion of memory 228.

[0032] In one example, the firmware debug driver 210 may include a timestamp with each instruction or call that is executed in the firmware layer 204 in response to API calls from the applications 208. The timestamps may allow the firmware debug information to be ordered in a time sequence with debug information from the applications 208, as discussed in further details below.

[0033] For example, the debug output statements may be written to the kernel debug support 232 in real-time as they occur. There may be a slight delay when the debug output statements in the firmware debug information 230 are accessed and provided to the kernel debug support 232. As a result, the event log 234 may record the debug output statements from the OS layer 202 and the debug output statements from the firmware layer 204 out of order. The timestamps may allow the debug output statements to be sorted in a time sequence order even if the debug output statements are listed in the event log 234 out of order.

[0034] In one example, the SMM 206 may send a notification to the OS driver 224. For example, after the firmware debug driver 210 writes the firmware debug information 230 to the portion of memory 228, the firmware debug driver 210 may notify the SMM 206. The SMM 206 may send a notification signal to the OS driver 224 and the OS driver 224 may read the firmware debug information 230 in response to the notification signal. In other examples, an interrupt process or a semaphore may be used as well to control access to the portion of memory 228 between the OS driver 224 and the firmware debug driver 210.

[0035] The OS driver 224 may provide the firmware debug information 230 to the kernel debug support 232. As noted above, an API call such as“output debug string” may be used by the applications 208 to write debug information to the kernel debug support 232. The debug information of the applications may include information related to an API call that was made, a direct link library (DLL) file that was called, a particular driver that was called, and the like.

[0036] The OS driver 224 may use a similar API call to write the firmware debug information 230 to the kernel debug support 232. The kernel debug support 232 may combine the debug information from the applications 208 executed in the OS layer 202 and the firmware debug information 230 in an event log 234.

[0037] In one example, the event log 234 may then be provided to a viewer tool 214 to view debugging information. The viewer tool 214 may be a window that displays the event log 234 for debugging the applications 208.

[0038] FIG. 3 illustrates an example window of the viewer tool 214 to view the event log 234. The window may include a graphical user interface (GUI)

302. The window may be displayed as part of a GUI of the OS layer 202 on a display device that is communicatively coupled to the apparatus 100 or 200.

[0039] In one example, the GUI 302 may include a column of events 304 and a column of timestamps 306. It should be noted that the GUI 302 has been simplified for ease of explanation. The GUI 302 may include additional menus, selectable options, sorting buttons, additional columns of information, and the like, that are not shown.

[0040] In one example, the events 302 may include debug output statements 308i-308_m that were recorded from execution of the applications 208 and the firmware debug information 230. The column of timestamps 306 may display a time 310i - 310_m that was recorded for each event 308i - 308_m. As can be seen in the GUI 302, the events 304 include debug output statements 308i ,

308₂, 308₃, 308₄, 308b, 308₇, and 308_m associated with events from execution of the applications 208 as well as debug output statements 308s and 308s from the firmware debug information 230. Thus, the viewer tool 214 may display both debug output statements from applications 208 in the OS layer 202 and the firmware debug information 230 from the firmware layer 204 in a single window 300 in the OS layer 202.

[0041] Although the events 304 are sorted in a time order based on the timestamps 306, it should be noted that the events 304 may be displayed out of time order. For example, there may be a slight delay as the firmware debug information 230 is accessed by the OS driver 224 and provided to the kernel debug support 232. In one example, the viewer tool 214 may include a small memory buffer to account for the delay, sort the events based on the respective times 310i - 310_m associated with each debug output statement 308i - 308_m, and then display the sorted debug output statements 308i - 308_m.

[0042] It should be noted that FIGs. 1 and 2 provide examples of how the firmware debug information 1 10 or 230 can be accessed by the OS. However, it should be noted that other examples may also be used that may be less efficient than the examples described above. For example, rather than using the portion of memory 108 or 228, the OS layer 204 may have a dedicated memory space. For example, the memory 226 may be completely within a system management RAM (SMRAM) that may accessible by the firmware layer 204, but isolated from the OS layer 202.

[0043] In an example, where the memory 226 is within the SMRAM, the SMM 206 may be used to retrieve the firmware debug information 1 10 or 230 from the dedicated memory space in the firmware layer 204 and provide the firmware debug information 1 10 or 230 to the OS driver 104 or 224 or to the kernel debug support 1 12 or 232. For example, the OS driver 224 may make an API call to read the firmware debug information 1 10 from the memory 226.

However, due to the additional number of calls made to the SMM 206, this process may be less efficient or slower than using the portion of memory 108 or 228. [0044] Thus, the present disclosure provides an apparatus that allows the firmware debug information 1 10 or 230 to be combined with the debug information from the applications 208 in the OS layer 202. As a result, the event log 1 14 or 234 may provide a complete view for debugging rather than including gaps where the applications 208 are paused in the OS layer 202 while the firmware layer 204 executes BIOS applications 212. The complete view of the firmware debug information 1 10 or 230 and the debug information from the applications 208 in the OS layer 202 allow for more efficient and accurate debugging.

[0045] Although FIG. 2 illustrates an example implementation that uses the SMM 206, it should be noted that the present disclosure may also be deployed in other system architectures, such as advanced reduced instruction set computing machines (ARM) architectures, hypervisor environments used for virtualization, and the like. For example, the SMM 206 may be substituted with a“TrustZone” feature of the ARM architecture, or the SMM 206 may be substituted with a hypervisor in the hypervisor environment.

[0046] FIG. 4 illustrates an example of an apparatus 400. In an example, the apparatus 400 may be the apparatus 100 and the instructions may be associated with the OS driver 104. In an example, the apparatus 400 may include a processor 402 and a non-transitory computer readable storage medium 404. The non-transitory computer readable storage medium 404 may include instructions 406, 408 and 410 that, when executed by the processor 402, cause the processor 402 execute the functions associated with the OS driver 104.

[0047] In one example, when firmware debug information 1 10 is written to the portion of memory 108, the OS driver 104 may read the firmware debug information 1 10 from the portion of memory 108. In one example, the OS driver 104 may periodically poll the portion of memory 108. For example, every few seconds, minutes, several minutes, and the like, the OS driver 104 may check the portion of memory 108 to see if the portion of memory 108 includes the firmware debug information 1 10.

[0048] In one example, the instructions 406 may include instructions to reserve a portion of memory to store firmware debug information. The firmware debug information may be a list of events, calls, instructions that are executed, and the like, for a firmware layer (e.g., a BIOS) of a computing device.

[0049] In one example, the portion of memory may be reserved in a memory of a system memory, such as a system RAM or other non-volatile computer readable memory. The portion of memory that is reserved may be static or pre determined. In one example, the portion of memory that is reserved may be changed dynamically at boot time when the computing device is powered on. The portion of memory may be reserved such that the OS cannot write to the portion of memory. The portion of memory may be reserved to store the firmware debug information.

[0050] As discussed above, an application in the OS layer may make an API call to the firmware. The API call may be to configure a component or device of the computing device (e.g., change a value or parameter of a setting in a network interface card, a display device, an external peripheral device, and the like). In one example, the API call may be provided to an SMM that controls operation between the OS layer and the firmware layer. The SMM may pause operation of the OS layer while the firmware layer executes the API call. A debug driver in the firmware layer may write the firmware debug information to the portion of memory that is reserved.

[0051] In one example, the instructions 408 may include instructions to access, by an OS driver, the firmware debug information in the portion of memory that is reserved. For example, the OS driver executed in the OS layer may read the firmware debug information from the portion of memory that is reserved.

[0052] In one example, the OS driver may be triggered to access the firmware debug information. For example, the OS driver may be notified, may periodically poll the portion of memory that is reserved, use an interrupt, a semaphore, and the like.

[0053] In one example, the instructions 410 may include instructions to provide the firmware debug information to a kernel debug support to be written into an event log and combined with OS debug error information. In one example, the OS driver may provide the firmware debug information to the kernel debug support. The event log may be provided to a viewer tool for viewing debugging information. The viewer tool may display the event logs that include both the OS debug error information and the firmware debug

information.

[0054] In one example, the firmware debug information may include a timestamp for each event that is recorded. In one example, the kernel debug support may sort the event log (e.g., the firmware debug information and the OS debug information) based on the timestamps to generate a sorted event log.

The sorted event log may be provided to the viewer tool for display.

[0055] In one example, the event log may be provided to the viewer tool with the timestamps, but unsorted. The viewer tool may provide a user interface button or menu option to sort the events based on the timestamps

[0056] FIG. 5 illustrates an example of an apparatus 500. In an example, the apparatus 500 may be the apparatus 100 and the instructions may be associated with the OS driver 104. In an example, the apparatus 500 may include a processor 502 and a non-transitory computer readable storage medium 504. The non-transitory computer readable storage medium 504 may include instructions 506, 508 and 510 that, when executed by the processor 502, cause the processor 502 execute the functions associated with the OS driver 104.

[0057] In an example, the instructions 506 may include instructions to receive a notification that firmware debug information is written to a portion of memory that is reserved. The instructions 508 may include instructions to access the firmware debug information in the portion of memory that is reserved. The instructions 510 may include instructions to provide the firmware debug information to a kernel debug support to be written into an event log and combined with OS debug error information.

[0058] It will be appreciated that variants of the above-disclosed and other features and functions, or alternatives thereof, may be combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

Claims

1. An apparatus, comprising:

a memory, wherein a portion of the memory is reserved to receive firmware debug information;

an operating system (OS) driver to access the firmware debug information in the portion of the memory that is reserved;

a kernel debug support to receive the firmware debug information for an event log; and

a processor to control execution of the OS driver to access the memory and to write the firmware debug information into the event log.

2. The apparatus of claim 1 , further comprising:

a viewer tool to display the event log.

3. The apparatus of claim 1 , wherein the event log includes the firmware debug information and OS debug information.

4. The apparatus of claim 1 , wherein the memory comprises a non-volatile memory of the apparatus.

5. The apparatus of claim 1 , wherein the portion of the memory is reserved at boot time.

6. An apparatus, comprising:

a firmware layer comprising:

a firmware debug driver to write firmware debug information to a reserved portion of memory;

an operating system (OS) layer comprising:

a kernel debug support to generate an event log;

an OS driver to access the reserved portion of memory and obtain the firmware debug information and to provide the firmware debug information to the kernel debug support to be written in the event log; and a memory that comprises the reserved portion of memory that is accessible by the firmware and the OS; and

a processor to control operation of the firmware layer and the OS layer.

7. The apparatus of claim 6, further comprising:

a system management module (SMM) to receive a call from the OS layer to cause the firmware debug driver to be executed.

8. The apparatus of claim 6, wherein the OS layer further comprise an application that is executed in the OS layer, wherein debug information associated with the application is combined with the firmware debug information in the event log.

9. The apparatus of claim 6, wherein the firmware debug information includes a time stamp.

10. A non-transitory computer readable storage medium encoded with instructions executable by a processor, the non-transitory computer-readable storage medium comprising:

instructions to reserve a portion of memory to store firmware debug information;

instructions to access, by an OS driver, the firmware debug information in the portion of memory that is reserved; and

instructions to provide the firmware debug information to a kernel debug support to be written into an event log and combined with OS debug error information.

1 1. The non-transitory computer readable storage medium of claim 10, wherein the instructions to access comprises:

instructions to notify the OS driver that the firmware debug information is written to the portion of memory that is reserved.

12. The non-transitory computer readable storage medium of claim 10, wherein the instructions to access comprises:

instructions to periodically poll the portion of memory that is reserved for the firmware debug information.

13. The non-transitory computer readable storage medium of claim 10, wherein the firmware debug information and the OS debug error information include timestamps.

14. The non-transitory computer readable storage medium of claim 13, further comprising:

instructions to generate a sorted event log by sorting the firmware debug information and the OS debug information based on the timestamps.

15. The non-transitory computer readable storage medium of claim 14, further comprising:

instructions to provide the sorted event log to a viewer tool for viewing debugging information to be displayed.