Abstract:
A mechanism of booting up a system directly from a storage device and a means of initializing an embedded system prior to activating a CPU is presented. The said system is comprised of one or more CPUs, a reset controller, a storage device controller, one or more direct memory access controllers, a RAM and its controller, a ROM and its controller, a debug interface and a power-on reset (POR) sequencer. The POR sequencer controls the overall boot process of the embedded system. Said sequencer uses descriptors (POR Sequencer descriptors) which are used to update the configuration registers of the system and to enable CPU-independent data transfers with the use of DMA controllers. 
     Using a minimal amount of non-volatile memory for booting up a system brings down costs associated with increased silicon real estate area and power consumption. Capability of pre-initializing the system even before a CPU is brought out of reset provides flexibility and system robustness. Through the use of the Power-On Reset Sequencer module, integrity of program code and user data used in the boot up process can be verified thus providing a resilient boot up sequence.

Description:
CROSS-REFERENCE(S) TO RELATED APPLICATIONS 
       [0001]    This application 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 is hereby fully incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    1. Field 
         [0003]    The present invention relates generally to computers having a single or multiple Central Processing Units (CPU), and more particularly, to a method and device for booting such a system directly from a storage device. 
         [0004]    2. Description of Related Art 
         [0005]    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 it to interpret and execute code. When an embedded system has more than one processor it 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 paper. 
         [0006]    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 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 it 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 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 doesn&#39;t have the ability to self check its integrity. 
         [0007]    In an invention described in US Patent Application Publication number US 2005/0120146 A1, Jun. 2 2005, an embedded system in  FIG. 1  that does not have an on-chip nonvolatile memory such as a read only memory 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 flash block mass storage  106  to the RAM  103 . 
       SUMMARY 
       [0008]    The invention that is described in this document makes 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. The invention also allows the system to verify the integrity of data and code used in the boot process. 
         [0009]    In some cases, the configuration registers of an embedded system may need to be initialized even before any of the CPU of the system is brought out of reset to begin execution of the system firmware. The invention presented in this paper will also address this issue of pre-initialization. 
         [0010]    The present 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 of the system is brought out of reset. The embedded system consists of multiple controller chips or a single controller chip. The embedded system can have a single or multiple central processing units. 
         [0011]    The present invention comprises of at least one Central Processing Unit (CPU) which reads and executes firmware; a random access memory (RAM) which is used to temporarily store firmware; a memory controller which provides 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; nonvolatile memory and controller used to store data used by the Power-On Reset 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 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 storage device with data and code. 
         [0012]    The present invention describes the structure of the Power-On Reset (POR) Sequencer and its operation. 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. 
         [0013]    The POR Sequencer Descriptor of the current 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. 
         [0014]    The present invention also provides a method of copying POR Sequencer Descriptor from nonvolatile memory to the RAM and verifying its integrity; 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 of the system from reset. 
         [0015]    Initially, the system&#39;s nonvolatile memory and storage device contain nothing. When the system is powered up, no boot process occurs but the debug interface and a CPU 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. 
         [0016]    The method of copying 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 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 step ends after the verification of the copied POR Sequencer Descriptor to the RAM completed without error. 
         [0017]    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 step 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 step is ended and the sequence proceeds to the next method. 
         [0018]    The next method is the step 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 step 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 must be 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 step ends. The storage device refers to a single storage device or a plurality of storage devices of the same type. 
         [0019]    The last step is the release of the CPUs of the embedded system from reset. When the system has a single CPU, 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 system, a CPU 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. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0020]    So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings. 
           [0021]    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. 
           [0022]      FIG. 1  shows a prior art embedded system that implements a mechanism to directly boot from flash block mass storage. 
           [0023]      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. 
           [0024]      FIG. 3  is a block diagram which presents the internal organization of the power-on reset sequencer and its interconnection to the RAM via a memory controller. 
           [0025]      FIG. 4  shows the structure of the power-on reset sequencer descriptor. 
           [0026]      FIG. 5  illustrates a linked-list data structure of the power-on reset sequencer descriptor. 
           [0027]      FIG. 6  is a flow chart of the sequence used in copying the power-on reset sequencer descriptor from nonvolatile memory to the RAM. 
           [0028]      FIG. 7  is a flow chart of the sequence used in the register initialization phase of the power-on reset sequencer. 
           [0029]      FIG. 8  is a flow chart of the sequence used in copying the system firmware from the storage device to the RAM. 
           [0030]      FIG. 9  is a flow chart of the sequence used in releasing the CPUs of the embedded system from their reset states. 
       
    
    
     DETAILED DESCRIPTION 
       [0031]    The present invention relates a method and device for booting up a system from a storage device and further relates a method for enabling a system to initialize all configuration registers even before any of the CPUs of the system is brought out of reset. 
         [0032]      FIG. 2  is a block diagram showing a typical embodiment of the present invention. The figure shows an embedded system  200  comprising a CPU bus  202  interconnecting a single CPU  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 comprising the system is an internal RAM  208 , a small nonvolatile memory  215  and a storage device  209 . A storage device type may be a mechanical disk drive, a mobile flash drive, or a solid-state drive. 
         [0033]    The storage device controller  204  controls the storage device or devices  209  connected to it. A storage device or a plurality of storage devices  209  are connected to the storage device controller  204  via an IO 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. The reset controller  206  handles the reset states of all the devices in the system. One or a plurality of DMA controllers  203  initiates and tracks data transfers. The storage device controller  204  provides 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, the descriptor is divided into fragments  212 ,  213  and distributed across the nonvolatile memory  215  and storage devices  209 . 
         [0034]    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 system 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 to the RAM and verifying its integrity. After the system firmware has been loaded in the RAM and the system&#39;s configuration registers pre-initialized, the POR sequencer sequences the release of the CPUs from their reset states. 
         [0035]    The nonvolatile memory  215  with its controller  214  is used to store the head of the POR sequencer descriptor  212  used by the POR sequencer  207  in the boot process. Initially, the system&#39;s nonvolatile memory and storage devices attached to the system are empty. When the system is powered up the boot process exits to emulation mode since there are no POR sequencer descriptor to process and no system firmware to load and execute in memory. The system integrator which writes program for the system loads a firmware to the RAM of the system via the debug interface  216 . The firmware loaded in the RAM has a routine that writes the POR sequencer descriptor and system firmware to the nonvolatile memory  215  and storage devices  209  attached to the system. After the POR sequencer descriptor and system firmware has been written to the nonvolatile memory and storage devices, the next time the system is powered up, the system doesn&#39;t exit to emulation mode instead it continues with the boot process until all CPUs  201  of the system are released from their reset states. 
         [0036]      FIG. 3  is a schematic diagram that illustrates the structure and interconnection between the POR sequencer  300  and the multi-port memory controller  308 . For the POR sequencer  300 , data and control signals to and from the CPU bus  304  is managed by the bus master interface  303  while control signals to and from the RAM  311  is 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 . 
         [0037]    The POR sequencer  300  transfers the POR sequencer descriptor from the nonvolatile memory or from the storage device to the RAM  311  before it 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 it 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&#39;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. 
         [0038]    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 . 
         [0039]      FIG. 4  shows the POR sequencer descriptor format. 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&#39; 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&#39;s configuration register space. The POR sequencer DMA descriptors&#39; control information  404  contains information about the DMA controller descriptors  406  of the current POR sequencer descriptor. 
         [0040]    When the POR sequencer descriptor doesn&#39;t 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  gives us an illustration of a fragmented POR sequencer descriptor. 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. 
         [0041]      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 . 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 in step  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 . 
         [0042]      FIG. 7  illustrates the register initialization phase by the POR sequencer  207 . 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 . Steps  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&#39;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&#39;s descriptor  406  that it 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&#39;s control information  404  in block  608 . It 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. 
         [0043]    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. The process 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 . 
         [0044]    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 . 
         [0045]    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 its transfer 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 . 
         [0046]      FIG. 9  describes the process of releasing the CPUs  201  from their reset state. 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. 
         [0047]    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. 
         [0048]    It is also within the scope of the present invention to implement a program or code that can be stored in a machine-readable or computer-readable medium to 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 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. 
         [0049]    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. 
         [0050]    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.