Abstract: Upon detection of a change in resolution from a first resolution to a second resolution, one or more user interface elements may be dynamically scaled based, at least in part, on the detected change in resolution. The user interface elements may be dynamically scaled in such a way as to maintain an aspect ratio of each of the user interface elements while adjusting a resolution of each of the user interface elements to the second resolution. After the user interface elements are dynamically scaled, a user interface, at the second resolution, may be presented on a display of an information handling system.

Abstract: An antenna assembly includes a tool mandrel having a tool axis; a first coil antenna including a first plurality of windings wrapped about the tool mandrel, wherein the first coil antenna is arranged in a first orientation and wherein portions of the first plurality of windings are wrapped about the tool mandrel at a first winding angle defined with respect to the tool axis; and a second coil antenna co-located with the first coil antenna and including a second plurality of windings wrapped about the tool mandrel, wherein the second coil antenna is arranged in a second orientation opposite the first orientation, wherein portions of the second plurality of windings are wrapped about the tool mandrel at a second winding angle defined with respect to the tool axis and wherein a difference between a loop area of the first coil antenna and a loop area of the second coil antenna is less than 25%.

Abstract: An information handling system may include at least one processor, an information handling resource including a firmware, and a memory having an initial identifier stored therein. The information handling system may receive a first firmware update package specifying the initial identifier, wherein the first firmware update package includes therein an intermediate identifier different from the initial identifier; based on the first firmware update package specifying the initial identifier, update the firmware with contents of the first firmware update package, and update the initial identifier in the memory with the intermediate identifier; receive a second firmware update package specifying the intermediate identifier; and based on the second firmware update package specifying the intermediate identifier, update the firmware with contents of the second firmware update package.

Abstract: Aspects of the subject technology relate to a circuit board mounting assembly for use in a downhole tool. The assembly can include a sleeve comprising a plurality of flaps and a circuit board disposed on the proximal end of the sleeve and secured by the plurality of flaps. The assembly can include a hollow housing comprising a shoulder on an interior surface of the housing at a proximal portion of the housing and a circuit board disposed on the shoulder of the housing. The assembly can further include a groove disposed on the interior surface and a ring disposed within the groove. The assembly can further include a threaded portion on the interior surface extending from a distal end of the housing and a nut threadedly engaged with the threaded portion of the housing.

Abstract: An antenna assembly that includes a bobbin including arcuate first and second bobbin portions positioned about a tool mandrel. A protective layer is formed about the first and second bobbin portions, and a cover occludes a portion of an axially extending gap defined between the first and second bobbin portions to prevent the protective layer from extruding into the gap.

Abstract: A tool that uses antennas to evaluate an environment surrounding a borehole, the tool including an antenna assembly, and the antenna assembly including a body with a longitudinal central axis, and an antenna mounted on the body in a continuous groove comprising a plurality of circumferential portions and a plurality of transition portions, with each of the circumferential portions being formed in a plane and each of the planes being spaced apart from each other and parallel to each other; and with each of the circumferential portions at least partially extending circumferentially around the body within its respective plane and each of the transition portions transitioning the groove from an end of one of the circumferential portions to an end of an adjacent one of the circumferential portions.

Abstract: An information handling system may include at least one processor, a memory coupled to the at least one processor, and an information handling resource including a firmware. The information handling system may be configured to: boot into an operating system stored on the memory; after booting into the operating system, receive, from at least one remote server, information regarding a vulnerability associated with the firmware; based on a security policy, determine a resolution for mitigation of the vulnerability; and store information regarding the resolution in a storage location accessible to a preboot environment of the information handling system, wherein the preboot environment is configured to apply the resolution upon a subsequent boot of the information handling system.

Abstract: A BIOS of an information may transmit information regarding events detected by the BIOS to an OS of an information handling system for logging in an OS event log. A BIOS of an information handling system may detect an event and may log information regarding the event in a memory of an information handling system. An OS of the information handling system may retrieve at least a portion of the information regarding the event from the event log and may add at least a portion of the retrieved information to an OS event viewer.

Abstract: Systems and methods are provided for supporting use of system BIOS components (e.g., such as BIOS debug messages, debugger firmware, UEFI drivers, etc.) that are stored separately from the remainder of system BIOS firmware for an information handling system. The system BIOS components may represent only a portion of the total BIOS firmware, and may be selectively retrieved and loaded from the separate storage into system memory when needed by the system BIOS for operating purposes (e.g., such as debugging operations).

Abstract: The identification and loading of an appropriate service operating system can be facilitated when a main operating system fails. To facilitate the identification of which main operating system failed, an agent can create a UEFI variable that is specific to each main operating system on a client. These OS-specific UEFI variables can be employed to identify which main operating system has failed to boot. When a main operating system fails to boot, a UEFI preboot application can be configured to access the UEFI variables to identify which main operating system has failed. The UEFI preboot application can also obtain characteristics of the failed operating system from the UEFI variable and include such characteristics in a vendor extension of an SLP request. A server can employ the characteristics defined in the vendor extension to identify and send an appropriate service operating system to the client.

Abstract: Systems and methods for providing pre-boot services in an Information Handling System (IHS) having Operating System (OS)-specific hardware and/or firmware components. In some embodiments, an IHS may include an Embedded Controller (EC), a first Operating System (OS)-specific chip coupled to the EC, and a second OS-specific chip coupled to the EC, where the EC is configured to cause the IHS to: in a first mode of operation, perform a first boot procedure using the first OS-specific chip; and in a second mode of operation, perform a second boot procedure using the second OS-specific chip.

Abstract: The identification and loading of an appropriate service operating system can be facilitated when a main operating system fails. To facilitate the identification of which main operating system failed, an agent can create a UEFI variable that is specific to each main operating system on a client. These OS-specific UEFI variables can be employed to identify which main operating system has failed to boot. When a main operating system fails to boot, a UEFI preboot application can be configured to access the UEFI variables to identify which main operating system has failed. The UEFI preboot application can also obtain characteristics of the failed operating system from the UEFI variable and include such characteristics in a vendor extension of an SLP request. A server can employ the characteristics defined in the vendor extension to identify and send an appropriate service operating system to the client.

Abstract: UEFI images can be securely loaded at runtime so that it is unnecessary to flash the entire platform firmware whenever a UEFI image is added or updated. The platform firmware can include an OEM file list that maps file GUIDs to public keys. When it is desired to add a UEFI image, the OEM can employ one of the file GUIDs in the OEM file list and a private key corresponding to the mapped public key to create the UEFI image. During the PEI phase of the boot process, a verification module in the platform firmware can verify any added UEFI image using the OEM file list. Additionally, to ensure that the added UEFI images will pass the subsequent Secure Boot verification, a sync module can add custom Secure Boot keys for the added UEFI images to the Secure Boot databases during the DXE phase of the boot process.

Abstract: Upon detection of a change in resolution from a first resolution to a second resolution, one or more user interface elements may be dynamically scaled based, at least in part, on the detected change in resolution. The user interface elements may be dynamically scaled in such a way as to maintain an aspect ratio of each of the user interface elements while adjusting a resolution of each of the user interface elements to the second resolution. After the user interface elements are dynamically scaled, a user interface, at the second resolution, may be presented on a display of an information handling system.

Abstract: An information handling system may load first data from a location information area of a first memory, specifying a plurality of locations of metadata for a plurality of stages of basic input/output system (BIOS) initialization. The information handling system may then load first metadata for a first stage of BIOS initialization from a first metadata location of the plurality of locations specified by the first data. The first metadata may contain information for indexing first initialization data located at a first initialization data location. The information handling system may then index the first initialization data of the first initialization data location based, at least in part, on the first metadata. The information handling system may then perform the first stage of BIOS initialization based, at least in part, on the first initialization data.

Abstract: A BIOS of an information may transmit information regarding events detected by the BIOS to an OS of an information handling system for logging in an OS event log. A BIOS of an information handling system may detect an event and may log information regarding the event in a memory of an information handling system. An OS of the information handling system may retrieve at least a portion of the information regarding the event from the event log and may add at least a portion of the retrieved information to an OS event viewer.

Abstract: UEFI images can be securely loaded at runtime so that it is unnecessary to flash the entire platform firmware whenever a UEFI image is added or updated. The platform firmware can include an OEM file list that maps file GUIDs to public keys. When it is desired to add a UEFI image, the OEM can employ one of the file GUIDs in the OEM file list and a private key corresponding to the mapped public key to create the UEFI image. During the PEI phase of the boot process, a verification module in the platform firmware can verify any added UEFI image using the OEM file list. Additionally, to ensure that the added UEFI images will pass the subsequent Secure Boot verification, a sync module can add custom Secure Boot keys for the added UEFI images to the Secure Boot databases during the DXE phase of the boot process.

Abstract: An antenna assembly includes a bobbin positionable about an outer surface of a tool mandrel, and a coil wrapped about an outer bobbin surface of the bobbin and extending longitudinally along at least a portion of the outer bobbin surface. A plurality of ferrites are positioned within a groove defined in the outer surface of the tool mandrel, and the plurality of ferrites extend circumferentially about the outer surface and interpose the tool mandrel and the coil.

Abstract: Apparatus, systems, and methods may operate to couple a power supply to a ground point associated with a well, and to a lower portion of a conductive casing disposed within the well, where the lower portion of the conductive casing is separated by an insulating gap from an upper portion of the conductive casing, the upper portion of the conductive casing being at a higher elevation of the first well than the lower portion of the conductive casing. Further activity may include injecting an excitation signal into the lower portion of the conductive casing to induce a magnetic field in a geological formation surrounding the first well. Additional apparatus, systems, and methods are disclosed.

Abstract: Systems and methods to stage firmware capsule package for an external device in a firmware client system. The firmware client system may include a basic input/output system (BIOS) and an operating system (OS). The BIOS may create a virtual device. The OS may download a virtual device driver package associated with the virtual device from an update service. The virtual device driver package may include a first virtual device driver and a first external device firmware. The OS may also install the first virtual device driver of the virtual device driver package, stage the first external device firmware on a storage device, and execute the first virtual device driver. The first virtual device driver may, when a first external device associated with the first external device firmware is available, deliver the first external device firmware to the first external device using an update firmware mechanism.