Boot-Time Hotkey Control for Device-Specific Boot Modes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Information Handling Systems (IHSs) lack efficient mechanisms for booting that allow administrators to selectively trigger different boot modes for various boot devices using hotkeys, particularly in heterogeneous computing platforms, leading to inefficiencies in diagnostic, recovery, and upgrade operations.
Innovation Solution
Incorporating Non-Volatile Random-Access Memory (NVRAM) with boot instructions that enable hotkey-triggered boot modes for different boot devices, including System-on-Chip (SoC) and embedded controllers, allowing administrators to select and boot devices like SoCs and ECs using designated hotkeys, and supporting diagnostic, recovery, and safe modes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a traditional boot sequence is used without hotkey support, then the boot process is simple and fast, but administrators cannot selectively trigger different boot modes for diagnostic and recovery operations
Solution Approach 1:
The system performs preliminary actions by halting the boot sequence at a specific point and loading a key scan driver before the operating system takes control. This allows hotkey detection to occur during the boot process itself, enabling mode selection before the main OS boot completes, thus adding versatility without significantly increasing overall complexity
Solution Approach 2:
A key scan driver acts as an intermediary component between the boot sequence and the operating system. This driver intercepts keyboard input during the boot process, allowing hotkey detection and response without requiring modifications to the core OS or boot firmware, thereby maintaining relative simplicity while enabling new functionality
2Ease of operation
If hotkey detection is implemented during the entire boot process, then administrators can select boot modes, but the boot process becomes slower and more complex
Solution Approach 1:
The key scan driver is loaded and activated only partially - specifically during the window between boot device selection and OS loading. This limited activation period is sufficient to capture hotkey input without extending the overall boot process significantly, as the driver is automatically unloaded once the OS takes control
Solution Approach 2:
The key scan driver is designed to be self-managing during the boot process - it automatically loads when needed, detects hotkeys, triggers the appropriate boot mode, and then unloads itself. This self-service approach minimizes manual intervention and reduces the time the system spends in an extended boot state
3Adaptability or versatility
If multiple boot devices are supported with individual hotkeys, then diagnostic and recovery operations are enhanced, but the system requires more complex driver management
Solution Approach 1:
The boot process is segmented into distinct phases, with the key scan driver active only during the intermediate phase after boot device selection but before OS loading. This segmentation allows different hotkey configurations to be applied to different boot devices without requiring the entire boot process to handle all complexity, as each device can have its own hotkey mappings defined in its boot parameters
Data Source
AI summary
Systems and methods include an Information Handling System (IHS) that is adapted to utilize runtime hotkeys in the selection of boot modes that are supported by the IHS. The IHS is powered and a boot sequence is initiated. Further booting of the IHS is halted upon detecting a selection of a boot device during the boot sequence. One or more hot keys are identified for use in booting the selected boot device. The selection of a hot key that is supported by the boot device is detected. Booting of the IHS is resumed by booting the selected boot device according to a boot mode corresponding to the selected hot keys.