FIRMWARE OVERWRITES USING QUEUES AND POINTERS BACKGROUND [0001] Computing devices often include firmware such as a Basic Input/Output System (BIOS) stored in non-volatile memory. When a computing device is booted, the BIOS may initialize hardware of the computing device and start runtime services that may be used by an operating system or application executed by the computing device. BRIEF DESCRIPTION OF THE FIGURES [0002] FIG.1 is a block diagram of an example non-transitory computer- readable medium with instructions to perform a firmware update or other overwrite with a queue and a completion pointer at a non-volatile storage device. [0003] FIG.2 is a block diagram of the example of FIG.1 where a firmware update or other overwrite is continued after an unexpected interruption during the update. [0004] FIG.3A is a block diagram of the example of FIG.1 where a firmware is restored after an unexpected interruption during an update by generating a restore queue from an update queue. [0005] FIG.3B is a block diagram of the example of FIG.3A when copying the restore queue to the non-volatile storage device. [0006] FIG.4 is a block diagram of an example computing device to perform a firmware overwrite with a queue and a completion pointer at a non-volatile storage device. [0007] FIG.5 is a flowchart of an example method of recovering from an interrupted firmware overwrite. [0008] FIGs.6A and 6B are flowcharts of an example method of recovering from an interrupted firmware overwrite by selectively continuing the update or restoring the update from a backup. DETAILED DESCRIPTION [0009] Device firmware may be updated, restored, or repaired from time to time. Existing firmware code may be overwritten by code obtained from a target firmware that embodies the update, restoration, or repair. It is often the case that a firmware overwrite is performed by copying blocks of code in sequence from a target firmware to a computing device. If an unexpected interruption occurs during the overwrite process, such as by a loss of power, a user may have to restart the overwrite process from the beginning. That is, once the computing device recovers, the user then needs to begin the firmware overwrite process again. This requires user intervention and increases the time it takes to perform the overwrite. In more advanced systems, a computing device is capable of detecting an interruption to the firmware overwrite process and restarting the process if needed. A flag that is set at the start of the overwrite and unset at the end of the overwrite may be used. For example, when the computing device detects that it has restarted (e.g., after a power loss event), the computing device may check the flag to determine whether a firmware overwrite was interrupted. If it is determined that a firmware overwrite was interrupted (i.e., the flag is set), then the computing device may restart the firmware overwrite. This approach may avoid user intervention but may also still cause the overwrite to take an increased amount of time to perform. [0010] As described herein, a queue is used to perform a firmware overwrite. The queue contains segments of code to overwrite. A pointer points to a most recently completed segment. The queue and pointer are maintained in a working memory, such as a Random-Access Memory (RAM). A copy of the queue and pointer are also maintained in non-volatile storage, such as a hard disk drive (HDD), solid-state drive (SDD), or other device that maintains data persistence without external power. As such, if the firmware update, restoration, or repair is interrupted, the queue and pointer may be loaded back into working memory and the overwrite may continue from the last successfully copied segment as identified by the pointer. This may save time, in that the update, restoration, or repair may be continued from where it left off instead of being restarted. The same queue and pointer methodology may be used in different ways in the same larger process. For example, a queue and a pointer may be used for a firmware update and, if the firmware update is interrupted or aborted, a queue and pointer may also be used for a subsequent restoration to the original firmware. [0011] FIG.1 shows an example non-transitory computer-readable medium 100. The medium 100 may be part of a computing device, such as a notebook computer, desktop computer, all-in-one (AIO) computer, tablet computer, smartphone, or similar device. The medium 100 may include a volatile or non- volatile memory, such as an electronic, magnetic, optical, or other physical storage device that encodes instructions. The medium 100 may include, for example, random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), flash memory, an HDD, an SSD, an optical device, or similar. [0012] The non-transitory computer-readable medium 100 includes processor-executable instructions 102 to perform a firmware overwrite using a queue 104 and a completion pointer 106. [0013] The instructions 102 may be executed by a processor such as a microcontroller (e.g., an embedded controller). [0014] Firmware 108 may be stored on a non-volatile memory, such as a flash memory, EEPROM, or similar. [0015] The firmware 108 may include a BIOS to initialize, control, or operate a computing device that contains the medium 100 prior to execution of an operating system (OS) of the computing device. Instructions included within the BIOS may include software, firmware, microcode, or other programming that defines or controls functionality or operation of the BIOS. In some examples, the BIOS may be implemented using instructions, such as platform firmware of a computing device, executable by a processor, such as a central processing unit (CPU) of the computing device. The BIOS may operate or execute prior to the execution of the OS of the computing device. The BIOS may initialize, control, or operate components such as hardware components of a computing device and may load or boot the OS of computing device. [0016] In some examples, a BIOS may provide or establish an interface between hardware devices or platform firmware of the computing device and an OS of the computing device, via which the OS of the computing device may control or operate hardware devices or platform firmware of the computing device. In some examples, a BIOS may implement the Unified Extensible Firmware Interface (UEFI) specification or another specification or standard for initializing, controlling, or operating a computing device. [0017] A firmware overwrite may be a full overwrite that replaces the entire existing firmware 108 or a partial overwrite that replaces a portion of the existing firmware 108. An overwrite may update the firmware 108 with a new version, restore the firmware 108 to a previous version, or repair the existing version of the firmware 108. The firmware 108 includes instructions and may also include data to support those instructions. Instructions and data may be intermingled. The terms firmware, firmware instructions, firmware data, and firmware code are used interchangeably herein. [0018] The instructions 102 may perform a firmware overwrite on the basis of programable segments. A segment may include a predetermined quantity of firmware code. In various examples, a programmable segment may be a sector or a page storing 4 kilobytes (KB) of information. In other examples, a programmable segment may be a block storing 64 KB of data. A block may include data corresponding to 16 contiguous sectors. Hence, an overwrite may target a set of segments in which firmware code has changed, in the case of an update or restoration, or in which firmware code has been corrupted, in the case of a repair. Any suitable number of segments may be overwritten. [0019] A set of segments 110A-E for an overwrite may be determined prior to carrying out the overwrite. This may be done by comparing the existing firmware 108 to a target firmware. Segments of the existing firmware 108 may be compared to segments of a target firmware, which may represent the desired end state of the update, restoration, or repair of the existing firmware 108. For example, a hash of a segment of the existing firmware 108 may be computed and compared to a hash computed for a corresponding segment of the target firmware. A difference in the hashes indicates that the target segment is different from the existing one and the target segment should be overwritten to the corresponding segment in the existing firmware 108. The instructions 102 may identify the set of segments 110A-E to be written or another set of instruction may identify such. For sake of explanation, it is assumed that the set of segments 110A-E is predetermined outside the scope of the instructions 102. In other examples, all segments are overwritten and thus the selection is simplified. [0020] The instructions 102 use working memory 112 to store a queue 104 of the segments 110A-E to be overwritten. The working memory 112 may be RAM or other volatile memory that supports relatively fast access, so that the overwrite may be performed quickly. [0021] The queue 106 may be referred to as an update queue when an update is performed or a restore queue when a restoration is performed. Correspondingly, the segments 110A-E may be referred to as update segments or restore segments. The principle of operation is the same regardless of whether the firmware is being updated, restored, or repaired. Hence, it should be understood that discussion herein concerning any of an update, restoration, or repair applies equally to all of an update, restoration, and repair, unless otherwise mentioned. [0022] The queue 106 may store a segment identifier 114A-E of the firmware 108 for each segment 110A-E as well as the code 116A-E of the target firmware itself. As such, the queue 106 may be a complete rendition of the overwrite to be performed. [0023] A segment identifier 114A-E may be a unique identifier, such as a sequence number (e.g., 0001, 0002, 0003, etc.), that identifies the relative position of a segment in the firmware 108. The segment identifiers 114A-E may be consistent among the existing firmware 108, target firmware, and backup firmware. The completion pointer 106 may be set to the value of the segment identifier 114A-E of the most recently overwritten segment 110A-E of the firmware 108. [0024] The instructions 102 also use the working memory 112 to store a completion pointer 106 in association with the queue 104. The completion pointer 106 indicates the queued segment 110A-E that was most recently completely written to the firmware 108. [0025] After the segments 110A-E have been identified and queued, the instructions copy the queue 104 to a non-volatile storage device 118, such as an HDD, SSD, flash memory, EEPROM, or other persistent storage device that is capable of maintaining data without power input. The copy of the queue 124 includes segments 130A-E that are identical to the segments 110A-E in the working memory 112. A copy of the completion pointer 126 may be associated with the queue 124 in the non-volatile storage device 118. [0026] The copy of the queue 124 at a non-volatile storage device 118 allows for the queue 104 in the working memory 112 to be restored in case of power loss or other unexpected interruption that may cause loss of the queue 104 and pointer 106 in the working memory 112. [0027] The instructions 102 then overwrite the queued segments 110A-E to the firmware 108 by referencing the completion pointer 106 to identify a current segment 110C and copying the current segment 110C from the working memory 112 to the firmware 108. Since the completion pointer 106 identifies a last copied segment 110B, the instructions 102 may select the next segment 110C in the queue 104 as the current segment to copy. [0028] When the copying of the current segment 110C is complete, the instructions 102 modify the completion pointer 106 in the working memory 112 to point to the current segment 110C, thereby maintaining a current record of the last successfully copied segment. The instructions 102 further modify the completion pointer 126 as stored in the non-volatile storage device 118 to point to the current segment 130C, so as to maintain the current state of the firmware overwrite in the non-volatile storage device 118 in case of power loss or other unexpected interruption that affects the working memory 112. [0029] The instructions 102 traverse the queue 104 in sequence to copy the segments 110A-E to the firmware 108. After each segment 110A-E is successfully copied to the firmware 108, the completion pointer 106, 126 is advanced and updated in both the working memory 112 and the non-volatile memory 118. As such, if at any time the working memory 112 loses the queue 104 and/or pointer 106, at most one segment 110A-E may need to be recopied after the interruption is overcome. [0030] With reference to FIG.2, if an unexpected interruption occurs and the queue 104 or completion pointer 106 in the working memory 112 are lost or corrupted, the instructions 102 may recover from the interruption by copying the queue 124 and completion pointer 126 from the non-volatile storage device 118 to the working memory 112. The overwrite may then continue with reference to the queue 124 and pointer 126 in the working memory 112, as discussed above. Continuance of the overwrite includes modifying the pointer 126 in both the working memory 112 and the non-volatile storage device 118 in case of subsequent interruption. [0031] The instructions 102 may detect an incomplete firmware overwrite in various ways. The instructions may execute at boot or start up to allow detection of an incomplete overwrite. For example, a log may be recorded in non-volatile memory to track events, such as initiation of a firmware overwrite and completion of a firmware overwrite. The instructions 102 may write to the log when initiating and competing an overwrite. After an interruption, the instructions 102 may query the log to determine whether a firmware overwrite was interrupted, which may be reflected by the presence of a log entry that indicates a firmware overwrite was started and the absence of a log entry that indicates completion of the firmware overwrite. In other examples, a boot segment of the firmware 108 may indicate that an overwrite is in progress by, for example, the boot segment being modified as part of the overwrite or the boot segment referencing a flag or indicator stored in non-volatile memory and that is modified as part of the overwrite. The instructions 102 may then query the flag or other indicator to determine whether an overwrite was started but not finished. In other examples, the instructions 102 may determine that an overwrite was interrupted by detecting a queue 124 and pointer 126 in the non-volatile storage device 118 with the pointer 126 not yet pointing to the last segment in the queue 124. Hence, the instructions 102 may be aware of an interrupted update and thus continue with the update (or other overwrite) after the interruption. [0032] The instructions 102 may thereby determine that the firmware overwrite was interrupted and, in response, copy the queue 124 and completion pointer 126 from the non-volatile storage device 118 to the working memory 112 and continue with the overwrite as discussed above. [0033] With reference to FIG.3A, in some situations, after an interruption, an overwrite may be aborted instead of continued. For example, a user may wish to stop an update in progress, whether immediately after an interruption or as a user intervention during the update. [0034] When a firmware update is aborted, the instructions 102 may generate a queue 300, which may be termed a restore queue, based on the subset of segments 130A-130C that were successfully copied during the update. The restore queue 300 may be generated with reference to the update queue 124 as stored in the non-volatile storage device 112 since, in many situations, the working memory 112 has lost its copy of the queue 104. [0035] The instructions 102 may use the update queue 124 and completion pointer 126 to identify completed update segments 130A-C that were successfully copied to the firmware 108. The instructions 102 may then select restore segments 302A-C for the restore queue 300 from a firmware backup 304. The restore segments 302A-C include respective backup firmware code 306A-C. The restore segments 302A-C are selected as corresponding to the completed update segments 130A-C, as indicated in the non-volatile memory 118. Segments may correspond when they share the same segment identifier 114A-C. [0036] The instructions 102 thus build a restore queue 300 in working memory 112 on the basis of the segments copied during firmware update before the interruption or intervention. The instructions 102 further copy the restore queue 300 to the non-volatile storage device 118, as shown in FIG.3B, as a copy of the restore queue 320 containing segments 322A-C identical to segments 302A-C. [0037] The instructions 102 then perform overwriting with completion pointer updating, similar to as discussed above with respect to FIG.1. [0038] Specifically, the instructions 102 copy a current restore segment 302C from the working memory 112 to the firmware 108. When the copying is complete, the instructions modify the completion pointer 106, 126 in the working memory 112 and in the non-volatile storage device 118 to point to the current restore segment 302C, 322C. The copying of segments from the restore queue 300 in working memory and modification of the pointer 106, 126 in both the working memory 112 and the non-volatile storage device 118 is repeated for all restore segments in the restore queue 300 to complete the restoration of the firmware. [0039] If an interruption occurs during restoration, then the queue 320 and pointer 126 may be copied from the non-volatile storage device 118 into the working memory 112, so as to continue the restoration from where it left off. [0040] FIG.4 shows an example computing device 400 to perform a firmware overwrite using a queue and completion pointer. The computing device 400 may be a notebook computer, desktop computer, AIO computer, tablet computer, smartphone, or similar device. [0041] The computing device 400 includes firmware 108 (e.g., BIOS), memory 112 (e.g., RAM), a non-volatile storage device 118 (e.g., HDD or SSD), and a processor 402 connected to the firmware 108, memory 112, and non- volatile storage device 118. [0042] The processor 402 may be a microcontroller, such as an embedded controller (EC). The processor 402 may be different from a CPU 404 that executes the firmware 108. [0043] The processor 402 may include non-violative memory to store instructions or may be connected to such a memory. The processor 402 may execute such instructions to implement the firmware overwrite functionality discussed herein. [0044] To overwrite the firmware, the processor 402 first stores a queue 406 in the memory 112. The queue 406 identifies segments 408A-G of the firmware 108 to overwrite. The processor 402 further manipulates a pointer 410 that identifies a most recently overwritten segment 408D of the queue 406. [0045] The processor 402 copies the queue 406 to the non-volatile storage device 118, which stores it as queue 426. [0046] The processor 402 performs the overwrite of the firmware 108 with reference to the queue 406 and the pointer 410, as stored in the memory 112. During the overwrite, the processor 402 copies segments from the queue 410, one after the other, to the firmware 108. Further, the processor 402 updates the pointer 410 and maintains a copy of the pointer 430 in the non-volatile storage device 118. As such, a complete and current copy of the state of the overwrite is maintained in the non-volatile storage device 118. [0047] The processor 402 may write to a log 412 to indicate that a firmware overwrite as started and, when complete, to indicate that the firmware overwrite was completed. The log 412 may include event indicators, such as a firmware update started indicator 414 and a firmware update complete indicator 416. [0048] If the overwrite is interrupted, the processor 402 may detect an interrupted overwrite by referencing the log 412. For example, a start event may be logged and a completion event may not yet be logged. Detection of a start event without a corresponding completion event may indicate that a firmware overwrite has been interrupted. [0049] In response to detection of an interruption of a firmware overwrite, the processor 402 may copy the queue 426 and the pointer 430 from the non- volatile storage device 118 to the memory 112 and continue the overwrite using the memory 112 from the segment identified by the pointer 430. [0050] The processor 402 may automatically continue an interrupted firmware overwrite a number of times until successful or until a number of attempts are unsuccessful. The processor 402 automatically may restore the firmware 108 from a backup firmware 304 in response to a number of failed attempts to perform an update. For example, the processor 402 may restore the firmware 108 in response to an interruption in a first attempt to update the firmware. In another example, the processor 402, in response to an interruption, may make one attempt to continue an interrupted update, and then restore the firmware 108 in response to a second interruption during the attempt to continue the update. Attempts to continue an interrupted update and restoration of a backup firmware may be performed automatically without user intervention. [0051] In some examples, the computing device 400 includes a user interface device 418 to output information to a user and receive input from the user. Examples of user interface devices include a display device, keyboard, mouse, speaker, microphone, touchscreen, and the like. The user interface device 418 provides a user interface, such as a graphical user interface (GUI), between the user and the computing device 400. [0052] The processor 402 may output a user interface 420 in response to detection of an interruption to a firmware overwrite. If the overwrite is a firmware update, the user interface 420 may provide a choice to continue with the update or abort the update and restore a firmware backup. The user interface 420 may present the choice as a dialog box that allows the user to respond with a mouse to click a selection to continue with the update or restore the backup. [0053] In a firmware update is aborted, the processor 402 may perform a subsequent overwrite to restore from a firmware backup 304 by selecting those segments of the firmware identified by the queue 406 and the pointer 410 as having been overwritten during the firmware update. Hence, only those segments overwritten as part of the update are restored from the backup 304. [0054] FIG.5 shows an example method 500 of recovering from an interrupted firmware overwrite. The method 500 may be implemented by processor-executable instructions that may be stored on a non-transitory computer-readable medium. [0055] At block 502, a first queue of segments of updated firmware code is generated. The particular segments may be selected based on a comparison of segments of an existing firmware and segments of a target firmware. Any segments in the target firmware that differ from the existing firmware, e.g., by having different hashes, may be added to the queue. Each segment may include code for the firmware and a unique segment identifier that identifies a position for the code in the firmware. A comparison of segments in the existing firmware and the target firmware may be made for segments having the same unique segment identifier. The first queue once generated is used perform a firmware update. [0056] At block 504, the first queue is maintained in volatile memory that acts as working memory. The volatile memory may be RAM that allows for fast access and thus a fast update to the firmware. [0057] At block 506, a copy of the first queue is maintained in non-volatile memory that acts as persistent backup in case of power loss or other failure of the volatile memory. The non-volatile memory may be a HDD, SSD, or similar device that allows for storage of information in the absence of power. [0058] At block 508, the firmware update is performed according to the first queue as stored in the volatile memory. A segment is copied from the volatile memory to overwrite the corresponding segment of the firmware. A pointer is used to indicate the last segment copied. [0059] At block 510, the pointer to the most recently copied segment (i.e., from block 508) of the first queue is updated. The pointer is maintained in the volatile memory and the non-volatile memory. [0060] Blocks 508 and 510 are performed for the segments in the first queue to update the firmware. However, the update may experience an unexpected interruption such as loss of the first queue from the volatile memory caused by loss of power to the volatile memory. [0061] If the first queue is lost from the volatile memory then in response, via block 512, the first queue and the pointer are copied from the non-volatile memory to the volatile memory, at block 514. This may occur after power is restored to the volatile memory, such as after the computing device is turned on or rebooted. [0062] Subsequently, via block 516, the firmware update is continued using the volatile memory from the segment indicated by the pointer until the update is complete. [0063] FIGs.6A and 6B show an example method 600 of recovering from an interrupted firmware overwrite by selectively continuing the update or restoring the update from a backup. The method 600 may be implemented by processor- executable instructions that may be stored on a non-transitory computer- readable medium. [0064] The method 600 proceeds with an update in steps 502-510 as discussed above. If no unexpected interruption occurs, the firmware is updated segment by segment until complete, via blocks 512 and 516. [0065] If an unexpected interruption occurs, via block 512, it is determined whether the update should be continued or aborted, at block 602. The determination may depend on the number of interruptions that have occurred. The determination may be automatic or may prompt for user input. For example, if this is the first interruption, then block 602 may automatically determine that the update should be continued once the interruption is over and the queue has been recovered from non-volatile memory, via block 514. If this in the second interruption, then block 602 may prompt the user to continue with the update or restore the firmware to the existing version. The user may then choose to continue with the update, via block 514, or begin a restoration. Block 602 may implement any suitable automatic and/or user prompted determination of whether the update should continue or whether the update should be rolled back and the previous firmware be restored. [0066] If it is determined at block 602 that the update is to be aborted, then a second queue of segments of backup firmware code is generated, at block 604. The second queue contains segments of the backup firmware that correspond to those segments that were updated prior to the update being canceled. The first queue and pointer may be referenced to identify the corresponding segments from the backup for the second queue. [0067] At block 606, the second queue is maintained in the volatile memory. [0068] At block 608, a copy of the second queue is maintained in the non- volatile memory. [0069] At block 610, the firmware restoration is performed according to the second queue as stored in the volatile memory. A segment is copied from the volatile memory to overwrite the corresponding segment of the firmware. A pointer is used to indicate the last segment copied. [0070] At block 612, the pointer is updated to point to the most recently copied segment (i.e., from block 610) of the second queue. The pointer is maintained in the volatile memory and the non-volatile memory. [0071] Blocks 610 and 612 are performed for the segments in the second queue to restore the firmware. However, similar to updating, restoration may experience an unexpected interruption. [0072] If the second queue is lost then in response, via block 614, the second queue and the pointer are copied from the non-volatile memory to the volatile memory, at block 616. Block 614 may automatically continue with the restoration in case of interruption or may query a user as to whether the restoration should be continued or aborted. [0073] Subsequently, via block 618, the firmware restoration is continued using the volatile memory from the segment indicated by the pointer until the restoration is complete. [0074] In view of the above, it should be apparent that firmware my be overwritten with contingency for unexpected interruption. An update may be performed and, if interrupted, the update may be continued or abandoned, in which case a restoration may be performed. An overwrite may be performed on the basis a queue that contains segments of firmware code, and the queue and its segment completion pointer may be copied to non-volatile memory to recover from an interruption. [0075] It should be recognized that features and aspects of the various examples provided above can be combined into further examples that also fall within the scope of the present disclosure. In addition, the figures are not to scale and may have size and shape exaggerated for illustrative purposes.