Firmware Error Logging During System Boot and Shutdown
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current boot and shutdown logging methods in operating systems are inadequate for capturing errors during early system boot and late system shutdown, as the operating system cannot log events before launching or after shutting down, leading to difficulties in identifying hardware initialization and shutdown errors.
Innovation Solution
A firmware interface like UEFI initializes hardware and passes control to the operating system, which includes a logging module that prioritizes and writes error logs to NVRAM before the operating system has full memory access, allowing error logs to persist and be retrieved later for troubleshooting.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the operating system logs errors to a file on disk or network logging service, then logging functionality is provided, but the operating system cannot log events during early boot and late shutdown phases
Solution Approach 1:
The patent implements a logging module that is initialized during early boot phase before the operating system fully loads, allowing error logging to begin before traditional logging mechanisms are available. This preliminary action ensures that errors occurring during critical early system phases are captured, extending the logging time window backward into the boot process.
Solution Approach 2:
The patent introduces a firmware interface (UEFI) as an intermediary between the hardware and the operating system's logging module. This intermediary enables the logging module to access and write error logs to NVRAM during early boot and late shutdown phases when the operating system does not have full control, thereby bridging the gap in logging coverage.
2Reliability
If UEFI variables are used to pass error information from firmware to operating system, then error logging during early boot is enabled, but the limited NVRAM space quickly fills up preventing storage of numerous errors
Solution Approach 1:
The patent changes the storage parameter from traditional disk files to NVRAM for early boot error logs, enabling logging during phases when the operating system is not yet running. This parameter change allows error information to be persisted in a volatile-free memory space that is accessible during firmware execution, though it introduces the constraint of limited space.
Solution Approach 2:
The patent treats NVRAM error logs as temporary, disposable storage that is cleared once the operating system successfully boots and takes over logging. This approach allows the system to use the limited NVRAM space efficiently for its specific purpose (capturing early boot errors) without permanently consuming the space, effectively resetting the storage capacity for subsequent boot cycles.
3Reliability
If the UEFI stops saving data to NVRAM when space is full, then data integrity is maintained, but the ability to pass important troubleshooting information to the operating system is hindered
Solution Approach 1:
The patent implements a feedback mechanism where the logging module monitors NVRAM space availability and dynamically adjusts its logging behavior. When NVRAM is full, the system can prioritize certain error logs, overwrite older less-critical logs, or trigger alerts, ensuring that the most important troubleshooting information is preserved while maintaining data integrity through controlled management of the limited storage resource.
Data Source
AI summary
Systems and methods are described for improved error logging during system boot and shutdown. A hardware initialization firmware on a computing device can include a logging module. When errors occur during early system booting or late system shutdown, the firmware can create error logs. The logging module can receive the error logs and prioritize them according to a set of rules. The logging module can select error logs of the highest priority up to a predetermined maximum amount. The logging module can modify the error logs using a shorthand form and write them to nonvolatile random-access memory. The firmware can initialize runtime services and launch an operating system. A system logger on the operating system can retrieve the error logs, save them to a file, and erase them from the memory.