Live system updates
US-10936300-B1 · Mar 2, 2021 · US
US12164906B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-12164906-B2 |
| Application number | US-202016801382-A |
| Country | US |
| Kind code | B2 |
| Filing date | Feb 26, 2020 |
| Priority date | Feb 26, 2020 |
| Publication date | Dec 10, 2024 |
| Grant date | Dec 10, 2024 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A modular microcode (uCode) patch method to support runtime persistent update and associated apparatus. The method enables BIOS uCode patches to be received during platform runtime operations and written to first and second uCode extension regions as uCode images for a firmware device layout that further includes a uCode base region in which a current uCode image is stored. Following a platform reset, the first and second uCode extension regions are inspected to determine if one or more valid and newer uCode images (than the current uCode image) are present. If so, the newest uCode image is booted rather than the current uCode image. Following a successful boot, the newest uCode image is copied to the uCode base region to sync-up the current uCode image to the newest version. In one aspect, received uCode images are written to the first and second uCode extension regions in an alternating manner to support roll-back.
Opening claim text (preview).
What is claimed is: 1. A method implemented on a compute platform including non-volatile memory in which firmware microcode (uCode) are stored, the non-volatile memory having a layout partitioned into a plurality of regions, including a uCode base region, a first uCode extension region, and a second uCode extension region, the method comprising: during first runtime operations of the compute platform following booting a first uCode image having a first version, receiving a first uCode patch and writing uCode content contained therein to one of the first and second uCode extension regions as a second uCode image having a second version newer than the first version; following a first platform reset, detecting the second uCode image is present in the first or second uCode extension region and has a newer version than the first uCode image; and booting the second uCode image. 2. The method of claim 1 , further comprising: copying the second uCode image into the uCode base region to sync-up a current uCode image in the uCode base region. 3. The method of claim 1 , wherein the compute platform includes an operating system (OS) that is implemented during platform runtime operations, further comprising: during the first runtime operations of the compute platform, receiving an OS uCode runtime patch; and implementing the OS uCode runtime patch during the first runtime operations, wherein the first uCode patch comprises the OS uCode runtime patch. 4. The method of claim 1 , further comprising: during the first runtime operations, receiving a second uCode patch containing a third uCode image having a third version older than the second version, the second uCode patch being received prior to the first uCode patch; writing the third uCode image to one of the first and second uCode extension regions; when the third uCode image is written to the first uCode extension region, writing the second uCode image to the second uCode extension region; otherwise when the third uCode image is written to the second uCode extension region, writing the second uCode image to the first uCode extension region. 5. The method of claim 4 , further comprising: following the first platform reset and prior to booting the second uCode image, detecting presence of the second and third uCode images in the first and second uCode extension regions; and one of, determining the second uCode image has a version that is newer than the version of the third uCode image; or determining the third uCode image is marked as invalid. 6. The method of claim 4 , wherein when the third uCode image is written to the first or second uCode extension region it includes version indicia identifying the uCode image is the third version, and wherein when the second uCode image is written to the first or second uCode extension region it includes version indicia identifying the second uCode image is the second version, the method further comprising: confirming the second uCode image has been successfully written to the first or second uCode extension regions; and marking the version indicia for the third uCode image as invalid. 7. The method of claim 4 , further comprising: in conjunction with or following writing the third uCode image to one of the first and second uCode extension regions, updating a variable or pointer to point to the first or second uCode extension region the third uCode image is not written to; and employing the variable or pointer to identify which of the first and second uCode extensions regions the second uCode image is to be written to. 8. The method of claim 1 , further comprising: receiving a Unified Extensible Firmware Interface (UEFI) uCode capsule package including a UEFI capsule header and a payload containing a uCode firmware volume (FV) comprising the first uCode patch; and writing the uCode FV to the one of the first and second uCode extension regions as the second uCode image. 9. The method of claim 8 , wherein the UEFI uCode capsule package includes authentication information signed with a certificate, further comprising using the authentication information to validate the UEFI uCode capsule package before writing the uCode FV to the one of the first and second uCode extension regions as the second uCode image. 10. A compute platform, comprising: a processor; a memory, coupled to the processor; an operating system (OS), including executable instructions configured to be executed on the processor stored in at least one of a storage device coupled to the processor and the memory; a network interface, operatively coupled to the processor; a non-volatile memory device in which firmware instructions are stored operatively coupled to the processor, the non-volatile memory having a layout partitioned into a plurality of regions, including a microcode (uCode) base region, a first uCode extension region, and a second uCode extension region, wherein execution of the firmware and the OS executable instructions on the processor enables the compute platform to, boot the compute platform using a first uCode image in the uCode base region, the first uCode image having a first version; boot the OS and initiate first runtime operations; during the first runtime operations, receive a first uCode patch and write uCode content contained therein to one of the first and second uCode extension regions as a second uCode image having a second version newer than the first version; following a first platform reset, detect the second uCode image is present in the first or second uCode extension region and has a newer version than the first uCode image; and boot the second uCode image. 11. The compute platform of claim 10 , wherein execution of the firmware instructions on the processor further enables the compute platform to: copy the second uCode image into the uCode base region to sync-up a current uCode image in the uCode base region, wherein at least a portion of uCode in the uCode base region is replaced when the second uCode image is copied into the uCode base region. 12. The compute platform of claim 10 , wherein execution of the firmware instructions and the OS executable instructions on the processor further enables the compute platform to: during the first runtime operations, receive a second uCode patch containing a third uCode image having a third version older than the second version, the second uCode patch being received prior to the first uCode patch; write the third uCode image to one of the first and second uCode extension regions; when the third uCode image is written to the first uCode extension region, writing the second uCode image to the second uCode extension region; otherwise when the third uCode image is written to the second uCode extension region, writing the second uCode image to the first uCode extension region. 13. The compute platform of claim 12 , wherein execution of the firmware instructions on the processor further enables the compute platform to: following the first platform reset and prior to booting the second uCode image, detect presence of the second and third uCode images in the first and second uCode extension regions; and one of, determine the first uCode image has a version that is newer than the version of the second uCode image; or determine the second uCode image is marked as invalid. 14. The compute platform of claim 12 , wherein when the third uCode image is written to the first or second uCode extension region it includes version indicia identifying the uCode image is the third version, wherein when the second uCode image is written to the first or
using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories · CPC title
Secure firmware programming, e.g. of basic input output system [BIOS] · CPC title
Bootstrapping (security arrangements therefor G06F21/57) · CPC title
while running · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.