Patent Application
20110119474
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
This disclosure relates generally to a gaming system and, more particularly, to a system and methodology for providing a field upgradeable a BIOS chip that does not require physically replacing the BIOS chip.
The Basic Input Output System (BIOS) provides hardware specific initialization to computers. The BIOS boot firmware is the first code run by a CPU when a computer system is powered on. The functionality provided by a BIOS chip is to detect and initialize the system components as a video card, a network card, serial ports, and a compact flash (CF).
Supporting EPROM based BIOS becomes increasingly challenging due to unavailability of EPROM in bigger sizes (e.g., 8 MByte) to fit in Vendor BIOS (ever increasing in size), the size of the latest kernel (to support the latest chipset), and a more secure ECC based Game Guardian authentication code. The increasing numbers of the CPU manufacturers have been moving away from EPROM based BIOS to SPI BIOS making it to difficult to run the first code from EPROM-based BIOS.
It would be desirable to be able to upgrade a BIOS chip in the field, without physically replacing the BIOS chip.
Briefly, and in general terms, various embodiments are directed to a serial peripheral interface-based (SPI-based) BIOS system for improved upgrading of a BIOS software image in a gaming machine. The system includes a flash BIOS chip and a SPI BIOS chip. The flash BIOS chip is operable to be written to by an Intel chipset for storage of an onboard Ethernet controller's information, wherein the flash BIOS chip may contain a new BIOS software image. The SPI BIOS chip comprises a traditional BIOS including gaming extensions to the BIOS. The SPI BIOS chip can be disabled from write actions at a jumper/circuit-level. When a SPI BIOS write enable jumper circuit is ON, a write protect pin of the serial peripheral interface BIOS is in the disabled state. In this regard, when the write protect pin is in the disabled state, the SPI BIOS content may be updated to the new BIOS software image from a BIOS install compact flash. When the BIOS write enable jumper circuit is OFF, the write protect pin of the serial peripheral interface BIOS is in enabled state. In this regard, when the write protect pin is in the enabled state the serial peripheral interface BIOS content cannot be updated.
Another embodiment is directed towards a multiple BIOS method for improved upgrading of a BIOS software image in a gaming machine. The method includes: introducing new BIOS content to a gaming platform on a BIOS update compact flash; booting the gaming machine from a primary BIOS; authenticating the new BIOS content of the BIOS update compact flash using the primary BIOS; flashing the primary BIOS from the new BIOS content; reading the new BIOS content on the primary BIOS using the BIOS update compact flash and verifying the flash was performed correctly; and rebooting the gaming machine for the primary BIOS to boot from newly flashed content.
Other features and advantages will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example, the features of the various embodiments.
Various embodiments disclosed herein are directed to gaming devices having a system and method for implementing a Serial Peripheral Interface-based (SPI-based) change that improves the upgrading of a BIOS software image. In this manner, the BIOS performed authentication of the BIOS CF (compact flash), lessens a security risk by assuring that there is no BIOS upgrade until authentication. On the Alpha I/II gaming platform, the BIOS code contains a Linux kernel, certain kernel modules, and Game Guardian® based authentication code. Described herein are BIOS implementation and BIOS type, as well as a method for updating the BIOS firmware in the ALPHA II gaming platform. Changes to the SPI-based BIOS improve the process for upgrading the software image of the BIOS. The BIOS is the root of trust, and currently is on the socket.
The Alpha II gaming platform employs two Serial Peripheral Interface BIOS chips. The first chip is designed to be written to by the Intel chipset, specifically for the storage of the onboard Ethernet controller's information. The second chip contains the true BIOS including the gaming extensions to the BIOS. In compliance with the NGCB (Nevada Gaming Control Board) regulations, the second BIOS, which contains the control program, must be circuit-level disabled for write actions. Referring now to the drawings, wherein like reference numerals denote like or corresponding parts throughout the drawings and, more particularly to
In one embodiment, components 12 also include data files (which are any collections of data, including executable programs in binary or script form, and the information those programs operate upon), gaming machine cabinets (housings) 26, displays 28, or compact disk read-only memory (CDROM) or CD read-write (CR-RW) storage. In one embodiment, the data files may include data storage files, software program files, operating system files, and file allocation tables or structures. Ports 30 are included with the gaming machine 10 for connection to diagnostic systems 32 and other input/output devices 34. In one embodiment, the ports 30 each comprise a serial port, a universal serial bus (USB) port, a parallel port or any other type of known port, including a wireless port. Preferably, each of the components 12 have embedded or loaded in them identification numbers or strings that can be accessed by the processor 14, including the processor 14 itself, which are utilized for authentication as explained below. In one embodiment, the components that are data files each use their file path and name as their identification number or string.
Either within the gaming machine 10, or in the diagnostic system 32 attachable to the gaming machine 10, are executable instructions or a software program 36 for authentication of the components (authentication software 36), which itself may be one of the components 12 to authenticate if it is internal to the gaming machine 10. In one embodiment, authentication software 36 is stored on a persistent storage media such as the hard disk device 16, ROM 20, EEPROM, in a complementary metal oxide semiconductor memory (CMOS) 38, in safe RAM comprising a battery-backed static random access memory (BBSRAM) 40, in flash memory components 42, 44, or other type of persistent memory. In one embodiment, the authentication software 36 is stored in a basic input/output system (BIOS) 22 device or chip. BIOS chips 22 have been used for storing prior authentication software, such as previous versions of the BIOS+ chip used by Bally Gaming Systems, Inc. of Las Vegas, Nev. in their EVO gaming system. Placing the authentication software 36 in the BIOS 22 is advantageous because the code in the BIOS 22 is usually the first code executed upon boot or start-up of the gaming machine 10, making it hard to bypass the authentication process. Alternatively, in one embodiment, the authentication software 36 is stored in a firmware hub (FWH), such as Intel's 82802 FWH.
As an alternative, instead of, or in conjunction with, the hard disk device, another mass storage device is used, such as a CD-ROM, a CD-RW device, a WORM device, a floppy disk device, a removable type of hard disk device, a ZIP disk device, a JAZZ disk device, a DVD device, a removable flash memory device, or a hard card type of hard disk device.
It should be noted that the term, gaming device, is intended to encompass any type of gaming machine, including hand-held devices used as gaming machines such as cellular-based devices (e.g., phones), PDAs, or the like. The gaming device can be represented by any network node that can implement a game and is not limited to cabinet-based machines. The system has equal applicability to gaming machines implemented as part of video gaming consoles or handheld or other portable devices. In one embodiment, a geo-location device in the handheld or portable gaming device may be used to locate a specific player for regulatory and other purposes. Geo-location techniques that can be used include by way of example, and not by way of limitation, an IP address lookup, a GPS, a cell phone tower location, a cell ID, a known Wireless Access Point location, a Wi-Fi connection used, a phone number, a physical wire or port on the client device, or by an accessed middle tier or backend server. In one embodiment, GPS and biometric devices are built within a player's client device, which in one embodiment comprises a player's own personal computing device, or is provided by the casino as an add-on device using USB, Bluetooth, IRDA, serial or another interface to the hardware to enable jurisdictionally compliant gaming, ensuring the location of play and the identity of the player. In another embodiment, the casino provides an entire personal computing device with these devices built in, such as a tablet-type computing device, PDA, a cell phone or another type of computing device capable of playing system games.
One embodiment of a Serial Peripheral Interface BIOS system is described herein with respect to
In this regard, only three masters can access the four regions:
1. A Host processor running BIOS code
2. An integrated Gigabit Ethernet
3. A Host process running Gigabit Ethernet Software, and Management Engine.
Preferably, each master is only allowed to perform direct reads of its primary regions. In one embodiment, the ALPHA II gaming platform is not utilizing the Management Engine feature. In this regard, the information in the Flash Descriptor may be written during the manufacturing process as its read/write permissions are set to “read only” after first write. In one such embodiment, the management engine, gigabit Ethernet, and platform data reside on a separate SPI chip other than the BIOS SPI chip.
With respect to the Serial Peripheral Interface BIOS in the Alpha II board, in one specific non-limiting embodiment, the Alpha II SPI Chip is 8 MByte in size and is on the socket.
The BIOS content layout of a single chip is illustrated in
Referring now to
The following describes the BIOS update method as shown in
The new BIOS content is introduced to the ALPHA II gaming platform on a Compact Flash. Once gaming machine is booted from the manufacturer-specific BIOS, the BIOS then authenticates the BIOS update compact flash. In this manner, an option is presented of upgrading the content of BIOS with the latest firmware (both part numbers are displayed to an operator authorized to perform this operation). The operator may then select to perfoiin the update operation by key-switching the operator key.
In one embodiment, the BIOS update software then starts flashing the BIOS. Once finished, the update software reads the BIOS content back and verifies that the flash was performed correctly. The status is displayed to an operator. The operator is required to reboot the MPU board for the BIOS to boot from the newly-flashed content. Interrupting the BIOS update process causes the BIOS chip to have to be replaced.
In one embodiment, the Serial Peripheral Interface BIOS improves overall system security over that of currently existing environments. With this new setup provided by the Serial Peripheral Interface BIOS system, once a gaming machine is programmed from the manufacturer, no other party can compromise it, as no such rogue software can be run on the system. Additionally, the need for a bigger-sized BIOS need is eliminated, which combined with the bigger BIOS, is harder and more expensive to obtain. Additionally, the Serial Peripheral Interface BIOS provides ease in upgrading the new BIOS image, given that no special burner is needed.
The following is a description of an enhanced Main Processing Unit (MPU) which serves as the principle control electronics for gaming machine components including the Serial Peripheral Interface BIOS. The Alpha II MPU enhances the Alpha control system by employing advanced technologies. Such technological components include: an Intel® GS45 chipset-based Core 2 Duo processor; up to 4G Byte Dual Channel DDR3 system RAM; 32 M Byte (16 MB per Bank) battery-backed, non-volatile RAM (expandable up to 64 MB); Serial ATA (SATA) based Solid State Hard Disk Drive for program storage; SPI based Flash BIOS; a PCIe x16 v2.3 expansion slot for Video Graphics card; a PCIe x1 expansion slot; Two ports with Gigabit Ethernet; Intel High Definition Audio; new backplane to support additional serial port, S/PDIF digital audio output, two (2) USB 2.0 ports and five (5) spare digital I/O; and two compact flash slots to perform installation and programming of Hard Disk Drive and BIOS, and clearing of non-volatile RAM.
The following sections of the document describe the use, contents and methods of programming: Solid State HDD (hard disk drive), Flash BIOS, and ACTEL Field Programmable Gate Array (FPGA).
Referring now to the Solid State HDD, a brief description of the partitions that exist on the hard disk is present with reference to
In one embodiment, the alpha support partition contains all of the files needed to run the Alpha Support operating system and provides the support code required to run games on the gaming machine. Preferably, two alpha support partitions are created on the hard disk. One is used as the primary partition which is mounted as the Linux Root partition when the system is booted. The other partition is used to install new Alpha support on the gaming machine. When new Alpha Support is saved in the backup partition, the backup partition becomes the primary partition and the previous primary partition becomes the backup partition. If the newly-installed Alpha Support fails to boot properly, a reboot defaults to using the previous Alpha Support partition that now resides in the backup partition. Once the newly-installed Alpha support has booted successfully, any subsequent boot failure causes the system to halt with an error.
Referring now to the installed game partition, the installed game partition contains an image file for the game to be run. The game can be one of the following: (1) a PVSSR Manifest based Game; (2) a DSS/DSA Manifest based Game; or (3) a DSS/DSA File Signature Table (FST) based game. After the game image has been mounted, the image appears the same as a compact flash.
In another aspect of one embodiment, the critical data partition is used to store critical data such as install logs, history tracking information, status and other critical data. No programs can be run from this partition. Executing clear on the platform deletes all the information stored in the critical partition.
In still another aspect of one embodiment, the scratch partition is used to store temporary files. These files include download packages, temporary message and video files, and the like. Any download packages stored in this partition are authenticated before being installed on another partition. No executable files are allowed to execute from this partition. Executing clear on the platform deletes all the information stored in the scratch partition.
Referring now to the formatting of the hard disk, a special compact flash called the Install Flash is booted on the gaming machine and used to partition and format the hard disk and to install installation packages. The entire hard disk is zeroed out during the format process. The installation packages reside on a Media compact flash.
With respect to data security, new technology introduced in the ALPHA II gaming machine no longer supports inhibiting writes to the Serial ATA based storage media via a hardware patch. The Serial ATA (SATA) support on the new Alpha platform differs from a traditional Parallel ATA interface. In SATA, the only method of communication is over two serial differential pairs. A transmit pair and a receive pair are used to send serial commands to the drive and also to read data from the drive. Protecting a SATA drive potentially requires logic to intercept certain hardware commands and enable other commands to pass through complex custom logic. This would introduce timing and signal integrity issues which would jeopardize data integrity as speeds have reached the 3 Gbit/second range. These methods would also be subject to becoming non-functional as SATA drive command sets are revised.
Write Protection on a Parallel ATA-based Hard Disk Drive was possible, because it is accessed using a discrete write strobe which may be inhibited as needed. With the advancement of technology, PATA interfaces have become obsolete and are being replaced by faster, higher-performance serial interfaces. The modern Intel Chipsets used today no longer support the PATA interface. As a result, a number of software measures are being taken to insure the security of the data on the hard disk. These different security measures create a number of levels of security to insure the integrity and authenticity of the data.
Referring now to software security measures, preferably, the authentication code and the public key used to perform the authentication of data are stored in the gaming machine's BIOS. The authentication support is initialized and activated during the BIOS boot process. The Alpha Support, Games and Jurisdiction data software parts are digitally signed. These signatures are authenticated before any code is executed from the above-mentioned parts. In one embodiment, the DSS/DSA (both manifest as well as File Signature Table) signed games have a digital security strength of 1024 bits. The Game Guardian® signed software parts have a digital security strength of 256 bits (equivalent to 3072 bits DSS/DSA algorithm).
Referring now to the boot process, as shown in
In an aspect of one embodiment, the Linux Kernel, Authentication, Memory Validation and Fault Manager Modules are loaded from BIOS into the system RAM. The Authentication module then reads and authenticates the contents of a Jurisdiction chip and the contents of all the manifest files stored on the ALPHA Support compact flash. Based on the type of the Game compact flash, if the Game flash contains manifest files, the files are authenticated. Otherwise, the contents of the entire game flash are authenticated using a DSS signature. If authentication in any of the above steps fail, the system fault is raised and no further booting of the system is allowed.
Once the authentication is completed, control is passed back to the Linux kernel to initialize the system operating environment and start the game. In addition to boot-time authentication, several other measures are taken during run-time. In this regard, as each read-only file covered by a File Authentication Manifest file is opened, the entire contents of the file is authenticated. If the contents of the file cannot be authenticated, a system fault is raised and no additional processing is allowed on the machine until the problem has been resolved.
In another aspect of one embodiment, a background kernel task that is part of the authentication code continuously authenticates the contents of the File Authentication Manifest files and all the files defined within them. If any of the files fail to authenticate, or if a file is missing, a system fault is raised, and the system is halted. Furthermore, in addition to the files being defined as read-only, the partitions in which the files are stored are also mounted as read-only. In one preferred embodiment, no code is allowed to execute from the Manifest, Critical Data and Scratch partitions. All of the above measures insure that only manufacturer-signed software is allowed to run on the system.
Referring now to information storage on the hard disk, any game or Alpha support that is to be stored on the hard disk is contained within an installation package. The installation package is either retrieved from a Package Compact Flash or from a Download Server. In this regard, packages are authenticated before they are installed on the hard disk.
In still another aspect of one embodiment, the clear flash program zeros out the NVRAM data storage and backplane EEPROM. The clear flash program then reads back to verify that all zeros were successfully written. In addition to NVRAM and backplane EEPROM, the clear flash program removes all files in the Critical Data Partition and Scratch Partition of the hard drive.
Referring now to installation from the media compact flash, to install a package from the package compact flash, the gaming machine is booted using the Install Flash. The Install Flash is a special compact flash that does not support running a game on the gaming machine. In this regard, the Install Flash only supports formatting the hard disk and installing packages onto the hard disk.
The installation package from the compact flash to the hard disk is shown in
In one embodiment, the current and future released games that reside on a compact flash are treated as type of Install Flash that may be copied to the hard disk. In the case of current game compact flashes, the image of the complete game compact flash is copied onto the hard disk after the game compact flash has been authenticated. The signature of the legacy games is not changed regardless of the media (hard disk or compact flash) from which it is loaded and/or executed.
In one embodiment, the A3P1000FG484 Field Programmable Gate Array (FPGA), which is part of Actel's ProASIC3 family, is used on the ALPHA II printed circuit board. This family has the core FLASH (configuration FLASH) embedded into the component and is programmed via a JTAG port. ACTEL ProASIC3 on ALPHA II supports the following functionalities. First, the general I/O includes discrete In and Out registers, a general-purpose timer and player switches. Second, in one embodiment, the serial communication devices include twelve (12) 16550 equivalent UARTs to support peripherals (e.g., the Bill Validator, the Printer, and the like) and the SAS Host communication. Third, with respect to Non-volatile RAM (NVRAM), in one embodiment, up to 64 MBytes of non-volatile RAM (32 MB per bank) is supported on the platform. NVRAM access is 32-bit and read always returns full 32-bit DWORD, regardless of which bytes are enabled. Write actions can be any combination of BYTE, WORD or DWORD. To write to NVRAM, the NVRAM write enable register must be enabled. Finally, with respect to coin mechanisms and hopper FIFO (first in first out), in one embodiment, the FIFO is 15-bits wide by 63 WORDs deep, and is used to sample various status inputs that change too fast for standard polling techniques. This enables the states of the inputs to be monitored at regular time intervals, without interrupting the processor on every update. The sample rate is controlled by the Real-Time Latency Register (RTLR).
In another aspect of a preferred embodiment, the Alpha II hardware platform enables programming of FPGA via available JTAG connectors. There are several levels of security in this architecture as follows. With respect to the elimination of external configuration memories, since the configuration FLASH is embedded into the FPGA component and is programmed at the factory, there are no external program bit-streams available for monitoring. This prevents a third party from reading or writing the configuration code, via an external serial bitstream.
Additionally, the Alpha II hardware platform enables no read access to internal configuration. In this regard, the FLASH Configuration FLASH code is “write only.” Verification may only be performed by downloading the identical file to the FPGA and comparing the file (internally) to the existing configuration FLASH contents. Since the configuration FLASH isn't readable, the code is not available for upload and analysis. In this regard, trial and error would be impractical since the program code is several million bits long.
Referring now to message authentication control (MAC), to prevent internal damage to the FPGA from invalid configuration files, an authentication process (Actel proprietary) is in place. The MAC verifies that the code is valid before loading the code into the configuration FLASH. This procedure helps prevent erroneous code from being downloaded and reduces the risk of tampering. Moreover, with respect to verification, the internal contents of the configuration FLASH may be verified via the JTAG port, without compromising the code. Since the verification process occurs internally to the FPGA, the contents are never uploaded and remain secure.
As shown in
According to one embodiment, the main display 202 is a widescreen display (e.g., 16:9 or 16:10 aspect ratio display). In one embodiment, the display 202 is a flat panel display including by way of example only, and not by way of limitation, liquid crystal, plasma, electroluminescent, vacuum fluorescent, field emission, LCOS (liquid crystal on silicon), and SXRD (Silicon Xtal Reflective display), or any other type of panel display known or developed in the art. These flat panel displays may use panel technologies to provide digital quality images including by way of example only, and not by way of limitation, EDTV, HDTV, or DLP (Digital Light Processing).
According to one embodiment, the widescreen display 202 may be mounted in the gaming cabinet 204 in a portrait or landscape orientation. In another embodiment, the game display 202 may also include a touch screen or touch glass system (not shown). The touch screen system allows a player to input choices without using any electromechanical buttons 206. Alternatively, the touch screen system may be a supplement to the electromechanical buttons 206.
The main cabinet 204 of the gaming machine also houses a game management unit (not shown) that includes a CPU, circuitry, and software for receiving signals from the player-activated buttons 206 and a handle (not shown), operating the games, and transmitting signals to the respective game display 206 and speakers (not shown). Additionally, the gaming machine includes an operating system such as Bally Gaming's Alpha 05, as disclosed in U.S. Pat. No. 7,278,068, which is hereby incorporated by reference.
In various embodiments, the game program may be stored in a memory (not shown) comprising a read-only memory (ROM), volatile or non-volatile random access memory (RAM), a hard drive or flash memory device or any of several alternative types of single or multiple memory devices or structures.
As shown in
One of ordinary skill in the art will appreciate that not all gaming devices will have all these components or may have other components in addition to, or in lieu of, those components mentioned here. Furthermore, while these components are viewed and described separately, various components may be integrated into a single unit in some embodiments.
In some embodiments, the gaming machine 200 is part of a gaming system connected to or with other gaming machines as well as other components such as, but not limited to, a Systems Management Server (SMS) and a loyalty club system (e.g., casino management personnel/system (CMP/CMS)). Typically, the CMS/CMP system performs casino player tracking and collects regular casino floor and player activity data. The gaming system may communicate and/or transfer data between or from the gaming machines 200 and other components (e.g., servers, databases, verification/authentication systems, and/or third party systems).
An embodiment of a network that may be used with the system is illustrated in
The various embodiments described above are provided by way of illustration only and should not be construed to limit the claimed invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the claimed invention without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the claimed invention, which is set forth in the following claims.
