Patent Application
20150242213
Portable computing devices (“PCDs”) are becoming necessities for people on personal and professional levels. These devices may include cellular telephones, portable digital assistants (“PDAs”), portable game consoles, palmtop computers, and other portable electronic devices.
One aspect of PCDs that is in common with most computing devices is the use of electronic memory components for storing instructions and/or data. Various types of memory components may exist in a PCD, each designated for different purposes. Commonly, non-volatile read-only memory (“ROM”) such as mask ROM is used to store critical instructions in the form of a primary boot loader (“PBL”) required for the PCD to boot, load operating system (“OS”) software, and transition control of the PCD over to the OS.
Notably, once the mask ROM is encoded with instructions, it cannot be reprogrammed or easily modified. As such, software (i.e., firmware) and data encoded in the mask ROM must be carefully developed prior to being encoded into the mask ROM. If the PBL referred to above, for example, is incorrect when encoded into the mask ROM then the options for “fixing” the PBL may be limited to either application of software patches through a finite number of fuses or, if the required fixes are extensive, complete remanufacture of the mask ROM component.
The security of the mask ROM makes it desirable for storage of PBL instructions, however, the very nature of mask ROM which makes it such a reliable and secure storage medium also limits its flexibility in accommodating post-manufacture changes to the PBL instructions. Accordingly, there is a need in the art for a system and method that provides for on-chip development of the PBL instructions post-manufacture (i.e., post “tape-out”) of the mask ROM. Moreover, there is a need in the art for a system and method that extends the flexibility of current systems and methods for PBL patching and on-chip system on a chip (“SoC”) calibration using fuses. Further, there is a need in the art for a system and method that uses one time programmable (“OTP”) ROM to support modification of PBL instructions stored in mask ROM.
Various embodiments of methods and systems for flexible read only memory (“ROM”) storage of coded instructions in a portable computing device (“PCD”) are disclosed. Because certain instructions and/or data associated with a primary boot loader (“PBL”) may be defective or in need of modification after manufacture of a mask ROM component, embodiments of flexible ROM storage (“FRS”) systems and methods use a closely coupled one time programmable (“OTP”) memory component to store modified instructions and/or data. Advantageously, because the OTP memory component may be manufactured “blank” and programmed at a later time, modifications to code and/or data stored in an unchangeable mask ROM may be accomplished via fuses in the security controller that change the instruction to branch to the OTP and bypass the mask ROM.
In operation, an exemplary embodiment of an FRS system and method receives a request for coded instructions (or data) stored at an address of a mask ROM component. The request may emanate from a processing component, such as a CPU, during a boot sequence, for example. The request may be received by the mask ROM as well as a security controller that comprises a plurality of fuses. The security controller may determine that fuses that contain patch instructions or patch data are available for the request, and if a patch is available, the security controller may subsequently cause the patch to be forwarded to a MUX module that returns the patch data to the processing component instead of the original instantiation of the instructions or data stored in the mask ROM.
Furthermore, the fuse might, for example, patch the instruction into a branch instruction that causes the processor to jump to the OTP address space. In such case, the FRS embodiment may cause instructions and/or data stored in the OTP component to be returned to the requesting processing component, thereby causing the mask ROM to be bypassed. In this way, embodiments of an FRS system and method may provide developers with extended memory capacity beyond fuses in the security controller that is useful for making modifications to otherwise unchangeable code or data hard wired into the mask ROM. Advantageously, embodiments of an FRS system and method may reduce the number of fuses required to accommodate changes to the code or data stored in a mask ROM, thereby saving space in a PCD that has a limited form factor.
It is further envisioned that some embodiments of a FRS system and method may utilize a cache by prefetching instructions or data stored in the OTP memory to the cache early in a boot sequence, or by copying instructions or data stored in the OTP memory to the system memory, for example on-chip SRAM, that yield shorter access latency than the OTP. In this way, subsequent requests for the instructions or data stored in the OTP may be made on the faster cache component, thereby more closely approximating the speed of the mask ROM.
In the drawings, like reference numerals refer to like parts throughout the various views unless otherwise indicated. For reference numerals with letter character designations such as “102A” or “102B”, the letter character designations may differentiate two like parts or elements present in the same figure. Letter character designations for reference numerals may be omitted when it is intended that a reference numeral to encompass all parts having the same reference numeral in all figures.
The word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect described herein as “exemplary” is not necessarily to be construed as exclusive, preferred or advantageous over other aspects.
In this description, the term “application” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, an “application” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
In this description, the term “fuse” is meant to refer to a programmable gate controlled by a security controller that receives a request for instructions or data stored at a memory address, such as an address in a mask ROM memory component. The fuse may contain instructions or data referred to in this description as a “patch” or it may contain a pointer to instructions or data stored in an alternative address, such as an address in an OTP memory component.
In this description, reference to “boot ROM” or “mask ROM” memory components refers to a broader class of non-volatile (i.e., retains its data after power is removed) read only memory and will not limit the scope of the solutions disclosed herein to modification of instructions stored in mask ROM only. That is, it will be understood that various embodiments of the systems and method provide a solution for post-manufacture modification of instructions stored in any non-volatile read only memory at the time of manufacture, whether such memory is reprogrammable or not. Notably, although some types of read only memory other than mask ROM can be erased and re-programmed multiple times, it is envisioned that the cumbersome and slow process of reprogramming such memory types may make them attractive for application of certain embodiments of the solutions disclosed herein.
In this description, reference to one time programmable (“OTP”) memory or “boot OTP” or the like refers to a broader class of non-volatile read only memory to which instructions and/or data may be burned (i.e., saved or stored) after manufacture of the memory and will not limit the scope of the solutions disclosed herein to specific use of OTP memory. As such, in this description, it will be understood that OTP memory envisions any programmable read-only memory or field programmable non-volatile memory suitable for a given application of a solution.
As used in this description, the terms “component,” “database,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution, and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components may execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).
In this description, the terms “central processing unit (“CPU”),” “digital signal processor (“DSP”),” “graphical processing unit (“GPU”),” and “chip” are used interchangeably. Moreover, a CPU, DSP, GPU or a chip may be comprised of one or more distinct processing components generally referred to herein as “core(s).”
In this description, the term “portable computing device” (“PCD”) is used to describe any device operating on a limited capacity power supply, such as a battery. Although battery operated PCDs have been in use for decades, technological advances in rechargeable batteries coupled with the advent of third generation (“3G”) and fourth generation (“4G”) wireless technology have enabled numerous PCDs with multiple capabilities. Therefore, a PCD may be a cellular telephone, a satellite telephone, a pager, a PDA, a smartphone, a navigation device, a smartbook or reader, a media player, a combination of the aforementioned devices, a laptop computer with a wireless connection, among others.
In this description, the terms “bootstrapping,” “boot,” “reboot,” “boot mode,” “boot sequence,” “boot phase” and the like are meant to refer to the initial set of operations that a PCD performs at the direction of the primary boot loader (“PBL”) when the PCD is initially powered on including, but not limited to, loading the operating system, subsequent images corresponding to different scenarios such as factory provision or normal boot up, and preparing the various PCD components for use. Notably, exemplary embodiments of the solutions are described within the context of modifying PBL instructions; however, it is envisioned that certain embodiments of the solutions may be applicable to other instruction and/or data sets stored in non-volatile memory and in need of modification.
In current systems and methods, the PBL instructions reside entirely in unchangeable mask ROM. Extensive modifications to the PBL instructions after manufacture of the mask ROM may dictate scrapping the mask ROM and starting over. Minor changes to the PBL instructions, however, may be accommodated through patches applied through fuses. Fuses provide a limited amount of flexibility to make changes to the code programmed in the ROM.
Because the ability to modify PBL instructions after tape-out of a chip is limited to the capacity represented by fuses in the PCD, designers have to be extremely careful in developing the PBL code prior to the tape-out process. The time and care taken by designers translates into more expensive chips and slower lead times to market. To overcome these limitations, flexible ROM storage (“FRS”) systems and methods couple OTP memory banks with mask ROM memory banks for shared duties in storage of PBL instructions and data. Advantageously, by using OTP memory in couple with mask ROM, the number of fuses needed to accommodate changes to the initial instantiation of PBL instructions may be reduced, thereby saving physical space in a PCD with form factor constraints. Additionally, by using the OTP memory in this manner, embodiments of FRS systems and methods may provide for increased capacity to make changes to the PBL content after tape-out of the mask ROM without sacrificing security of the PBL.
As mentioned above, limitations on using mask ROM for the entire storage of PBL instructions include long lead times to market that result from the inflexibility of mask ROM to accommodate instruction and/or data modification. As an example, suppose that a typical six-week lead-time for design and manufacture of a mask ROM component during the development of a PCD is reduced to one week. In reaction to the shortened lead time, designers move forward with a previous instantiation of PBL instructions, or a new PBL with certain new functions not implemented, with limited modifications, and load it into the metal mask ROM. After verification, it is discovered that a significant portion of the PBL driver, 5% for example, is questionable. Again, because of the shortened lead-time, the designers have no choice but to move forward to mass production of the mask ROM.
Inevitably, the 5% of “bad” code will present a huge, maybe insurmountable, problem post-manufacture of the mask ROM because there may not be enough fuses in the PCD to accommodate all the patching that will be required to “fix” the 5% of code. With FRS solutions, however, closely coupled OTP memory may provide a large blank memory capacity that can be used in conjunction with the fuses to correct the questionable portions of the PBL driver.
Returning to the example, suppose that the 5% of questionable PBL code opened up a lot of bugs that required a significant amount of rework to the PBL driver. Further suppose that the volume of rework exceeds the capacity of the fuses but could easily be stored in an available OTP memory component. In this situation, an FRS embodiment may provide for storage of the reworked PBL code portions into the OTP memory component and then use a fuse for storage of a pointer to the OTP memory instead of for storage of the reworked PBL code. Advantageously, when a request for questionable PBL code is received at a security controller, the fuse points to the reworked PBL code in the OTP, thereby branching the request to the OTP memory component and bypassing the problematic PBL code in the mask ROM.
As another application, FRS embodiments may provide for accommodation of newly added or upgraded functionality in the PCD by using the fuses again to map away from the mask ROM and point to an updated image of the PBL driver in the OTP memory. The updated image, which may have been loaded into the OTP memory at the time the functionality of the PCD was changed or upgraded, may be required to support the new functionality which would otherwise not be possible without replacement of the mask ROM or addition of extra fuses.
Notably, one of ordinary skill in the art will recognize that FRS embodiments optimize the capacity of fuses in the PCD because the fuses do not necessarily need to contain patch code but, rather, only need to contain pointers to patch code stored in a coupled OTP memory. Along these lines, it is envisioned that certain embodiments of FRS systems and methods may include a portion of fuses with pointers to OTP memory and a portion of fuses with patch code stored therein, while other embodiments may use fuses entirely for storage of pointers to code stored in OTP memory.
It is also envisioned that some FRS embodiments may not include fuses at all but, instead, use code stored in the OTP memory to either direct requests to the mask ROM or respond to requests with instructions and/or data instantiated in the OTP itself. It is further envisioned that certain FRS embodiments include mask ROM instructions that branch to the OTP memory. In such embodiments, a fuse may replace the instruction in the mask ROM or change it into a branch to the OTP memory.
In general, the security controller 101 may be formed from hardware and/or firmware and may be responsible for receiving requests for instructions and/or data associated with a primary boot loader (“PBL”) and using fuses to either return patch instructions or point to patch instructions stored in an OTP memory component coupled with a mask ROM. Advantageously, using the fuses to point to instructions and/or data stored in an OTP memory component, a security controller 101 may provide for modification and/or update of PBL driver code stored in a mask ROM without needing excessive numbers of fuses.
As illustrated in
As further illustrated in
The CPU 110 may also be coupled to one or more internal, on-chip thermal sensors 157A as well as one or more external, off-chip thermal sensors 157B. The on-chip thermal sensors 157A may comprise one or more proportional to absolute temperature (“PTAT”) temperature sensors that are based on vertical PNP structure and are usually dedicated to complementary metal oxide semiconductor (“CMOS”) very large-scale integration (“VLSI”) circuits. The off-chip thermal sensors 157B may comprise one or more thermistors. The thermal sensors 157 may produce a voltage drop that is converted to digital signals with an analog-to-digital converter (“ADC”) controller (not shown). However, other types of thermal sensors 157 may be employed.
The touch screen display 132, the video port 138, the USB port 142, the camera 148, the first stereo speaker 154, the second stereo speaker 156, the microphone 160, the FM antenna 164, the stereo headphones 166, the RF switch 170, the RF antenna 172, the keypad 174, the mono headset 176, the vibrator 178, thermal sensors 157B, the PMIC 180 and the power supply 188 are external to the on-chip system 102. It will be understood, however, that one or more of these devices depicted as external to the on-chip system 102 in the exemplary embodiment of a PCD 100 in
In a particular aspect, one or more of the method steps described herein may be implemented by executable instructions and parameters stored in the memory 112 or as form the security controller 101 and/or its fuses. Further, the security controller 101, the memory 112, the instructions stored therein, or a combination thereof may serve as a means for performing one or more of the method steps described herein.
If the particular instructions or data stored at the requested address has been patched, i.e. a “patch valid” bit has been set for that address by the security controller 101, the patch data held by a fuse (F0, for example) is forwarded (arrow 215) to the Boot ROM Patch and Multiplexor Module (“MUX” module) 114. The MUX module 114 overrides the PBL data coming out of the metal mask ROM 117 (arrow 210) and returns the patch code or patch data, as the case may be, to the CPU 110 (arrow 220) instead of the original instantiation of the code or data stored in the mask ROM 117. If no valid patch data is held by a fuse of the security controller 101, the MUX module 114 returns the original instructions and/or data to the CPU 110 (arrow 220).
Notably, the particular embodiment of the on-chip system 102 illustrated in
If the particular instructions or data stored at the requested address has been patched, i.e. a “patch valid” bit has been set for that address by the security controller 101, the patch data held by a fuse (F0, for example) may be forwarded (arrow 315) to the MUX module 114. In such case, the MUX module 114 overrides the PBL data coming out of the metal mask ROM 117 (arrow 310) and returns the patch code or patch data, as the case may be, to the CPU 110 (arrow 320A) instead of the original instantiation of the code or data stored in the mask ROM 117. As in the
Alternatively, however, in the FRS system of
Advantageously, by using OTP memory 115 in conjunction with the Boot ROM 113, FRS systems and methods may provide extended memory capacity for holding replacement code and/or data associated with a PBL driver. Moreover, by storing PBL instructions and/or data in the Boot OTP 115, FRS embodiments optimize fuse capacity as certain fuses of the security controller 101 may need to only hold one patch to branch to OTP memory 115 addresses instead of entire code patches or replacement data. Notably, the
Referring to the
If the particular instructions or data stored at the requested address has been patched, i.e. a “patch valid” bit has been set for that address by the security controller 101, the patch data held by a fuse (F0, for example) may be forwarded (arrow 415) to the MUX module 114. In such case, the MUX module 114 overrides the PBL data coming out of the metal mask ROM 117 (arrow 410) and returns the patch code or patch data, as the case may be, to the CPU 110 (arrow 420A) instead of the original instantiation of the code or data stored in the mask ROM 117. If a “patch valid” bit has not been set for a fuse of the security controller 101, the MUX module 114 returns the original instructions and/or data stored in the mask ROM 117 to the CPU 110 (arrow 420A).
Alternatively, however, in the FRS system of
Additionally, because the Boot OTP 115 may be divided into banks with individual circuitry, the slower programming time of the Boot OTP 115 relative to the Boot ROM 113 may be accommodated via parallel programming methodologies. In this way, each bank may be programmed concurrently. As an example, it is envisioned that a 48 Kb OTP may be divided into 2, 4, or 8 banks, thereby enabling the programming of the entire OTP memory in parallel, thereby possibly shortening the programming time for the entire OTP to the time that it takes to program a single bank of OTP.
Further regarding programming the Boot OTP 115, it is envisioned that some embodiments of the FRS solutions may include an encryption of the instructions and/or data that is stored in the Boot OTP 115. Because certain instructions and data must be secured in order to prevent hacking or compromising of the data, such as PBL instructions and data for example, the code and data designated for storage in the Boot OTP 115 after tape-out of the mask ROM may require encryption and decryption methodologies, as would be understood by one of ordinary skill in the art of encryption.
When pointed to the Boot OTP 115, the Boot OTP 115 may return the correct, well verified instructions or data stored therein to the CPU (arrow 520B). In some embodiments, the Boot OTP 115 instructions and/or data may be copied into a CPU cache 116 (arrow 530) so that subsequent requests for the instructions and/or data may be made by the CPU 110 to the faster cache 116 (arrow 535).
Returning to decision block 610, if no fuse with patch code or data that replaces original code or data in the mask ROM 117 and instructs the CPU to continue its execution flow in the mask ROM 117 is identified, the process follows the “no” branch to decision block 625. At decision block 625, if a fuse of the security controller 101 contains valid patch code or data that replaces original code or data with a branch to the OTP 115, then the “yes” branch is followed to block 630 and the mask ROM 117 is bypassed to the Boot OTP 115. Notably, depending on the patch value in the fuse, the patch may replace the original instruction or data and still instruct the CPU to continue the original execution flow in ROM, or it can replace the original instruction or data into a branch into boot OTP. In the latter case, the CPU may continue to fetch the instructions or data in the boot OTP after the patch.
Returning to the method 600 at block 630, at the Boot OTP 115, patch code or data associated with the requested address is queried and returned to the CPU 110. Subsequently, at block 635 the patch code or data in the Boot OTP 115 is copied to a cache 116 so that the CPU 110 may more quickly access the data for future requests.
Returning to the decision block 625, if no fuse of the security controller 101 contains replacement code or data (as represented in method 600 by the “yes” branches of decision blocks 610 and 625), then the instructions or data originally instantiated at the requested address in the mask ROM 117 is presumed valid and the “no” branch is followed to block 640. At block 640, the original code or data, such as PBL code or data, is queried from the mask ROM and returned to the CPU 110 via the MUX module 114. The process 600 returns.
Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the scope and spirit of the invention. In some instances, certain steps may be omitted or not performed without departing from the invention. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.
Additionally, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example. Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the drawings, which may illustrate various process flows.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.
Therefore, although selected aspects have been illustrated and described in detail, it will be understood that various substitutions and alterations may be made therein without departing from the spirit and scope of the present invention, as defined by the following claims.
