US20160103747A1 - Post (power-on-self-test) debugging method and apparatuses using the same - Google Patents
Post (power-on-self-test) debugging method and apparatuses using the same Download PDFInfo
- Publication number
- US20160103747A1 US20160103747A1 US14/587,672 US201414587672A US2016103747A1 US 20160103747 A1 US20160103747 A1 US 20160103747A1 US 201414587672 A US201414587672 A US 201414587672A US 2016103747 A1 US2016103747 A1 US 2016103747A1
- Authority
- US
- United States
- Prior art keywords
- driver
- guid
- phase
- phase number
- volatile memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 238000012360 testing method Methods 0.000 title claims abstract description 9
- 238000012545 processing Methods 0.000 claims abstract description 43
- 238000004891 communication Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 101100309719 Arabidopsis thaliana SD31 gene Proteins 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 239000010409 thin film Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2284—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by power-on test, e.g. power-on self test [POST]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
-
- G06F2011/2278—
Definitions
- the present disclosure relates to debugging technology, and in particular, to POST debugging method and apparatuses using the same.
- a POST power-on self-test
- BIOS Basic Input Output System
- chipset manufacturer a chipset manufacturer
- OEM OEM
- check points are inserted in the drivers by these vendors.
- identification numbers of drivers provided by different vendors may be redundant, leading to a misunderstanding of the interrupted firmware when a check point is reached.
- An embodiment of the present disclosure introduces a method for debugging in a POST (power-On-Self-Test), executed by a processing unit, which contains at least the following steps.
- a phase number is set to indicate that a phase of the POST has been entered.
- a driver is selected from a scheduled queue.
- a GUID Globally Unique Identifier
- the phase number or the GUID is stored or output, thereby enabling to recognize that the driver of the phase is interrupted when a break point of the driver is to be reached. After that, the driver is executed.
- An embodiment of the present disclosure introduces a POST debugging apparatus, which contains at least a volatile memory and a processing unit.
- the processing unit contains a cache and is coupled to the volatile memory.
- the processing unit sets a phase number to indicate that a phase of the POST has been entered; selects a driver from a scheduled queue; obtains a GUID of the driver; and stores or outputs the phase number or the GUID, thereby enabling to recognize that the driver of the phase is interrupted when a break point of the driver is to be reached. After that, the processing unit executes the driver.
- FIG. 1 is the system architecture of a computer apparatus according to an embodiment of the present disclosure
- FIG. 2 is a schematic diagram illustrating a POST (power-on self-test) according to an embodiment of the present disclosure
- FIG. 3 is a flowchart illustrating a method for debugging in a POST according to an embodiment of the present disclosure
- FIG. 4 is a schematic diagram illustrating the storage of core dispatchers according to an embodiment of the present disclosure.
- FIG. 5 is a schematic diagram illustrating the storage of phase numbers and GUIDs of drivers according to an embodiment of the present disclosure.
- FIG. 1 is the system architecture of a computer apparatus according to an embodiment of the present disclosure.
- the system architecture may be practiced in a desktop computer, a notebook computer, a tablet computer, a mobile phone or another electronic apparatus, at least including a processing unit 110 .
- the processing unit 110 can be implemented in numerous ways, such as with dedicated hardware, or with general-purpose hardware (e.g., a single processor, multiple processors or graphics processing units capable of parallel computations, or others) that is programmed using microcode or software instructions to perform the functions recited herein.
- the system architecture further includes a non-volatile memory 140 , such as a ROM (Read Only Memory), a EPROM (Erasable Programmable Read Only Memory), a NVRAM (Non-Volatile Random Access Memory), etc., for storing firmware routines executed for hardware in a POST, which are provided by different vendors; a volatile memory 150 , such as a DRAM (Dynamic Random Access Memory), for storing necessary data in execution, such as variables, data tables, or others, and a register 170 for storing GUIDs (Globally Unique Identifiers) associated with the currently executed driver and the last executed driver.
- a non-volatile memory 140 such as a ROM (Read Only Memory), a EPROM (Erasable Programmable Read Only Memory), a NVRAM (Non-Volatile Random Access Memory), etc.
- firmware routines executed for hardware in a POST which are provided by different vendors
- a volatile memory 150 such as a DRAM (Dynamic Random Access Memory),
- the system architecture further includes a connection interface 160 , thereby enabling the processing unit 110 to communicate with another electronic apparatus.
- the connection interface 160 may be a USB (Universal Serial Bus) interface, a COM (Communication) interface, or others.
- the system architecture further includes one or more input devices 130 to receive user input, such as a keyboard, a mouse, a touch panel, or others. A user may press hard keys on the keyboard to input characters, control a mouse pointer on a display by operating the mouse, or control an executed application with one or more gestures made on the touch panel.
- the gestures include, but are not limited to, a single-click, a double-click, a single-finger drag, and a multiple finger drag.
- a display unit 120 such as a TFT-LCD (Thin film transistor liquid-crystal display) panel, an OLED (Organic Light-Emitting Diode) panel, or another display unit, may also be included to display input letters, alphanumeric characters and symbols, dragged paths, drawings, or screens provided by an application for a user to view.
- TFT-LCD Thin film transistor liquid-crystal display
- OLED Organic Light-Emitting Diode
- FIG. 2 is a schematic diagram illustrating a POST (power-on self-test) according to an embodiment of the present disclosure.
- the POST contains at least three phases: a SEC (SECurity) phase P 21 ; a PEI (PreExtensible-firmware-interface Initialization) phase P 23 ; and a DXE (Driver Execution Environment) phase P 25 .
- SEC SECurity
- PEI PreExtensible-firmware-interface Initialization
- DXE Driver Execution Environment
- These three phases are referred to as a platform initialization collectively, and in each phase, a particular core dispatcher is used to coordinate with all hardware initializations.
- the processing unit 110 loads and executes the core dispatcher 210 of this phase.
- the processing unit 210 when executing the core dispatcher 210 , selects a driver from a scheduled queue and stores it in a cache (not shown) of the processing unit 210 or the volatile memory 150 , such as one of the drivers 230 _ 1 to 230 _n, where n is an integer greater than 0 (the operation is also referred to as loading a driver).
- Each driver has a GUID.
- GUIDs are unique reference numbers used as identifiers of the drivers 230 _ 1 to 230 _n.
- GUIDs may be stored as 128-bit values, and displayed as 32 hexadecimal digits with groups separated by hyphens, such as ⁇ 21EC2020-3AEA-4069-A2DD-08002B30309D ⁇ .
- the processing unit 110 After loading a driver, the processing unit 110 further calls and executes a callback record handle 250 .
- the processing unit 110 may store or output this phase number and the GUID of this driver.
- the processing unit 110 may store this phase number and the GUID of this driver in the non-volatile memory 140 .
- the processing unit 110 may store this phase number and the GUID of this driver in a register of port 80 , enabling the phase number and the GUID of the driver to be displayed in the display unit 120 .
- the processing unit 110 may store this phase number and the GUID of this driver in a register of the connection interface 160 , enabling the phase number and the GUID of the driver to be output to another electronic apparatus.
- the processing unit 110 After executing the callback record handle 250 , the processing unit 110 starts to fetch and execute the stored instructions of the driver to finish an initialization for specific hardware. Next, the processing unit 110 repeatedly executes the core dispatcher 210 to load the next driver from the scheduled queue, call and execute the callback record handle 250 , and execute the loaded driver until all drivers of this phase are executed completely. It should be noted that, when any break point is reached, a user may recognize which driver of a particular phase breaks by viewing information of the display unit 120 , obtaining the updated output phase number and GUID via the connection interface 160 or reading the updated phase number and GUID from the volatile memory 150 .
- FIG. 3 is a flowchart illustrating a POST debugging method according to an embodiment of the present disclosure.
- the method is performed when the processing unit 110 loads and executes relevant firmware routines.
- the process repeatedly loads and executes a core dispatcher of a (the next) phase until the whole platform is initialized completely (step S 311 ), and under the control of the core-dispatcher, completes necessary hardware initialization tasks of this phase (steps SD 31 to S 371 ).
- FIG. 4 is a schematic diagram illustrating the storage of core dispatchers according to an embodiment of the present disclosure.
- the non-volatile memory 140 stores three core dispatchers 210 _ 1 to 210 _ 3 when being executed by the processing unit 110 to manage relevant hardware initialization in the SEC phase P 21 , the PEI phase P 23 and the DXE phase P 25 , respectively. Under the control of the designated core dispatcher, the processing unit 110 first sets a phase number (step S 331 ).
- the processing unit 110 when the core dispatcher 210 _ 1 is executed, the variable “Progress Code” is set to “01” to indicate that the SEC phase P 21 has been entered; when the core dispatcher 210 _ 2 is executed, the variable “Progress Code” is set to “02” to indicate that the PEI phase P 23 has been entered; and when the core dispatcher 210 _ 3 is executed, the variable “Progress Code” is set to “03” to indicate that the DXE phase P 21 has been entered. Then, the processing unit 110 repeatedly performs a loop (steps S 333 to S 371 ) until all relevant hardware initialization of this phase is complete.
- the processing unit 110 selects a driver from the scheduled queue and stores the selected driver in a cache (not shown) of the processing unit 110 or the volatile memory 150 (step S 333 ), obtains the GUID of this driver (step S 335 ), calls and executes the callback record module 250 (step S 337 ), executes the driver stored in the cache (not shown) or the volatile memory 150 (step S 339 ) and determines whether all drivers of this phase have been executed (step S 351 ). If so, the process proceeds to the next determination (step S 371 ); otherwise, the process continues to select the next driver from the scheduled queue to do the subsequent process (step S 333 ).
- step S 333 when the cache of the processing unit 110 has been initialized but the volatile memory 150 has not been initialized, the driver may be stored in the cache of the processing unit 110 . Alternatively, when the volatile memory 150 has been initialized, the driver may be stored in the volatile memory 150 .
- step S 337 when the callback record module 250 is executed, the processing unit 110 may store or output the phase number and the GUID of this driver. It should be noted that, after the callback record module 250 is executed completely, the execution control is returned to the core dispatcher to continue the operation of step S 339 . In step S 339 , after the driver is executed completely, the execution control is returned to the core dispatcher to continue the determination of step S 351 .
- step S 351 After all drivers of this phase are executed completely (the “Yes” path of step S 351 ), it is determined whether the whole platform initialization is complete, that is, whether the aforementioned three phases P 21 , P 23 and P 25 are completed (step S 371 ). If so, the processing unit 110 performs the OS (Operating System) boot (step S 391 ); otherwise, the processing unit 110 loads and executes the core dispatcher of the next phase to continue hardware initialization of the next phase (step S 311 ).
- OS Operating System
- the core dispatcher is re-executed.
- the processing unit 110 stores a phase number and a GUID of this driver in the non-volatile memory 140 .
- the re-executed core dispatcher may overwrite the phase number and the GUID of the driver, which are stored before the interruption, with the newly obtained phase number and the GUID of the currently executed driver.
- the reboot procedure may contain a step for duplicating the phase number and the GUID of the driver, which are stored before an interruption, in a new location of the non-volatile memory 140 .
- FIG. 5 is a schematic diagram illustrating the storage of phase numbers and GUIDs of drivers according to an embodiment of the present disclosure.
- a region 510 a of the non-volatile memory 140 stores the newly obtained phase number and a region 510 b of the non-volatile memory 140 stores the newly obtained GUID representing a driver.
- the processing unit 110 duplicates the values of the regions 510 a and 510 b of the non-volatile memory 140 (that is, the phase number and the GUID representing a driver, which are stored before an interruption) in the regions 530 a and 530 b of the non-volatile memory 140 .
- FIG. 3 includes a number of operations that appear to occur in a specific order, it should be apparent that these processes can include more or fewer operations, which can be executed serially or in parallel (e.g., using parallel processors or a multi-threading environment).
Abstract
Description
- This Application claims priority of Taiwan Patent Application No. 103135170, filed on Oct. 9, 2014, the entirety of which is incorporated by reference herein.
- 1. Technical Field
- The present disclosure relates to debugging technology, and in particular, to POST debugging method and apparatuses using the same.
- 2. Description of the Related Art
- A POST (power-on self-test) is a process performed by firmware or software routines immediately after a computer apparatus is powered on. The results of tests run by the POST may be displayed on a panel that is part of the computer apparatus, output to an external device, or stored for future retrieval by a diagnostic tool. Typically, drivers executed in the POST for hardware initiation are provided by different vendors, such as a BIOS (Basic Input Output System) manufacturer, a chipset manufacturer, an OEM (Original Equipment Manufacturer), etc., and check points are inserted in the drivers by these vendors. However, identification numbers of drivers provided by different vendors may be redundant, leading to a misunderstanding of the interrupted firmware when a check point is reached. Thus, it is desirable to have a POST debugging method and apparatuses using the same to address the aforementioned drawbacks.
- An embodiment of the present disclosure introduces a method for debugging in a POST (power-On-Self-Test), executed by a processing unit, which contains at least the following steps. A phase number is set to indicate that a phase of the POST has been entered. A driver is selected from a scheduled queue. A GUID (Globally Unique Identifier) of the driver is obtained. The phase number or the GUID is stored or output, thereby enabling to recognize that the driver of the phase is interrupted when a break point of the driver is to be reached. After that, the driver is executed.
- An embodiment of the present disclosure introduces a POST debugging apparatus, which contains at least a volatile memory and a processing unit. The processing unit contains a cache and is coupled to the volatile memory. The processing unit sets a phase number to indicate that a phase of the POST has been entered; selects a driver from a scheduled queue; obtains a GUID of the driver; and stores or outputs the phase number or the GUID, thereby enabling to recognize that the driver of the phase is interrupted when a break point of the driver is to be reached. After that, the processing unit executes the driver.
- A detailed description is given in the following embodiments with reference to the accompanying drawings.
- The present disclosure can be fully understood by reading the subsequent detailed description and examples with references made to the accompanying drawings, wherein:
-
FIG. 1 is the system architecture of a computer apparatus according to an embodiment of the present disclosure; -
FIG. 2 is a schematic diagram illustrating a POST (power-on self-test) according to an embodiment of the present disclosure; -
FIG. 3 is a flowchart illustrating a method for debugging in a POST according to an embodiment of the present disclosure; -
FIG. 4 is a schematic diagram illustrating the storage of core dispatchers according to an embodiment of the present disclosure; and -
FIG. 5 is a schematic diagram illustrating the storage of phase numbers and GUIDs of drivers according to an embodiment of the present disclosure. - The following description is of the best-contemplated mode of carrying out the present disclosure. This description is made for the purpose of illustrating the general principles of the present disclosure and should not be taken in a limiting sense. The scope of the present disclosure is best determined by reference to the appended claims.
- The present disclosure will be described with respect to particular embodiments and with reference to certain drawings, but the present disclosure is not limited thereto and is only limited by the claims. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
- Use of ordinal terms such as “first”, “second”, “third”, etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having the same name (but for use of the ordinal term) to distinguish the claim elements.
-
FIG. 1 is the system architecture of a computer apparatus according to an embodiment of the present disclosure. The system architecture may be practiced in a desktop computer, a notebook computer, a tablet computer, a mobile phone or another electronic apparatus, at least including aprocessing unit 110. Theprocessing unit 110 can be implemented in numerous ways, such as with dedicated hardware, or with general-purpose hardware (e.g., a single processor, multiple processors or graphics processing units capable of parallel computations, or others) that is programmed using microcode or software instructions to perform the functions recited herein. The system architecture further includes anon-volatile memory 140, such as a ROM (Read Only Memory), a EPROM (Erasable Programmable Read Only Memory), a NVRAM (Non-Volatile Random Access Memory), etc., for storing firmware routines executed for hardware in a POST, which are provided by different vendors; avolatile memory 150, such as a DRAM (Dynamic Random Access Memory), for storing necessary data in execution, such as variables, data tables, or others, and a register 170 for storing GUIDs (Globally Unique Identifiers) associated with the currently executed driver and the last executed driver. It should be understood that thenon-volatile memory 140 and/or the register 170 may be integrated into theprocessing unit 110, and the present disclosure should not be limited thereto. The system architecture further includes aconnection interface 160, thereby enabling theprocessing unit 110 to communicate with another electronic apparatus. Theconnection interface 160 may be a USB (Universal Serial Bus) interface, a COM (Communication) interface, or others. The system architecture further includes one ormore input devices 130 to receive user input, such as a keyboard, a mouse, a touch panel, or others. A user may press hard keys on the keyboard to input characters, control a mouse pointer on a display by operating the mouse, or control an executed application with one or more gestures made on the touch panel. The gestures include, but are not limited to, a single-click, a double-click, a single-finger drag, and a multiple finger drag. Adisplay unit 120, such as a TFT-LCD (Thin film transistor liquid-crystal display) panel, an OLED (Organic Light-Emitting Diode) panel, or another display unit, may also be included to display input letters, alphanumeric characters and symbols, dragged paths, drawings, or screens provided by an application for a user to view. -
FIG. 2 is a schematic diagram illustrating a POST (power-on self-test) according to an embodiment of the present disclosure. The POST contains at least three phases: a SEC (SECurity) phase P21; a PEI (PreExtensible-firmware-interface Initialization) phase P23; and a DXE (Driver Execution Environment) phase P25. These three phases are referred to as a platform initialization collectively, and in each phase, a particular core dispatcher is used to coordinate with all hardware initializations. At the beginning of each phase, theprocessing unit 110 loads and executes thecore dispatcher 210 of this phase. Theprocessing unit 210, when executing thecore dispatcher 210, selects a driver from a scheduled queue and stores it in a cache (not shown) of theprocessing unit 210 or thevolatile memory 150, such as one of the drivers 230_1 to 230_n, where n is an integer greater than 0 (the operation is also referred to as loading a driver). Each driver has a GUID. GUIDs are unique reference numbers used as identifiers of the drivers 230_1 to 230_n. GUIDs may be stored as 128-bit values, and displayed as 32 hexadecimal digits with groups separated by hyphens, such as {21EC2020-3AEA-4069-A2DD-08002B30309D}. After loading a driver, theprocessing unit 110 further calls and executes acallback record handle 250. When executing thecallback record handle 250, theprocessing unit 110 may store or output this phase number and the GUID of this driver. In an example, theprocessing unit 110 may store this phase number and the GUID of this driver in thenon-volatile memory 140. In another example, theprocessing unit 110 may store this phase number and the GUID of this driver in a register of port 80, enabling the phase number and the GUID of the driver to be displayed in thedisplay unit 120. In still another example, theprocessing unit 110 may store this phase number and the GUID of this driver in a register of theconnection interface 160, enabling the phase number and the GUID of the driver to be output to another electronic apparatus. After executing thecallback record handle 250, theprocessing unit 110 starts to fetch and execute the stored instructions of the driver to finish an initialization for specific hardware. Next, theprocessing unit 110 repeatedly executes thecore dispatcher 210 to load the next driver from the scheduled queue, call and execute thecallback record handle 250, and execute the loaded driver until all drivers of this phase are executed completely. It should be noted that, when any break point is reached, a user may recognize which driver of a particular phase breaks by viewing information of thedisplay unit 120, obtaining the updated output phase number and GUID via theconnection interface 160 or reading the updated phase number and GUID from thevolatile memory 150. -
FIG. 3 is a flowchart illustrating a POST debugging method according to an embodiment of the present disclosure. The method is performed when theprocessing unit 110 loads and executes relevant firmware routines. The process repeatedly loads and executes a core dispatcher of a (the next) phase until the whole platform is initialized completely (step S311), and under the control of the core-dispatcher, completes necessary hardware initialization tasks of this phase (steps SD31 to S371).FIG. 4 is a schematic diagram illustrating the storage of core dispatchers according to an embodiment of the present disclosure. Thenon-volatile memory 140 stores three core dispatchers 210_1 to 210_3 when being executed by theprocessing unit 110 to manage relevant hardware initialization in the SEC phase P21, the PEI phase P23 and the DXE phase P25, respectively. Under the control of the designated core dispatcher, theprocessing unit 110 first sets a phase number (step S331). For example, when the core dispatcher 210_1 is executed, the variable “Progress Code” is set to “01” to indicate that the SEC phase P21 has been entered; when the core dispatcher 210_2 is executed, the variable “Progress Code” is set to “02” to indicate that the PEI phase P23 has been entered; and when the core dispatcher 210_3 is executed, the variable “Progress Code” is set to “03” to indicate that the DXE phase P21 has been entered. Then, theprocessing unit 110 repeatedly performs a loop (steps S333 to S371) until all relevant hardware initialization of this phase is complete. Specifically, theprocessing unit 110 selects a driver from the scheduled queue and stores the selected driver in a cache (not shown) of theprocessing unit 110 or the volatile memory 150 (step S333), obtains the GUID of this driver (step S335), calls and executes the callback record module 250 (step S337), executes the driver stored in the cache (not shown) or the volatile memory 150 (step S339) and determines whether all drivers of this phase have been executed (step S351). If so, the process proceeds to the next determination (step S371); otherwise, the process continues to select the next driver from the scheduled queue to do the subsequent process (step S333). In step S333, when the cache of theprocessing unit 110 has been initialized but thevolatile memory 150 has not been initialized, the driver may be stored in the cache of theprocessing unit 110. Alternatively, when thevolatile memory 150 has been initialized, the driver may be stored in thevolatile memory 150. In step S337, when thecallback record module 250 is executed, theprocessing unit 110 may store or output the phase number and the GUID of this driver. It should be noted that, after thecallback record module 250 is executed completely, the execution control is returned to the core dispatcher to continue the operation of step S339. In step S339, after the driver is executed completely, the execution control is returned to the core dispatcher to continue the determination of step S351. - After all drivers of this phase are executed completely (the “Yes” path of step S351), it is determined whether the whole platform initialization is complete, that is, whether the aforementioned three phases P21, P23 and P25 are completed (step S371). If so, the
processing unit 110 performs the OS (Operating System) boot (step S391); otherwise, theprocessing unit 110 loads and executes the core dispatcher of the next phase to continue hardware initialization of the next phase (step S311). - After the break point of a driver is reached, the user may reboot the whole system, therefore, the core dispatcher is re-executed. Before the driver is interrupted, in step S337, the
processing unit 110 stores a phase number and a GUID of this driver in thenon-volatile memory 140. The re-executed core dispatcher may overwrite the phase number and the GUID of the driver, which are stored before the interruption, with the newly obtained phase number and the GUID of the currently executed driver. In order to avoid the aforementioned problem, the reboot procedure may contain a step for duplicating the phase number and the GUID of the driver, which are stored before an interruption, in a new location of thenon-volatile memory 140.FIG. 5 is a schematic diagram illustrating the storage of phase numbers and GUIDs of drivers according to an embodiment of the present disclosure. Aregion 510 a of thenon-volatile memory 140 stores the newly obtained phase number and a region 510 b of thenon-volatile memory 140 stores the newly obtained GUID representing a driver. When the reboot procedure is executed, theprocessing unit 110 duplicates the values of theregions 510 a and 510 b of the non-volatile memory 140 (that is, the phase number and the GUID representing a driver, which are stored before an interruption) in theregions non-volatile memory 140. - Although the embodiment has been described as having specific elements in
FIG. 1 , it is noted that additional elements may be included to achieve better performance without departing from the spirit of the present disclosure. While the process flow described inFIG. 3 includes a number of operations that appear to occur in a specific order, it should be apparent that these processes can include more or fewer operations, which can be executed serially or in parallel (e.g., using parallel processors or a multi-threading environment). - While the present disclosure has been described by way of example and in terms of the preferred embodiments, it should be understood that the present disclosure is not limited to the disclosed embodiments. On the contrary, it is intended to cover various modifications and similar arrangements (as would be apparent to those skilled in the art). Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
Claims (18)
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
TW103135170A TWI599876B (en) | 2014-10-09 | 2014-10-09 | Methods for debugging in a post (power-on self-test) and apparatuses using the same |
TW103135170 | 2014-10-09 | ||
TW103135170A | 2014-10-09 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160103747A1 true US20160103747A1 (en) | 2016-04-14 |
US9465707B2 US9465707B2 (en) | 2016-10-11 |
Family
ID=55655531
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/587,672 Active 2035-03-21 US9465707B2 (en) | 2014-10-09 | 2014-12-31 | POST (power-on-self-test) debugging method and apparatuses using the same |
Country Status (3)
Country | Link |
---|---|
US (1) | US9465707B2 (en) |
CN (1) | CN105487956B (en) |
TW (1) | TWI599876B (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106293620A (en) * | 2016-08-09 | 2017-01-04 | 浪潮电子信息产业股份有限公司 | The method of parameter in intel detection of platform Flash Rom |
CN109597787A (en) * | 2018-12-10 | 2019-04-09 | 浪潮(北京)电子信息产业有限公司 | SIO UART configuration method, system, device and readable storage medium storing program for executing |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160253501A1 (en) * | 2015-02-26 | 2016-09-01 | Dell Products, Lp | Method for Detecting a Unified Extensible Firmware Interface Protocol Reload Attack and System Therefor |
US11163643B2 (en) * | 2017-04-13 | 2021-11-02 | Hewlett-Packard Development Company, L.P. | Boot data validity |
CN109508263B (en) * | 2017-09-14 | 2022-05-27 | 佛山市顺德区顺达电脑厂有限公司 | Server system and detection method thereof |
TWI679529B (en) * | 2018-10-08 | 2019-12-11 | 新唐科技股份有限公司 | Self-check system and method thereof |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5615331A (en) * | 1994-06-23 | 1997-03-25 | Phoenix Technologies Ltd. | System and method for debugging a computing system |
US20070011507A1 (en) * | 2005-06-03 | 2007-01-11 | Intel Corporation | System and method for remote system support |
US20070174705A1 (en) * | 2005-12-14 | 2007-07-26 | Inventec Corporation | Post (power on self test) debug system and method |
US20080141073A1 (en) * | 2006-12-07 | 2008-06-12 | Inventec Corporation | BIOS debugging system and method |
US20080155332A1 (en) * | 2006-10-30 | 2008-06-26 | John David Landers | Point of sale system boot failure detection |
US20100017796A1 (en) * | 2008-07-16 | 2010-01-21 | Dell Products, Lp | Input/output transaction management during platform initiation |
US20100058314A1 (en) * | 2008-09-03 | 2010-03-04 | Chin-Yu Wang | Computer System and Related Method of Logging BIOS Update Operation |
US20100169633A1 (en) * | 2008-12-31 | 2010-07-01 | Vincent Zimmer | System and method to secure boot both uefi and legacy option rom's with common policy engine |
US20120159254A1 (en) * | 2010-12-17 | 2012-06-21 | Via Technologies, Inc. | Debugging Apparatus for Computer System and Method Thereof |
US8904182B2 (en) * | 2008-03-20 | 2014-12-02 | Kinamik Data Integrity, S.L. | Method and system to provide fine granular integrity to digital data |
US20150193620A1 (en) * | 2014-01-07 | 2015-07-09 | Dell Products, Lp | System and Method for Managing UEFI Secure Boot Certificates |
US20150235030A1 (en) * | 2014-02-18 | 2015-08-20 | Dell Products, Lp | Method for Processing UEFI Protocols and System Therefor |
US20150278068A1 (en) * | 2014-03-26 | 2015-10-01 | Robert C. Swanson | Initialization trace of a computing device |
US20160070913A1 (en) * | 2014-09-09 | 2016-03-10 | Dell Products, Lp | Method for Authenticating Firmware Volume and System Therefor |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1567229A (en) * | 2003-07-03 | 2005-01-19 | 纬创资通股份有限公司 | Method for dynamically establishing high-level configuration and power source interface architecture |
TW201030614A (en) | 2009-02-12 | 2010-08-16 | Asustek Comp Inc | Method of controlling basic input output system |
TW201128386A (en) * | 2010-02-01 | 2011-08-16 | Hon Hai Prec Ind Co Ltd | Post code detection systen and method for motherboard |
-
2014
- 2014-10-09 TW TW103135170A patent/TWI599876B/en active
- 2014-11-26 CN CN201410690235.8A patent/CN105487956B/en active Active
- 2014-12-31 US US14/587,672 patent/US9465707B2/en active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5615331A (en) * | 1994-06-23 | 1997-03-25 | Phoenix Technologies Ltd. | System and method for debugging a computing system |
US20070011507A1 (en) * | 2005-06-03 | 2007-01-11 | Intel Corporation | System and method for remote system support |
US20070174705A1 (en) * | 2005-12-14 | 2007-07-26 | Inventec Corporation | Post (power on self test) debug system and method |
US20080155332A1 (en) * | 2006-10-30 | 2008-06-26 | John David Landers | Point of sale system boot failure detection |
US20080141073A1 (en) * | 2006-12-07 | 2008-06-12 | Inventec Corporation | BIOS debugging system and method |
US8904182B2 (en) * | 2008-03-20 | 2014-12-02 | Kinamik Data Integrity, S.L. | Method and system to provide fine granular integrity to digital data |
US20100017796A1 (en) * | 2008-07-16 | 2010-01-21 | Dell Products, Lp | Input/output transaction management during platform initiation |
US20100058314A1 (en) * | 2008-09-03 | 2010-03-04 | Chin-Yu Wang | Computer System and Related Method of Logging BIOS Update Operation |
US20100169633A1 (en) * | 2008-12-31 | 2010-07-01 | Vincent Zimmer | System and method to secure boot both uefi and legacy option rom's with common policy engine |
US20120159254A1 (en) * | 2010-12-17 | 2012-06-21 | Via Technologies, Inc. | Debugging Apparatus for Computer System and Method Thereof |
US20150193620A1 (en) * | 2014-01-07 | 2015-07-09 | Dell Products, Lp | System and Method for Managing UEFI Secure Boot Certificates |
US20150235030A1 (en) * | 2014-02-18 | 2015-08-20 | Dell Products, Lp | Method for Processing UEFI Protocols and System Therefor |
US20150278068A1 (en) * | 2014-03-26 | 2015-10-01 | Robert C. Swanson | Initialization trace of a computing device |
US20160070913A1 (en) * | 2014-09-09 | 2016-03-10 | Dell Products, Lp | Method for Authenticating Firmware Volume and System Therefor |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106293620A (en) * | 2016-08-09 | 2017-01-04 | 浪潮电子信息产业股份有限公司 | The method of parameter in intel detection of platform Flash Rom |
CN109597787A (en) * | 2018-12-10 | 2019-04-09 | 浪潮(北京)电子信息产业有限公司 | SIO UART configuration method, system, device and readable storage medium storing program for executing |
Also Published As
Publication number | Publication date |
---|---|
US9465707B2 (en) | 2016-10-11 |
CN105487956B (en) | 2017-12-22 |
TWI599876B (en) | 2017-09-21 |
CN105487956A (en) | 2016-04-13 |
TW201614496A (en) | 2016-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9465707B2 (en) | POST (power-on-self-test) debugging method and apparatuses using the same | |
US10055218B2 (en) | System and method for adding and storing groups of firmware default settings | |
US9864702B2 (en) | Techniques to prelink software to improve memory de-duplication in a virtual system | |
US8108665B2 (en) | Decoupled hardware configuration manager | |
US7934209B2 (en) | Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan | |
US20170185461A1 (en) | Fast switching method, device and terminal of dual system | |
US8468334B1 (en) | Efficient initial RAM disk creation | |
US20150339005A1 (en) | Methods for handling applications running in the extend mode and tablet computers using the same | |
US20100049961A1 (en) | Update method for basic input/output system and update system thereof | |
US11500647B2 (en) | Systems and methods for achieving faster boot times using BIOS attribute mitigation | |
US8656133B2 (en) | Managing storage extents and the obtaining of storage blocks within the extents | |
US20120144390A1 (en) | Customized computer image preparation and deployment including virtual machine mode | |
US11768691B2 (en) | Boot process for early display initialization and visualization | |
US20150029114A1 (en) | Electronic device and human-computer interaction method for same | |
WO2021073549A1 (en) | Screen rotation picture display method and apparatus, computer device, and storage medium | |
US10162648B2 (en) | Methods for dynamically selecting a booting operating system and apparatuses using the same | |
US20180136825A1 (en) | System and method for updating a sign-on logo of an electronic device | |
US20130080882A1 (en) | Method for executing an application program | |
JP2007299233A (en) | Customizing device, customizing method, and customizing program | |
US20140368435A1 (en) | Modifying Input Delivery to Applications | |
CN117311741A (en) | Application program management method, terminal and server | |
US20200150945A1 (en) | Systems and methods for support of selective processor microcode updates | |
US9299058B2 (en) | Method and apparatus for automated display of documentation | |
JP6492465B2 (en) | Information processing apparatus, control method thereof, and program | |
CN114880632A (en) | Method for obtaining confusion resources, intelligent terminal and computer readable storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: WISTRON CORP., TAIWAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HSIEH, MIN HUA;CHEN, YU HONG;SIGNING DATES FROM 20141009 TO 20141013;REEL/FRAME:034607/0772 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |