Abstract:
A novel processor architecture and algorithms are provided which improve non-volatile memory updates and increases processor performance in successive generations of processors. A new processor architecture is supported by a software model consisting of two new firmware layers and the legacy 32 bit basic input output system (BIOS) firmware. The new firmware layers consist of a Processor Abstraction Layer (PAL) and a System Abstraction Layer (SAL). The PAL and SAL have procedure calls which allow updates of the firmware components in the non-volatile memory of a system, e.g. non-volatile ROM. 
     The present invention includes invoking a system abstraction layer update procedure to implement a new input binary into the non-volatile memory. An algorithm for the non-volatile memory includes selecting a lead processor to perform an update and using the system abstraction layer update procedure. The system abstraction layer update procedure is used to call an appropriate authentication routine. The system abstraction layer update procedure is used to call a specific non-volatile memory implementation routine.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to the field of electronic data processing devices. More particularly, the present invention relates to new processor architecture and algorithms for non-volatile memory updates. 
     BACKGROUND OF THE INVENTION 
     In any computer system it is extremely important to protect the boot code that is contained in the non-volatile read only memory (ROM) from being accidentally erased. If ROM boot code is destroyed, the machine will not even boot to an operating system making recovery almost impossible. Since today&#39;s machines use small flash ROM packages the end user can not recover a system that has lost its ROM data because the ROM component can not be replaced by the end user. All this means is that a software virus attack that destroys boot ROM code is entirely unacceptable. Hence it is necessary to have a full guarantee that boot ROM code is protected by the virtue of design and yet is updatable to a newer valid firmware. It is also necessary in a multiprocessor system that one processor execute the flash ROM update and other processors are in rendezvous state while a valid update is being processed. 
     In the prior art of 32 bit processors, on chip micro-code is generally provided with a patching facility. Unfortunately, this prior art method is unsuitable in the case of successive generation 64 bit processors which no longer possess the prior art micro-code patching facility. Also, the prior art micro-code patching facility is useful only to embed a 2 kilo-byte (KB) patch into ROM and is unable to perform an update of 1 mega-byte (MB) or greater. 
     For the reasons stated above, and for other reasons stated below which will become apparent to those skilled in the art upon reading and understanding the present specification, it is desirable to develop improved methods for updating non-volatile memory in successive processor generations. 
     SUMMARY OF THE INVENTION 
     A novel processor architecture and algorithms are provided which improve non-volatile memory binary code updates and increase processor performance in successive generations of processors. A new processor architecture is supported by a software model consisting of two new firmware layers and the legacy 32 bit basic input output system (BIOS) firmware. The new firmware layers consist of a Processor Abstraction Layer (PAL) and a System Abstraction Layer (SAL). The PAL and SAL have procedure calls which allow updates of the firmware components in the non-volatile memory of a system, e.g. non-volatile ROM. 
     The present invention includes invoking a system abstraction layer update procedure to implement a new input binary into the non-volatile memory. An algorithm for the non-volatile memory update includes selecting a lead processor to perform an update and using the system abstraction layer update procedure. The system abstraction layer update procedure is used to call an appropriate authentication routine. The system abstraction layer update procedure is then used to call a specific non-volatile memory implementation routine. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 illustrates a network according to the teachings of the present invention 
     FIG. 2 illustrates, in block diagram form, a successive generation processor architecture according to the teaching of the present invention. 
     FIG. 3 illustrates, in flow diagram form, a method for authenticating and updating non-volatile memory at designated hardware events in successive processor generations according to the teachings of the present invention. 
     FIG. 4 illustrates, in flow diagram form, a method for run-time authentication and update of non-volatile memory in successive processor generations according to the teachings of the present invention. 
    
    
     DETAILED DESCRIPTION 
     In the following detailed description numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present invention. 
     FIG. 1 is an illustration of a system configuration  100  according to the teachings of the present invention. The system configuration  100  includes an electronic system  102 . In one embodiment, the electronic system  102  includes a personal computer  102 . In an alternative embodiment, the electronic system  102  includes a system server  102  or a microcontroller  102 . As shown in the embodiment of FIG. 1, the electronic system  102  is linked to the Internet  108  and to another server  106  as part of the system configuration  100 . In one embodiment, the electronic system  102  is a reliable, available and serviceable (RAS) electronic system  102 . The electronic system  102  can be linked to the Internet  108  and server  106  either in a direct hardwired fashion or indirectly in a wireless fashion using remote electromagnetic signal transmission in the radio or microwave frequencies. In FIG. 1, the electronic system  102  includes computer readable medium such as a disk drive for reading data storage media, e.g. a compact disc  104 . The electronic system  102  also includes computer readable medium such as random access memory (RAM) and read only memory (ROM). The electronic system further includes a control system  110 . 
     FIG. 2 illustrates is a block diagram illustrating the control system  110  according to the teachings of the present invention. The control system  110  includes an operating system  200  which is communicatively coupled to a processor architecture  205 . In one embodiment, the processor architecture  205  includes a number of processors,  210 A,  210 B, . . . ,  210 N, which couple to non-volatile memory  220 . In one embodiment, the number of processors,  210 A,  210 B, . . . ,  210 N, and the non-volatile memory  220  are on separate chips. In an alternative embodiment, the number of processors,  210 A,  210 B, . . . ,  210 N, and the non-volatile memory  220  are located on the same chip. The non-volatile memory  220  includes a FLASH memory, an electrically erasable and programmable read only memory (EEPROM), or any other suitable non-volatile memory  220 . The non-volatile memory  220  includes a binary code module called a processor abstraction layer  221  (PAL) and a binary code module called a system abstraction layer  224  (SAL). The non-volatile memory  220  includes a data structure or directory structure  229  with pointers to different components of the firmware, each of which can come from different sources or owners to be finally merged together as a firmware (FW) entity. In one embodiment, and as referred to in this application, the directory structure  229  is called the Firmware Interface Table  229  (FIT). The non-volatile memory  220  can further include the legacy 32 bit basic input output system  228  (BIOS). 
     The FIT  229  provides information about each firmware component in the non-volatile memory  220 , such as location of the component within the non-volatile memory  220 , length of the component, checksum, version number, etc. Firmware components may be developed by different organizations at different times. These components will be built separately but will need to interact with each other. The FIT  229 , acting as the repository of the locations of various firmware components facilitates this interaction. Further, the FIT  229  permits the replacement/addition of an individual firmware component within the non-volatile memory  220 . Also, the FIT  229  allows the flexibility of positioning a firmware component at any convenient place in the non-volatile memory  220 , thus allowing for better management of non-volatile memory  220  space. The FIT data structure contains the checksum of a firmware component that may be verified prior to its execution and this facilitates reliable booting. 
     The PAL  221  includes multiple binary code blocks  222  which are provided by the processor vendor, and which provides a standard firmware interface to abstract processor implementation specific features of the processor architecture  205 . The PAL  221  is integrated with other code layers such as the SAL  224  which similarly includes binary code blocks  225 . This poses unique issues to original equipment manufacturers (OEMs), since the PAL  221  binary code  222  is not an independent block living in a separate ROM device but an integrated component with other OEM controlled software layers. It also opens up a huge potential for a probable software virus attack from a malignant binary code block that looks like a valid PAL  221  binary code block  222  for a non-volatile ROM update utility. The virus issue is so potent that OEMs usually do not allow any binary blocks to be integrated into their system ROM today. 
     In one embodiment, the PAL  221  includes protected binary code blocks  222  comprising enhancements and bug fixes that are made to the processor architecture  205  over time. It is important for the processor vendor to be able to control the update of the PAL  221  by the end user in order to make sure that all enhancements and bug fixes made to the processor architecture  205  are made correctly. It is similarly important for original equipment manufacturers (OEMs) to be able to control updates to OEM provided components which are integrated into the non-volatile memory  220 . 
     The present invention facilitates this need by defining a unique SAL procedure interface block  227  within the SAL  224 . The unique SAL procedure interface block  227  is copied into random access memory (RAM)  215  where is exposed to a caller program of an update utility, also present in RAM  215 , when an update is to be performed. The SAL procedure interface block  227  imposes a unique header onto the multiple binary code blocks  222  in the PAL  221  and onto multiple binary code blocks  225  in the SAL  224 . This unique header will contain a version number that will follow an ascending order and a date stamp that can be checked against the corresponding fields in the FIT structure  229  associated with the code blocks,  222  and/or  225 , contained in the non-volatile memory  220 . The present invention also solves the issue of virus attack threat by making it mandatory for the SAL procedure interface to call an authentication routine before allowing access to the already programmed binary blocks,  222  and/or  225 , in the PAL  221  and SAL  224  of the non-volatile memory  220 . Both the PAL  221  and SAL  224  include an authentication routine,  223  and  226  respectively, for the protected binary code,  222  and  225  respectively. This authentication routine will authenticate the newer binary blocks that are submitted to PAL  221  and SAL  224  in the non-volatile memory  220 . 
     The SAL procedure interface block  227  design makes certain that only authenticated binary blocks of an appropriate version and date as compared to the binary blocks,  222  and/or  225 , contained in the non-volatile memory  220 , are allowed to replace the non-volatile memory  220  copies of the binary blocks,  222  and/or  225 , as well as update the FIT data structures in interface block  229  that are associated with or point to the protected binary blocks,  222  and/or  225 . The SAL procedure interface makes sure that new input binaries, which fail authentication, do not update the non-volatile memory, and hence protects the non-volatile memory from virus attacks. In this manner, it is not possible for random access memory (RAM) based code (e.g. a malignant virus), to initiate a non volatile memory update and destroy the boot code. Additionally, the SAL procedure interface block  227  design ensures that the new versions of PAL  221  binary blocks  222  are compatible with all the processors within the system configuration  100  to ensure successful boots subsequently. 
     Included within the scope of the present invention are at least two scenarios in which an update to the non-volatile memory of a system may occur. A first scenario includes performing an update to non-volatile memory during boot time in firmware. A second scenario includes performing an update to non-volatile memory while the operating system is up and running. 
     FIG. 3 illustrates, in flow diagram form, a method for updating non-volatile memory during boot time in firmware. Here, the update will be performed at a designated hardware event, e.g. initialize mode (INIT) in successive processor generations according to the teachings of the present invention. As shown in FIG. 3, the update procedure starts in the firmware (FW)  310 . Data or a new input binary to be programmed is marked and a hardware event, e.g. an initialize/reset (INIT/RESET) mode is invoked  320 . Control is here transferred over to the INIT mode. Next the INIT mode will serve as a starting point for the update sequence  330 . The INIT and/or RESET is invoked using chip set registers after the new input binary that needs to be programmed in the non-volatile memory has been brought into memory, e.g. RAM. In a successive generation processor based system according to the teachings of the present invention, the invocation of hardware events like INIT/RESET brings the machine to native mode and forces execution from ROM resident code in the non-volatile memory. Additionally, the INIT/RESET signal releases write protected blocks of non-volatile memory for normal programming  345  in certain embodiments of non-volatile memory such as flash memory. The transition to native mode permits a single code block to update the firmware components regardless of the current Instruction Set Architecture (ISA) of the processor. This ROM resident code includes a SAL procedure interface contained in the SAL as described and explained in detail with connection to FIG.  2 . 
     By arranging this ROM resident code to be in hardware protected regions of the non-volatile memory, it is ensured that the code will be present and secure. According to the teachings of the present invention, the INIT/RESET code in the successive generation processor based system runs in the highest privilege level and in physical mode making it possible to do raw accesses to the non-volatile memory. Also, since the INIT mode is of the highest priority it will bring all of the processors, in a multi-processor system, into the INIT/RESET code block and the code can then select one processor, e.g. a boot strap processor (BSP), to serve as a lead processor and process the non-volatile memory update  340 . The INIT signal releases protected binary blocks of ROM to be normal blocks for normal programming  345 . Meanwhile, the lead processor will then communicate with the SAL procedure interface that has been copied from the SAL of the non-volatile memory into RAM. The SAL procedure interface will call an appropriate authentication routine to validate the new input binary. In the case of a PAL update, the SAL procedure calls the PAL authentication routine within the PAL in the non-volatile memory. In the case of a SAL update, the SAL procedure will call the vendor specific SAL authentication routine within the SAL in non-volatile memory. At this point the marked new input binary is also copied to an available block of RAM  355 . 
     Only a new input binary block which passes the authentication routine of the trusted code and is executing in INIT mode will be allowed access to the non-volatile memory  360 . In this case, the new input binary which has passed the authentication routine will be copied into the non-volatile memory  360 , and the directory table entries within the FIT  229  will be adjusted to point to this new binary block. In certain embodiments of non-volatile memory such as FLASH memory, further writes to the non-volatile memory blocks containing code will be prevented by setting certain lock bits associated with the non-volatile memory. Next the system will perform a boot  370 . 
     If the authentication fails, the new input binary will not be allowed to access the non-volatile memory  360 . Here, the INIT code in the firmware can get back to the operating system by returning through the operating system registered INIT handler. 
     FIG. 4 illustrates, in flow diagram form, a second scenario for performing updates to non-volatile memory when the operating system is up and running. In other words, FIG. 4 illustrates a method for run-time updates which starts through the operating system (OS) using an update utility  405 . The SAL procedure interface from the non volatile memory is copied into RAM where it is exposed, or operatively coupled, to a caller program of an update utility  408  for updating the non volatile memory with a new input binary. The OS selects a lead processor and brings all the other processors in the system to a spin-loop  410 . As shown in FIG. 4, a firmware update utility invokes a system abstraction layer (SAL) update procedure call  420 , or SAL procedure interface. Here the SAL update procedure is directed to the new firmware component, e.g. a new input binary, to be added to the non-volatile memory. The new firmware component, or new input binary, is provided by a data storage disk, over the Internet, or through a server network as described in connection with FIG.  1 . The SAL procedure then takes over  430  to lead the update procedure and can at this stage perform preliminary security checks and authentication of the new input binary. Additionally, the SAL procedure ensures that the new versions of PAL binary blocks  221  are compatible with all the processors within the system configuration  100  to ensure successful boots subsequently. 
     In an alternative embodiment for a run-time update, the SAL procedure interface selects the lead processor in coordination with an operating system for the electronic system of FIG.  1 . In both embodiments, the other processors are kept in an idle loop and will not contend or conflict with the resources that the SAL procedure interface requires to perform the update of the non-volatile memory. The SAL procedure interface will call an appropriate authentication routine  440  to be certain that the new input binary accords with trusted code from the vendor. In the case of a PAL update, the SAL procedure interface calls the PAL authentication routine from the PAL in the non-volatile memory. In the case of a SAL update, the SAL procedure will call the vendor specific SAL authentication routine. Once the authentication process is complete, the SAL procedure will call the specific non-volatile memory implementation routine needed  450 . For example, the SAL procedure will call the appropriate platform implementation specific non-volatile memory erase and write functional modules for a successful completion of the firmware update. Again, this is done with the SAL procedure working in coordination with the operating system (OS) of the electronic system. 
     In certain embodiments of non-volatile memory such as FLASH memory, further writes to the non-volatile memory blocks containing code will be prevented by setting certain lock bits associated with the non-volatile memory. After successfully completing the update of the relevant code blocks in the non-volatile memory, in one embodiment, the SAL procedure can reset the electronic system, so that all the processors will load and execute the new input binary, or updated firmware. In an alternative embodiment, the OS will copy the new input binary into other memory, e.g. RAM, of the electronic device and bring all of the other processors to an active state with SAL coordination  460 . The OS and/or SAL firmware will also take appropriate actions to eliminate portions of the old binary that may be present within the processors&#39; cache memory. If the system is to execute the updated firmware without rebooting the system, the Operating system has to co-operate with the update process and re-register all the PAL firmware procedural entry points with the SAL firmware and provide appropriate mappings for the same. In this embodiment, there is no down time for the electronic system and the electronic system functions as a highly reliable, available and serviceable (RAS) system. 
     This method is capable of not only preventing a virus attack but also at the same time allowing valid binaries supplied by the processor vendor to be integrated into the non-volatile flash ROM device. This type of update allows system firmware to be upgraded in the field by the end user with an OS hosted utility and at the same time guarantees that the updated code is the vendor trusted code. This method allows the processor architecture to be updated with patches for bug fixes and also allows processor upgrades on the system.