Embedded system boot from a storage device

Description

CROSS-REFERENCE(S) TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. Provisional Application 61/980,564, filed 16 Apr. 2014 and is a Continuation-in-Part (CIP) of U.S. patent application Ser. No. 14/217,365 which claims benefit of and priority to U.S. Provisional Application 61/801,952, filed 15 Mar. 2013. The above Applications are hereby fully incorporated herein by reference.

This application is a continuation in part of U.S. application Ser. No. 14/217,365 which claims the benefit of and priority to U.S. Provisional Application 61/801,952, filed 15 Mar. 2013. This U.S. Provisional Application 61/801,952 and U.S. application Ser. No. 14/217,365 are hereby fully incorporated herein by reference.

FIELD

Embodiments of the invention relate generally to computers having a single or multiple Central Processing Units (CPU) or processors. Embodiments of the invention relate more particularly to a method and device for booting such a system directly from a storage device.

DESCRIPTION OF RELATED ART

The background description provided herein is for the purpose of generally presenting the context of the disclosure of the invention. Work of the presently named inventors, to the extent the work is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against this present disclosure of the invention.

An embedded system refers to an apparatus that is made up of a single or multiple controller chips interconnected to each other on a printed circuit board. A controller chip can have one or more central processing unit (CPU) that enables the controller chip to interpret and execute code. When an embedded system has more than one processor, the embedded system is already called a multiprocessor system. The term embedded system will be used to refer to a single CPU or a multiprocessor system in this disclosure.

A conventional embedded system contains a nonvolatile memory which is used to store firmware that is read and executed by a CPU to initialize the embedded system. The nonvolatile memory can be a read-only memory (ROM), one-time programmable memory (OTP), programmable read only memory (PROM), electrically erasable PROM (EEPROM), or a flash PROM (FPROM). The nonvolatile memory can be internal (on-chip) or external (off-chip) to the controller chip. The firmware stored in the nonvolatile memory can be a boot code loader, a basic input/output system (BIOS), an operating system (OS), or an application firmware. The boot code loader is a small code executed by a CPU to do minimum initialization of the system. After initialization, the boot code loader copies the BIOS or OS or application firmware from a mass storage device external to the embedded system to the random access memory (RAM) of the system. When the BIOS or OS or application firmware is already loaded in the RAM, the CPU reads and executes the BIOS or OS or application firmware to do exhaustive initialization and diagnostics before proceeding to normal system operation. A mass storage device can be a rotating disk drive or a solid-state drive (SSD) which is made up of FPROM devices. Though nonvolatile memory size can be reduced due to a small boot code loader, the boot code loader does not have the ability to self-check an integrity of the boot code loader.

In an invention described in US Patent Application Publication number US 2005/0120146 A1, which was published on 2 Jun. 2005, now U.S. Pat. No. 7,103,684, which was issued on 5 Sep. 2006, an embedded system in FIG. 1 that does not have an on-chip nonvolatile memory such as a read only memory (ROM) directly boots from flash block mass storage 106. The flash block mass storage 106 is a collection of flash chips interfaced to the flash memory controller 105. The apparatus makes use of a Flash Programming Engine, embedded within a Flash memory controller 105, the first device that is taken out of reset, to program a Direct Memory Access controller 104 to transfer a boot code loader from flash block mass storage 106 to an internal Random Access Memory (RAM) 103. When the transfer of the boot code loader to the RAM 103 is completed the internal Central Processing Unit 101 of the controller chip is taken out of reset to read and execute the boot code loader in the RAM 103. The boot code loader performs initialization of the system, power-on self-tests, and copies a much larger control program or application firmware from the flash block mass storage 106 to the RAM 103.

SUMMARY

Embodiments of the invention described in this disclosure make use of a minimum amount of non-volatile memory in order to boot an embedded system. Reduction in size of the nonvolatile memory brings about an advantage in terms of cost and complexity. An embodiment of the invention also allows the system to verify the integrity of data and code used in the boot process.

In some cases, the configuration registers of an embedded system may need to be initialized even before any of the CPU (processor) of the system is brought out of reset to begin execution of the system firmware. Embodiments of the invention presented in this disclosure will also address this issue of pre-initialization.

An embodiment of the invention provides a mechanism for booting up a system using a minimum amount of nonvolatile memory. This method also enables the embedded system to initialize all configuration registers even before any of the CPUs (processors) of the system is brought out of reset. The embedded system comprises multiple controller chips or a single controller chip. The embedded system can have a single or multiple central processing units (processors).

An embodiment of the invention comprises at least one Central Processing Unit (CPU) (or processor) which reads and executes firmware; a random access memory (RAM) which is used to temporarily store firmware; a memory controller which provides an interface to the RAM; a Reset Controller which maintains the reset states of all the devices of the embedded system; a Power-On Reset Sequencer which controls the overall boot process of the embedded system; a nonvolatile memory (e.g., ROM) and nonvolatile memory controller used to store data used by the Power-On Reset (POR) Sequencer in the boot process; at least one direct memory access (DMA) controller which initiates and tracks data transfers; a storage device controller which provides an interface to the storage device; a CPU bus which interconnects the devices of the system; and a storage device which is used to store system firmware; a debug interface used to pre-program the nonvolatile memory, and a storage device with data and code.

An embodiment of the invention describes the structure of the Power-On Reset (POR) Sequencer and the operation of the POR sequencer. The POR Sequencer makes use of a POR Sequencer Descriptor which is a preassembled descriptor that is stored in a nonvolatile memory of the system. The POR Sequencer descriptor contains register information and direct memory access (DMA) controller descriptors. The register information are read and used by the POR Sequencer to update the configuration registers of the system. The DMA descriptors are loaded by the POR Sequencer to the DMA controllers of the system. The POR Sequencer facilitates the boot process and takes care of verifying the integrity of loaded data and code in the RAM.

The POR Sequencer Descriptor in an embodiment of the invention is not limited to a single data structure. A linked-list of data structures is presented to increase the amount of register information and DMA descriptors available for processing by the POR Sequencer.

An embodiment of the invention also provides a method of copying a POR Sequencer Descriptor from nonvolatile memory to the RAM and verifying an integrity of the POR Sequencer Descriptor; a method of initializing the configuration registers by the POR Sequencer; a method of copying the system firmware from the storage device to the RAM; and a method of releasing the CPUs (processors) of the system from reset.

Initially, a nonvolatile memory of the system and storage device contain nothing. When the system is powered up, no boot process occurs but the debug interface and a CPU (processor) are released from reset. The system integrator loads a program to the RAM via the debug interface. The program contains code to burn the POR Sequencer Descriptor in nonvolatile memory and to save a copy of the System Firmware in the storage device.

The method of copying a POR Sequencer Descriptor from nonvolatile memory to RAM starts when the supply voltage of the system becomes stable after power-up. Then the Reset Controller, the POR Sequencer, the CPU Bus, the memory controllers, the DMA controllers, and the storage device controllers are released from reset. Then the POR Sequencer detects the presence of the POR Sequencer Descriptor in the nonvolatile memory. If the POR Sequencer Descriptor is not detected, then the debug interface and a CPU (processor) of the system are released from reset. If the POR Sequencer Descriptor is detected, then the POR Sequencer copies the POR Sequencer Descriptor from nonvolatile memory to RAM. This operation ends after the verification of the copied POR Sequencer Descriptor to the RAM is completed without error.

The method of initializing the configuration registers of the system starts when the first register information of the POR Sequencer Descriptor is read. Then the register indicated by the register information is updated with a new set of configuration. This sequence is repeated until the last register information of the POR Sequencer Descriptor is read and processed. Then the operation proceeds to the processing of the DMA descriptor. The type of the DMA descriptor is identified by the POR Sequencer. If the DMA descriptor points to another set of register information then the DMA transfer will update the register information and DMA descriptor spaces of the current POR Sequence Descriptor in the RAM. If the DMA descriptor points to a system firmware fragment, then this operation is ended and the sequence proceeds to the next method.

The next method is an operation where the system firmware stored in the external storage device is copied to the RAM of the embedded system. The system firmware can be a boot code loader, a BIOS, an operating system, or a plain application firmware. This operation starts when the POR Sequencer identifies that the DMA descriptor points to a system firmware fragment. The POR Sequencer loads the DMA or DMAs with the DMA Descriptors that will copy the system firmware fragments to the RAM. The POR Sequencer waits for completion signals from all DMA controllers that have been loaded with DMA descriptors before proceeding in the process flow. If the last DMA descriptor of the current POR Sequencer Descriptor points to another set of DMA Descriptors then another set of system firmware fragments are copied from the storage devices to the RAM. If the last DMA descriptor of the current POR Sequencer Descriptor points to the last system firmware fragment, then this operation ends. The storage device refers to a single storage device or a plurality of storage devices of the same type.

The last operation is the release of the CPUs (processors) of the embedded system from reset. When the system has a single CPU (processor), after the system firmware is loaded in the RAM, the POR Sequencer configures the reset controller to release the CPU from reset. Then the CPU starts reading and executing the system firmware. In a multi-CPU (multi-processor) system, a CPU (processor) is released from reset. Then, the CPU reads and executes the system firmware in the RAM. The system firmware will have instructions to sequence the release of the other CPUs from reset either one at a time or simultaneously.

In an embodiment of the invention, In an embodiment of the invention, an apparatus comprises an embedded system comprising: a processor configured to execute firmware; a random access memory (RAM) configured to store firmware and a multi-port memory controller configured to interface with the RAM; a power-on reset (POR) sequencer configured to control a boot process of the embedded system; a nonvolatile memory configured to store data used by the POR sequencer in the boot process and a nonvolatile memory controller configured to interface with the nonvolatile memory; a direct memory access (DMA) controller configured initiate and track data transfers; and a configuration and status register (CSR) controller configured to access modules in the embedded system.

In another embodiment of the invention, a method comprises: booting up an embedded system using a minimum amount of nonvolatile memory, including accessing modules in the embedded system.

In yet another embodiment of the invention, an article of manufacture, comprises: a non-transient computer-readable medium having stored thereon instructions that permit a method comprising: booting up an embedded system using a minimum amount of nonvolatile memory, including accessing modules in the embedded system.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one (several) embodiment(s) of the invention and together with the description, serve to explain the principles of the invention.

BRIEF DESCRIPTION OF DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the present invention may admit to other equally effective embodiments.

FIG. 1 shows a conventional embedded system that implements a mechanism to directly boot from flash block mass storage.

FIG. 2 is a block diagram of an embedded system with a power-on reset sequencer that manages the initialization and boot up of the system, in accordance with an embodiment of the invention.

FIG. 2A is a block diagram of an embedded system, in accordance with another embodiment of the invention.

FIG. 3 is a block diagram which presents the internal organization of the power-on reset sequencer and the interconnection of the power-on reset sequencer to the RAM via a memory controller, in accordance with an embodiment of the invention.

FIG. 4 shows the structure of the power-on reset sequencer descriptor, in accordance with an embodiment of the invention.

FIG. 5 illustrates a linked-list data structure of the power-on reset sequencer descriptor, in accordance with an embodiment of the invention.

FIG. 6 is a flow chart of the sequence used in copying the power-on reset sequencer descriptor from a nonvolatile memory to the RAM, in accordance with an embodiment of the invention.

FIG. 7 is a flow chart of the sequence used in the register initialization phase of the power-on reset sequencer, in accordance with an embodiment of the invention.

FIG. 8 is a flow chart of the sequence used in copying the system firmware from the storage device to the RAM, in accordance with an embodiment of the invention.

FIG. 9 is a flow chart of the sequence used in releasing the CPUs (processors) of the embedded system from their reset states, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

In the following detailed description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the various embodiments of the present invention. Those of ordinary skill in the art will realize that these various embodiments of the present invention are illustrative only and are not intended to be limiting in any way. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure.

In addition, for clarity purposes, not all of the routine features of the embodiments described herein are shown or described. One of ordinary skill in the art would readily appreciate that in the development of any such actual implementation, numerous implementation-specific decisions may be required to achieve specific design objectives. These design objectives will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine engineering undertaking for those of ordinary skill in the art having the benefit of this disclosure. The various embodiments disclosed herein are not intended to limit the scope and spirit of the herein disclosure.

Exemplary embodiments for carrying out the principles of the present invention are described herein with reference to the drawings. However, the present invention is not limited to the specifically described and illustrated embodiments. A person skilled in the art will appreciate that many other embodiments are possible without deviating from the basic concept of the invention. Therefore, the principles of the present invention extend to any work that falls within the scope of the appended claims.

As used herein, the terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items.

In the following description and in the claims, the terms “include” and “comprise” are used in an open-ended fashion, and thus should be interpreted to mean “include, but not limited to . . . ”. Also, the term “couple” (or “coupled”) is intended to mean either an indirect or direct electrical connection. Accordingly, if one device is coupled to another device, then that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and/or other connections.

Embodiments of the invention relate to a method and device for booting up a system from a storage device. Embodiments of the invention also relate to a method for enabling a system to initialize all configuration registers even before any of the CPUs (processors) of the system is brought out of reset.

FIG. 2 is a block diagram showing an exemplary embodiment of the invention. The block diagram in the figure shows an embedded system 200 comprising a CPU (Central Processing Unit) bus 202 interconnecting a single CPU 201 (or processor 201) or a plurality of CPUs 201, a single DMA controller 203 or a plurality of DMA controllers 203, a reset controller 206, a power-on reset (POR) sequencer 207, a RAM controller 205, a nonvolatile memory controller 214, a storage device controller 204, and a debug interface 216. Also, the system 200 comprises an internal RAM 208, a small nonvolatile memory 215, and a storage device 209. A storage device 209 type may be a mechanical disk drive, a mobile flash drive, or a solid-state drive (SSD).

The storage device controller 204 controls the storage device 209 or devices 209 connected to the storage device controller 204. A storage device 209 or a plurality of storage devices 209 are connected to the storage device controller 204 via an IO (input/output) bus 210 for the case of interface standards such as IDE/ATA, Serial ATA, SCSI/SAS, PCI/PCI-X, USB, Firewire, Bluetooth, Fibre Channel and PCI Express. For a solid-state drive, a flash bus is used to connect to the storage device controller 204 which also called a flash controller 204. The reset controller 206 handles the reset states of all the devices (as shown in FIG. 2) in the embedded system 20.

One DMA controller 203 or a plurality of DMA controllers 203 initiates and tracks data transfers. The storage device controller 204 provides an interface to the storage device 209. The storage device 209 is used to store system firmware 211 or a fragment of the system firmware 211. When the POR sequencer descriptor exceeds the space of the nonvolatile memory 215, the descriptor is divided into fragments 212, 213 and distributed across the nonvolatile memory 215 and storage devices 209.

The multi-port memory controller 205 interfaces the RAM 208 to the CPU bus 202 and to the POR sequencer 207. The POR sequencer 207 processes the POR sequencer descriptor which contains information to initialize configuration registers of the embedded system 200 and DMA descriptors used to fetch other POR sequencer descriptor fragments 213 and the system firmware 211. The POR sequencer 207 takes care of loading the system firmware 211 to the RAM 208 and verifying an integrity of the system firmware 211. After the system firmware 211 has been loaded in the RAM 208 and the configuration registers of the embedded system 200 are pre-initialized, the POR sequencer 207 sequences the release of the CPUs 201 from their reset states.

The nonvolatile memory 215 with the nonvolatile memory controller 214 is used to store the head of the POR sequencer descriptor 212 that is used by the POR sequencer 207 in the boot process. Initially, the nonvolatile memory 215 of the embedded system 200 and storage devices 209 that are attached to the embedded system 200 are empty. When the system 200 is powered up, the boot process exits to emulation mode since there are no POR sequencer descriptor to process and no system firmware 211 to load and execute in memory. The system integrator which writes program for the embedded system 200 loads a firmware to the RAM 208 of the system 200 via the debug interface 216. The firmware loaded in the RAM 208 has a routine that writes the POR sequencer descriptor and system firmware 211 to the nonvolatile memory 215 and storage devices 209 attached to the system 200. After the POR sequencer descriptor and system firmware 211 has been written to the nonvolatile memory 215 and storage devices 209, the next time the system 200 is powered up, the system 200 does not exit to emulation mode and instead the system 200 continues with the boot process until all CPUs 201 of the system 200 are released from their reset states. The firmware stored in the nonvolatile memory 215 can be a boot code loader, a BIOS, an OS, and/or an application firmware.

FIG. 2A is a block diagram of an embedded system 200A, in accordance with another embodiment of the invention. The embedded system 200A also has similar components and configuration as those described for the embedded system 200 in FIG. 2 except for the differences discussed below. The system 200A comprises a single CPU (0) 201 (processor (0) 201) or an n+1 number of CPUs (processors) 201 wherein n is an integer. The CPUs 201 can vary in number as noted by, for example, the dot symbols 250.

The operations of the embedded system 200A in FIG. 2A is as follows.

1. Power is supplied to a chip that includes the embedded system 200A.

2. Clock and Reset Controller 206 or CrCORE (which is implemented by the system 200A) waits for a crystal oscillator in the system 200A to stabilize.

3. CrCORE releases the nonvolatile memory controller 214, CPU bus 202, CSR bus 217, CSR controller 218, and multi-port memory controller 205 from the reset state.

4. POR sequencer 207 waits for above modules (nonvolatile memory controller 214, CPU bus 202, CSR bus 217, CSR controller 218, and multi-port memory controller 205) to be ready.

5. POR sequencer 207 commands the nonvolatile memory controller 214 through (via) sideband signal 220 to start searching for a bootstrap code loader stored in the nonvolatile memory 215.

6. Nonvolatile memory controller 214 searches for the latest instance/copy of the strap configuration and bootstrap code loader, wherein the latest instance or latest copy of the strap configuration and bootstrap code loader are stored in the nonvolatile memory 215.

7. Nonvolatile memory controller 214 maps the system address 0x0000 to this latest copy of the strap configuration and bootstrap loader.

8. Nonvolatile memory controller 214 informs the POR sequencer 207, through sideband signal 220 that the bootstrap code loader is ready.

9. This sideband signal 220 causes the clock and reset controller 206 to release the master CPU 201 (e.g., CPU (0) 201) from reset (i.e., reset state).

10. Master CPU (0) 201 reads the bootstrap code from nonvolatile memory 215.

11. Reading of bootstrap code by the master CPU (0) 201 also causes the nonvolatile memory controller 214 to check for data errors in the bootstrap code.

12. As part of the bootstrap code, CPU (0) 201 configures the clock sources 221 in the embedded system 200A via CSR access across the CSR bus 217.

13. CPU (0) 201 waits for the ready status of the clock sources 221.

14. CPU (0) 201 then releases from reset other modules (or elements) that are necessary for system firmware transfer, wherein these other modules or elements comprise the storage device controller 204, system bus 219, and multiport memory controller 205.

15. CPU (0) 201 instructs the DMA controller 203 to move firmware from the storage device 209 to the RAM 209 via the system bus 219. The DMA controller 203 can be one or more in number and can vary in number as noted, for example, the dot symbols 252. For example, there can be a single DMA controller (0) 203 in the embedded system 200A or there can be an m+1 number of DMA controllers 203 in the embedded system 200A, wherein m is an integer.

16. CPU (0) 201 releases remaining modules from reset state.

17. CPU (0) 201 remaps the system address 0x0000 from the nonvolatile memory 215 to the RAM 208.

18. The system firmware then starts running in the embedded system 200A.

Additional definitions in the embedded system 200A also includes the following.

The Clock and reset controller 206 handles the reset states of all the devices in the embedded system 200A and controls the clock sources used in the chip that includes the embedded system 200A.

The CSR bus 217 comprises a bus primarily used by the CPU(s) 201 to access the configuration and status registers of modules in the chip that includes the embedded system 200A.

The CSR (configuration and status register) controller 218 provides an interface for the CPU(s) 201 to access the configuration and status registers of modules in the chip that includes the embedded system 200A. These modules comprises the nonvolatile memory controller 214, CPU bus 202, CSR bus 217, storage device controller, and multi-port memory controller 205

The System bus 219 comprises a bus connecting the storage device controller 204 to the multiport memory controller 205.

The Sideband signals 220 comprises exclusive signals between the POR sequencer 207 and the nonvolatile memory controller 214.

The clock sources 221 produces clocking signals, usually, for example, phase-locked loops (PLL) signals. The clock sources 221 can be an m+1 number of clock sources 221 in the embedded system 200A as noted by, for example, the dot symbols 254, or the embedded system 200A comprises a single clock source (0) 221.

Other elements in the embedded system 200A such as, for example, the I/O bus 210, system firmware fragments 211, debug interface 216, and POR sequence descriptor fragments 212 and 213 were similarly described above with reference to the embedded system 200 in FIG. 2. The storage devices 209 can vary in number as noted, for example, by the dot symbols 256. For example, the embedded system 200A can include a single storage device (0) 209 or an m+1 number of storage devices 209. If there is an m+1 number of storage devices 209 in the embedded system 200A, then there are a p number of system firmware fragments 211 and a p number of POR sequence descriptor fragments 213, wherein p=m+1.

FIG. 3 is a schematic diagram that illustrates the structure and interconnection between the POR sequencer 300 and the multi-port memory controller 308, in accordance with an embodiment of the invention. For the POR sequencer 300, data and control signals to and from the CPU bus 304 are managed by the bus master interface 303 while control signals to and from the RAM 311 are managed by the memory controller port interface 302. The POR sequencer state machine 301 utilizes the bus master interface 303 to perform data transfer to and from the CPU bus and the memory controller port interface 302 to do data transfer to and from the RAM 311. The POR sequencer 300 combines the use of the bus master interface 303 and the memory controller port interface 302 in order to control transfers to and from the RAM 311.

The POR sequencer 300 transfers the POR sequencer descriptor from the nonvolatile memory or from the storage device to the RAM 311 before the POR sequencer descriptor is processed. When the POR sequencer descriptor is already loaded in the RAM 311, the POR sequencer state machine reads a part of the descriptor from RAM to parse and interpret. Depending on the content of the part of the POR sequencer descriptor, the POR sequencer state machine decides whether to get another part of the descriptor from RAM, transfer data from RAM to a device mapped on the CPU bus 304, or to write data that the POR sequencer state machine generated to the RAM or to a device mapped on the CPU bus 304. Through the use of POR sequencer state machine 301, memory controller port interface 302, and bus master interface 303 the POR sequencer 300 is able to do the following tasks: transfer of DMA controller descriptor to the DMA controller's configuration register space, activation of the DMA controller, initialization of configuration registers, and copy of data from storage device or nonvolatile memory to the RAM.

The multi-port memory controller 308 has several port interfaces. Port 1 interface 307 provides devices on the CPU bus 304 access to the RAM 311. Port 2 interface provides the POR sequencer 300 access to the RAM 311. The data path multiplexers 309 route the read and write requests from the POR sequencer 300 and the CPU bus 304 to the RAM 311. The controller 310 manages how the data path multiplexers 309 behave in response to the read and write requests received from the POR sequencer 300 and CPU bus 304.

FIG. 4 shows the POR sequencer descriptor format, in accordance with an embodiment of the invention. The POR sequencer descriptor is comprised of the register information space 401, the DMA descriptor space 403, and an optional POR sequencer descriptor checksum 407. The register information space consists of controller core register information 402 used by the POR sequencer to update the configuration registers of the system. The DMA descriptor space 403 on the other hand consists of the POR sequencer DMA descriptors' control information 404 and one or more DMA controller descriptors 406. The DMA controller descriptors 406 are loaded by the POR Sequencer to the DMA controller's configuration register space. The POR sequencer DMA descriptors' control information 404 contains information about the DMA controller descriptors 406 of the current POR sequencer descriptor.

When the POR sequencer descriptor does not fit in the nonvolatile memory of the system, the descriptor is divided into fragments and distributed across the nonvolatile memory and storage devices attached to the system. FIG. 5 provides an illustration of a fragmented POR sequencer descriptor, in accordance with an embodiment of the invention. POR sequencer descriptor fragment 0 501 is stored in the nonvolatile memory. Fragment 0 comprises of register information space 505, DMA descriptor space 503, and POR sequencer descriptor checksum 504. The DMA descriptor space 503 is composed of DMA controller descriptors 0 to P. The last DMA controller descriptor 506 of the POR sequencer descriptor fragment 501, 502 points to the next POR sequencer descriptor fragment 502. POR sequencer fragment 1 to N 502 have only two parts, the register information space 505 and DMA descriptor space 503 in contrast to POR sequencer descriptor fragment 0 501 which is made up of three parts. The POR sequencer descriptor fragment 501 or 502 may or may not have a register information space 505. The last DMA controller descriptor 507 of the last POR sequencer descriptor fragment points to the last fragment of the system firmware in the storage device.

FIG. 6 is a flowchart showing the process of transferring the POR sequencer descriptors 212, 213 from nonvolatile memory 215 and storage device 209 to the RAM 208, in accordance with an embodiment of the invention. After the system is powered-up and the input power supply stabilizes in block 601, the CPU bus 202, reset controller 206, DMA controller 203, storage device controller 204, RAM controller 205, nonvolatile memory controller 214 and POR sequencer 207 are brought out of reset in block 602. The POR sequencer 207 then detects the presence of POR sequencer descriptor 212 in the nonvolatile memory in block 603. If the first copy of the POR Sequencer descriptor 212 is detected, then POR sequencer 207 copies the POR sequencer descriptor 212 from the nonvolatile memory 215 to the RAM 208 in block 606. POR sequencer 207 then checks the integrity of POR sequencer descriptor 212 in block 606 by comparing the computed checksum to the POR sequencer descriptor checksum 507. If no error is found then copying of POR sequencer descriptor 212 from nonvolatile memory 215 to the RAM 208 is completed. If an error is found, a POR sequencer error handler is activated in block 612. If the first copy 212 is unsuccessfully detected at operation 604, in block 609, the POR sequencer will try to detect a second copy of the POR sequencer descriptor which is not shown in FIG. 2. If successful, the POR sequencer 207 will copy the backup copy of the POR sequencer descriptor from the nonvolatile memory 215 to the RAM 208 in block 605. If not, the POR sequencer 207 releases the debug interface 216 and a CPU 201 from reset to allow a system integrator from updating the nonvolatile memory 215 with a new POR sequencer descriptor 212.

FIG. 7 illustrates the register initialization phase by the POR sequencer 207, in accordance with an embodiment of the invention. Starting from block 701, the POR sequencer 207 reads the first register information in the register information space 401 of the POR sequencer descriptor 212 from the RAM 208. The POR sequencer 207 then processes the register information and then updates the corresponding configuration register based on the contents of the register information in block 702. Operations 701 and 702 are repeated for succeeding register information until the last register information of the current POR sequencer descriptor 212 is read and processed. After the last register information is read, the POR sequencer 207 writes the DMA controller descriptor 406 to the DMA controller's register space in block 704. The POR sequencer 207 then activates the DMA controller 203 in block 705. The DMA controller 203 then processes the DMA controller's descriptor 406 that the DMA controller 203 received and initiates transfer of data from the storage device 209 to the RAM 208 via the storage device controller 204 in block 706. When the data transfer is finished, in block 707, the DMA controller 203 informs the POR sequencer 207 that the data transfer has completed. The POR sequencer 207 then reads the POR sequencer DMA descriptor's control information 404 in block 608. The POR sequencer 207 then checks if the DMA controller descriptor 406 points to a new set of register information of another POR sequencer descriptor fragment 502 in block 709. If the test is positive, the register initialization phase is repeated starting with block 701. If the test is negative, then the register initialization phase has ended.

DMA controller descriptors 406 are not only used to fetch POR sequencer descriptor fragments 501, 502. They are also used to transfer system firmware 211 from the storage device to the RAM 208. In FIG. 8, the copying of system firmware 211 from the storage device 209 to the RAM 208 is illustrated, in accordance with an embodiment of the invention. The process, in this embodiment of the invention, starts with the POR sequencer 207 reading a DMA controller descriptor 406 from RAM 208 and then writing the DMA controller descriptor 406 to the configuration space of an available DMA controller 203 in block 801. The POR sequencer 207 then activates the DMA controller 203 in block 802, which would then cause the DMA controller 203 to start the transfer of a system firmware fragment 211 from the storage device 209 to the internal RAM 208 via the storage device controller 204 in block 803.

The POR sequencer 207 then reads the DMA descriptor control information 404 from RAM 208 in block 804. If the DMA descriptor 406 points to the last system firmware fragment, the POR sequencer 207 waits for all busy DMA controllers to complete their transfers in block 809. The POR sequencer 207 then verifies the integrity of the copied system firmware in block 811. If the system firmware is error free then the sequence completes. If an error is found, an error handling routine will be executed in block 813. In block 805, if the DMA controller descriptor 406 does not point to the last system firmware fragment, which means there are succeeding system firmware fragments, then the POR sequencer 207 proceeds to block 806 to check if the said DMA controller descriptor 406 was the last descriptor of the current POR sequencer descriptor. If it is the last DMA controller descriptor 406 of the current frame, then POR sequencer 207 waits for all the busy DMA controllers to complete their transfers in block 810. The process is repeated starting from block 801 for the next POR sequencer descriptor which will be used to fetch the next system firmware fragment 211.

In block 806, if the DMA controller descriptor 406 of the current POR sequencer descriptor is not the last one, then the availability of a DMA controller 203 is determined in block 807. If there is no available DMA controller, meaning, all the DMA controllers 203 are busy, then the POR sequencer 207 waits for a DMA controller 203 to complete the transfer performed by DMA controller 203 in block 808 before proceeding to process the next DMA controller descriptor 406. When a DMA controller becomes available the process goes back to block 801.

FIG. 9 describes the process of releasing the CPUs 201 from their reset state, in accordance with an embodiment of the invention. The POR sequencer 207 first configures the reset controller 206 to release a CPU 201 from reset in block 901. This CPU is usually referred to as the bootstrap CPU. After coming out of reset, the bootstrap CPU reads and executes the system firmware from RAM 208 in block 902. Then the bootstrap CPU performs full system initialization and diagnostics in block 903. If the diagnostic failed, a system firmware error handling routine is executed in block 905. If the system diagnostics is successful, the release of other CPUs, if present, proceeds. The system firmware instructs the reset controller 206 to release the next CPU from reset in block 908. The next CPU is released from reset which then reads and executes a copy of the system firmware in block 909. This process ends when all of the CPUs 203 have been brought out of reset. At this point, the system firmware exits system initialization phase and waits for service calls from the controller cores of the embedded system.

Foregoing described embodiments of the invention are provided as illustrations and descriptions. They are not intended to limit the invention to precise form described. In particular, it is contemplated that functional implementation of invention described herein may be implemented equivalently in hardware, software, firmware, and/or other available functional components or building blocks, and that networks may be wired, wireless, or a combination of wired and wireless.

It is also within the scope of the present invention to implement a program or code that can be stored in a non-transient machine-readable (or non-transient computer-readable medium) having stored thereon instructions that permit a method (or that permit a computer) to perform any of the inventive techniques described above, or a program or code that can be stored in an article of manufacture that includes a non-transient computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive techniques are stored. Other variations and modifications of the above-described embodiments and methods are possible in light of the teaching discussed herein.

The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.

These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.