KR101120956B1 - Portable multi-platform booting systems and architectures - Google Patents

Abstract

The present invention relates to a method, system, and architecture for multiplatform booting from a portable module with nonvolatile memory. The portable module preferably has the correct binary number for booting the multi-system architecture, along with a table where the host can calculate the correct offset to load the proper binary number upon power up.

Description

PORTABLE MULTI-PLATFORM BOOTING SYSTEMS AND ARCHITECTURES

TECHNICAL FIELD This application generally relates to the field of computer systems, and more particularly, to systems and methods for multiple architecture bootstrapping from removable storage devices.

In order to mediate between application programs and underlying hardware, several layers of software and firmware architecture are used. First, when power is applied to the computer, the various hardware elements (chips and subsystems) will each have internal procedures (reset procedures) to restore a stable and known state. However, at some point (if the hardware is intact), these reset procedures will terminate, at which point the CPU performs various important overhead tasks. These include, for example, examining system configuration, performing sanity checks on system hardware, and allowing users to branch to NVRAM configuration programs under software control. This stage of operation is commonly referred to as "POST" (power-up-self-check).

After POST, the "bootstrap" (or "boot") program starts up automatically, causing the CPU to run other software. The boot program uses data from the master boot record, and on PC architecture the data is typically booted. The files are stored in sector 1 (512-byte area) of the drive where they are placed .. During execution, the master boot record loads the starting system file from disk into memory.After all operating system files have been loaded, the bootstrap program is operated. The bootstrap program starts the CPU when the main operating system software runs; depending on how the system is set up, the boot software can direct Vista, OS / X, Unix, or other operating systems to run the program. This is usually automatic and predetermined, but some At this point, the bootstrap program's task is terminated, and the operating system is then configured to allow the user to start whatever the initialization phases are configured for and ultimately which application is targeted. A computer can be used.

Although the above description relates to the world of computers, many low power portable electronic systems present similar problems. As the systems become more common and more versatile, the architecture of the system has several more tendencies. (Very low power consumption and customized I / O demands tend to form diversity.) Many of these devices have processor and / or memory specifications that are compatible with personal computers 10 years ago or so, and some have more. Many of these portable electronic designs are designed around one main application with other features added. For example, PDA (Personal Digital Assistant) phone designs may exhibit some differences in design depending on whether the manufacturer (or company) is based on phones or PDAs. Combining expensive computer power and battery energy is a powerful force for function convergence, but many portable electronics market segments represent indications of more specific origins. Various and complex portable electronic functions include game machines, telephones, music and movie players, cameras and video recorders, PDAs, position sensing, heart monitors, mixtures thereof, and image understanding security monitors, Newer features such as face recognition software, and collision avoidance. Thus, the extreme variety of hardware will continue, at least for the near future, while the convergence potential increases.

Many developments of portable electronics have been intended by content ownership. Music, videos, and games are frequently plagiarized, and the gap between the unit price paid by conscientious buyers and the average unit price received by copyright owners is a development burden. Thus, extreme efforts have been made to develop nonvolatile memory modules that make it impossible to destroy. Advanced memory modules, such as those sold by SanDisk, commonly include a processor that can execute encryption algorithms invisible to the host machine, so protected content cannot be accessed directly.

Even stronger security can be provided by the host's controlled software environment. This is not easily accomplished by the program of the nonvolatile memory module, but may be achieved when the system is booted from the nonvolatile memory module. In this case the boot program may restrict the loading of non-standard operating system components, and / or otherwise the load monitor handles the standard operating system components.

The first personal computers boot from removable disks (floppy disks), but may also boot from nonvolatile memory modules. U.S., incorporated herein by reference. See application 07 / 901,645.

Multiplatform booting is a more difficult problem. The bootstrap program must know which files should be loaded into memory before starting the operating system, and generally must know the limitations of file sequencing and memory locations. This varies widely depending on the operating system and hardware environment. For example, in 2006, SD cards could be inserted into a variety of systems, but many of these systems would not be able to execute IA32 instructions. ARM and PowerPC systems have only two alternative architectures for a wide range of applications where the IA32 is incompatible. Bootstrap type behavior on these systems cannot be achieved unless compatible binary files are provided for these platforms.

U.S., incorporated herein by reference. Patent 5,291,585 describes a personal computer with BIOS extensions. These BIOS extensions are indexed by their description table stored in the BIOS extension.

The present application discloses new methods of multiplatform booting from a portable storage module. The portable module has a table (or other data structure) that redirects various architectures and operating systems to various locations within the portable module to access appropriate binary files for booting.

For complete boot compatibility, the system's boot code preferably understands finding the table, and branch, of the module as appropriate. However, even if full boot compatibility is not achieved in all architectures, the disclosed embodiments can prevent boot incompatibility, that is, avoid indeterminate or other undesirable consequences of incorrect boot files.

The technical innovations disclosed in various embodiments provide one or more of the following advantages:

More diverse applications may be based on portable data modules. The advantage of cross platform compatibility will open up many new markets for porting targeted functions to any platform targeted by users.

Greater security can be ensured for portable data modules that are compatible with many platforms, including complex electronic systems not configured as personal computers.

A particular advantage of embodiments using SD cards is that the SD card specification is defined as a disk-like file structure-thus a PC bootable module can be easily achieved by adding MBR (Master Boot Record) to the existing configuration of the SD card. have.

An additional advantage is backward compatibility with existing PC architectures, while allowing many new applications for new architectures. This is particularly useful for applications where users expect to round trip activities between a portable device and a computer.

Another advantage of the disclosed inventions is easy and secure firmware update in mobile systems, or in a device (such as an appliance) that has substantially no permanent storage.

The disclosed inventions will be described with reference to the accompanying drawings, which show important sample embodiments of the invention and are incorporated herein by reference.

1 is a block diagram of a computer system.

FIG. 2 shows an example of a table for identifying memory locations of master boot records for another type of architecture.

FIG. 3 is a flow diagram illustrating a process for bootstrapping a computer system from a removable device capable of bootstrapping computer systems having a different architecture.

4 illustrates a general exemplary block diagram of a removable storage device including a sample embodiment.

Many of the innovative teachings of the present application will be described with specific reference to the presently preferred embodiments (by way of example, without limitation).

According to a sample embodiment, the removable nonvolatile memory includes a table stored at a predefined memory location of the removable nonvolatile memory, the table identifying a plurality of memory locations in the nonvolatile memory, the plurality of bootstrap codes Are stored in a number of memory locations associated with the table.

The predefined memory location is known by the basic input / output system (BIOS) of the computer system coupled to the removable nonvolatile memory and the table assigns a number of unique identifiers to each of the plurality of computer architectures and the associated number of memory locations respectively. Include. Identifiers can be indexed and multiple bootstrap code can include two or more of the following architecture types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x , Sh, Sh64, Sparc, and / or Sparc64. The predefined memory location may be a first logical block address (LBA) and the predefined memory location is located in accordance with the type of computer system architecture coupled to the nonvolatile memory in which the master boot record is removable. The master boot record may be located in one of a number of memory locations in removable nonvolatile memory.

According to other kinds of embodiments, a method executed in a computer system includes executing a basic input / output system (BIOS) for placing a predefined memory location in removable memory coupled to the BIOS, and predefined The stored memory locations have a table that identifies a plurality of memory locations in removable non-volatile memory in which a plurality of bootstrap codes for a plurality of computer architectures are stored. Run the BIOS to determine from the table the location of the bootstrap code associated with the identifier associated with the architecture type of the computer system, and load the bootstrap code into the computer system and run the BIOS to execute the bootstrap code.

The table preferably includes a plurality of identifiers each unique to a plurality of computer architectures and associated plurality of memory locations and the identifiers can be indexed. The BIOS code may be executed to copy the table to the computer system and retrieve the table, and the removable nonvolatile memory may be an SD memory card, a compact flash, a hard drive, or an optical disk. As noted above, multiple bootstrap code may include two or more of the following architecture types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh , Sh64, Sparc, and / or Sparc64. The predefined memory location may be a first logical block address (LBA) and the predefined memory location may be a location where the master boot record may be located according to the architecture type of the computer system. The master boot record may be located in one of a number of memory locations in removable nonvolatile memory.

According to another embodiment, a computer system includes a read only memory (ROM) having a basic input / output system (BIOS) code stored therein, wherein the BIOS code includes a number and knowledge of identifiers associated with the architecture type of the computer system. Knowledge of a predefined memory location having a table identifying a plurality of memory locations in a removable storage device having stored therein a plurality of bootstrap code for a computer architecture. The interface is coupled to the ROM and the processor is coupled to the interface, the processor executes the BIOS code to detect the removable storage device and, if detected, locates a predefined memory location and locates the bootstrap code associated with the identifier. Determine from the table, load the bootstrap code into the computer system, and execute the bootstrap code.

The table includes a plurality of identifiers, each unique to a number of computer architectures and a plurality of associated memory locations, which can be indexed. The processor may execute the BIOS code to copy the table to the computer system and retrieve the table and the removable storage device may be an SD memory card, a compact flash, a hard drive, or an optical disk as described above. Multiple bootstrap code may include two or more of the following architecture types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh, Sh64, Sparc , And / or Sparc64. The predefined memory location may be a first logical block address (LBA) and the predetermined memory location may be where the master boot record is located according to the architecture type of the computer system. The master boot record can be located in one of a number of memory locations in the removable storage device.

In other kinds of embodiments, the removable nonvolatile memory includes a table stored in a predefined memory location in the removable nonvolatile memory, the table identifying a plurality of memory locations in the nonvolatile memory, the plurality of computers Multiple applications associated with the architecture are stored in multiple memory locations associated with the table.

The predefined memory location is known by a computer system coupled to removable nonvolatile memory and the table includes a plurality of identifiers, each unique to a number of applications associated with the type of computer architectures. Identifiers can be indexed. As noted above, multiple applications may include two or more of the following architecture types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh, Sh64 , Sparc, Sparc64, Palm, Windows CE and / or Windows. The application can play music applications of various types of computer architectures, each of which can execute data files, such as music files, stored on removable non-volatile memory.

In accordance with embodiments of the present invention, systems and methods allow removable storage devices to provide a suitable or compatible master boot record for bootstrapping multiple computer systems having different types of architectures.

1 is a diagram of a hardware and operating environment in which embodiments of the inventions may be practiced. The description in FIG. 1 is intended to provide a general description of suitable computer hardware and suitable computing environment in which the present invention may be practiced.

The computer system 10 and the removable storage device 35 may include the removable computer storage device 35 (eg, IA32, Intel® architecture) and some of the names Arm ?, Alpha? And Sparc. Implement the principles of the present invention to provide bootstrap code suitable for various other types of computer architectures, such as. In accordance with the principles of the present invention, the removable storage device 35 can be removed from the computer system 10 and operably coupled to other systems with other architectures, where the removable storage device 35 is compatible. Possible master boot records and bootstrap programs can be provided for various types of computer architectures. The master boot record contains bootstrap code, which is a boot loader or program that starts the operating system kernel. Both are programs that load the operating system into system memory when executed by a processor. Exemplary boot loaders are the Grand Unified Boot Loader (GRUB) or system commander. The master boot record and bootstrap program are considered boot code.

The exemplary hardware and operating environment of FIG. 1 for practicing the inventions is operatively coupled to processor 15 with various system components including processor 15, system memory 25, system memory 25. A programmable device in the form of a system bus 30. There may be only one or more processors 15, so that the processor of the computer system 10 includes a single central processing unit (CPU), or multiple processing units, generally referred to as a parallel processing environment. Computer system 10 may be a conventional computer or any other type of computer; Accordingly, the present inventions are not limited.

System bus 30 may be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory 25 is referred to simply as memory and includes read only memory (ROM) 40 and random access memory (RAM) 45. The basic input / output system (BIOS) program 50 is code that includes basic routines or programs that are stored in the ROM 40 and assist in transferring information between elements within the same computer system 10 during the startup discussed below. It includes. Computer system 10 further includes an optical drive 65, such as a hard drive 55 and a CD ROM or other optical medium.

Hard drive 55 and optical drive 65 are connected to system bus 30 by a hard drive interface and an optical drive interface, respectively. The drives and associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for the computer system 10. Any type of computer readable medium that can store data accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAM), read-only memories (ROM), and the like. Should be implemented that can be used in an exemplary operating environment. Multiple program modules are stored on hard drive 55, optical drive 65, ROM 40, or RAM 45, and operating system 70, one or more application programs 75, and others. Program modules 80, and program data 85.

In an exemplary embodiment of the present invention, removable storage device 35 is a hard drive that conforms to the logical block addressing (LBA) partitioning method for PC computers. According to an embodiment of the invention, a table 45 is stored in sector 1 of offset (0x3E) of removable storage device 35 and master boot records 60-1 through 60- in other block locations. y) is included, where y is a number greater than one. Table 45 identifies various memory locations within removable storage device 35 where various master boots compatible with different types of computer architectures (e.g. IA32, Alpha ?, Sparc ?, to name a few) are available. Records 60-1 through 60-y are placed. As noted above, in this particular embodiment of the present invention, the architecture type of computer system 10 is an Intel® Platform-Windows® operating system. Thus, in order for the computer system 10 to be bootstrapped by the removable storage device 35, the at least one master boot record 60-1 through 60-y stored in the removable storage device 35 is Intel? -Windows® architecture compatible. The remaining master boot records are compatible with the type of computer architecture that removable storage 35 wants to support.

2 illustrates an example table 45 that identifies various memory locations within removable storage device 35 in which various master boot records are located that are compatible with various types of computer architectures. The BIOS program 50 stored in the ROM 40 of the computer system 10 and all other BIOS programs stored in the computers that wish to interface with the removable storage 35 may be compatible with the table 45. In this embodiment of the present invention, the exemplary table 45 has two columns, an identifier column 205 and an architecture column 210. Identifier column 205 lists each identifier (denoted 205-1 through 205-x) for each type of computer system architecture, where x is a number greater than one. In this particular embodiment, x is 17 because there are 17 different architectures that removable storage 35 can support. The identifiers consist of unique eight byte entries that serve as indices and indicate a unique location of the identifier column 205.

Each type of computer system architecture is assigned a unique identifier that identifies the type of computer system architecture. Such identifiers are stored, mounted or " burned " in the ROM of each computer system intended to interface with a removable storage device designed in accordance with the present invention. The identifiers can work with the BIOS program of the remaining computer system. It is also used to identify the architecture type of a computer system.

In this embodiment of the invention, the exemplary identifier "8686" is assigned to the Intel®-Windows® architecture. The identifier "8686" is "burned" into the ROM 40 and made part of the BIOS. It should be noted that all other computer systems with the Intel®-Windows® architecture will have the same identifier "8686" "burned" into ROM. Of course, computer systems with different types of architectures, such as Alpha, will have different identifiers, such as "2218" "burned" to ROM, for example. As noted above, an identifier represents a particular type of computer architecture or platform. Thus, the architecture type of a computer system can be determined by reading the identifier. Each identifier is also associated with a corresponding entry in the architecture column 210 of the table 45.

The table 45 includes an architecture column 210 that lists memory locations (denoted 210-1 through 210-x) for the master boot record for the various computer architectures supported by the removable storage device 35. . As mentioned above, x is 17. Although there is one identifier for each of 17 different architectures, removable storage 35 does not store 17 master boot records that are not available. Thus, the table 45 may represent the identifier "7999" assigned to the Arm? Architecture, but the removable storage 35 is stored therein, for example, to save memory space discussed later in more detail. It may be desirable not to have a compatible master boot record.

Memory location entries in architecture columns 210-1 through 210-17 are block addresses indicating that master boot records for the various architectures are placed in removable storage 35. Every entry in architecture column 210 is six bytes, where the first four bytes represent a logical block address (LBA) offset. LBA offset indicates that the master boot record for a particular architecture remains in removable storage 35. The other two bytes represent a binary length as multiple LBA sectors. The removable storage device 35 uses a logical block address method, which among other things includes translating the logical block address location into physical block address locations on the removable storage device.

In summary, identifiers (denoted 205-1 through 205-17) are associated with memory locations 210-1 through 210-17 where master boot records and bootstrap programs are stored. Thus, if an identifier of a particular type of computer architecture is known, the table 45 places a bootstrap program (e.g., a boot loader) stored in the removable storage device 35 and a compatible or corresponding master boot record. Can be used to

As noted above, although there is one identifier for each of the 17 different architectures in table 45, removable storage 35 does not store the 17 master boot records that have become unavailable. In situations where it is desirable not to include a master boot record for a particular type of architecture, null or "0" values indicate empty entries in the architecture column 210 corresponding to identifiers of an unsupported architecture type. To be used. For example, if the removable storage device 35 does not support the Cris® architecture, the identifier "7853" is associated with null or "0" values in the architecture column 210 rather than having a memory location. In addition, the removable storage 35 does not store a compatible master boot record for the Cris® architecture, thus saving memory space. Referring to table 45, the Cris® architecture memory location (indicated by 210-3) has an entry "0000". The first entry of the table 45 is the index "0" (denoted 220) with the corresponding value x86 HLT (0xF4) (denoted 215). The x86 HLT (0xF4) opcode is an abort instruction that prevents previous Intel® architectures from erroneously executing any master boot record in removable storage 35.

3 shows a flowchart of a method performed by computer system 10 and removable storage 35 in accordance with an exemplary embodiment. When computer system 10 is turned on, processor 15 proceeds to a memory location in ROM 40 and begins executing BIOS program 50 (block 305). In any Intel® Windows® architecture, the BIOS program 50 performs a power on self test (POST) and a master boot record lookup. The BIOS program 50 is a device that is part of and is coupled to a computer system 10 such as, for example, an optical drive 65, a hard drive 55, and a universal serial bus operably coupled to an interface 90. Have them. Thus, the BIOS program 50 can interact with the devices and detect the devices. For example, the device may interact with and detect the removable storage device 35.

In prior art systems, upon identifying the drive on which the master boot record is located, the BIOS program will display sector 1 (512 byte area), LBA # 0 of the device where the master boot record is stored, and offset 0x3E (448 byte area) where the bootstrap code is stored. Find). The BIOS program copies the master boot record into RAM and passes control to the master boot record. The master boot record controls the computer system and loads code until it is no longer needed.

According to an embodiment of the invention, the table 45 is stored in the sector 1 of the storage device 35 which is removable than the master boot record. The master boot record and bootstrap code are relocated to one of the memory locations 60-1 through 60-y of the removable device 35 in accordance with the table 45, where y is in the removable storage device 35. It is equal to the number of master boot records stored. Also in accordance with an embodiment of the present invention, the master boot record and bootstrap code are stored between other master boot records and bootstrap codes, each of which is compatible with other types of computer system architectures. Referring to FIG. 2, the memory location of the bootstrap code for the master boot record and the Intel®-Windows® architecture is XXX (denoted 210-4).

Thus, BIOS program 50 reads table 45 located in sector 1 and reads ROM 40 to locate the master boot record and bootstrap code that is compatible with the architecture of computer system 10. Use the identifier burned in. In addition, the BIOS program 50 is configured to select information and to execute the options from the table 45. Optionally, the information and options in table 45 are selected and executed via a program stored in ROM 40 that works with BIOS program 50.

Referring again to FIG. 3, processor 15 continues to execute BIOS program 50 to identify removable storage drive 35 and access table 45 located at a predefined memory location (block 310). . In this example, the predefined memory location is sector 1 (512 byte area) and offset 0x3E (448 byte area) of the more specifically removable storage device 35. Knowing the identifier for computer system 10, BIOS program 50 places identifier " 8686 " (denoted 205-4) in table 45 (block 315). As mentioned above, according to an embodiment of the present invention, the identifier serves as an index. Thus, the BIOS program 50 finds a specific position in the table 45 without repeating through the table. As noted above, in this embodiment, computer system 10 is based on an Intel®-Windows® architecture assigned an "8686" identifier.

In turn, BIOS program 50 reads a memory location entry in architecture column 210 associated with identifier " 8686 " (block 320). In this embodiment, the entry of the architecture column 210 associated with the identifier "8686" is XXXX (denoted 210-4), which represents a memory location where a compatible master boot record is placed in the removable storage 35. . LBA Method Next, the removable storage device 35 translates the logical block address into a physical block address indicating where a compatible master boot record is located on the medium. BIOS program 50 accesses the memory location at LBA offset xxx and copies the master boot record to RAM 45 (block 325). Computer system 10 executes the master boot record and passes control to the master boot record (block 330). The master boot record controls the computer system 10 and continues loading code until it is no longer needed, which includes loading the operating system of the computer system from the hard drive 55 to the RAM 45.

As noted above, in accordance with an embodiment of the present invention, removable storage device 35 may be detached from computer system 10 operably connected to a second computer system having a different architecture and booting the second computer system. Strap it.

For example, FIG. 4 shows a general exemplary block diagram of a removable storage device 35 in accordance with the methods and systems described above. In a first exemplary embodiment, removable storage device 35 is operatively coupled to computer system 410 that includes the Intel® architecture. When computer system 410 is turned on, the BIOS program accesses the identifiers in table 45. From the table 45, the BIOS program determines the location of the master boot record 430, copies the master boot record and stores it in the running computer system 410.

In a second exemplary embodiment, removable storage device 35 is operably coupled to computer system 420 that includes an Alpha® architecture. When computer system 420 is turned on, the BIOS program accesses the identifiers in table 45. From the table 45, the BIOS program determines the location of the master boot record 440, copies it and stores it in the RAM of the computer system 420 to be executed.

The above merely illustrates the principles of the invention. It will therefore be appreciated that those skilled in the art will implement the principles of the present invention and will, accordingly, devise many other devices that fall within the spirit and scope of the present invention.

For example, based on the above disclosure, it is apparent that the removable storage device is a memory such as an SD memory card, a compact flash card, a multimedia card or other removable card or memory device and can easily accommodate the principles of the present invention.

Moreover, based on the disclosure, it is clear that the principles of the present invention can easily accommodate a table loaded in the RAM 45 of the computer system 10. In an exemplary embodiment of the present invention, the BIOS program of the ROM 40 places the table 45 stored in the removable storage device 35 and loads the table 45 into the RAM 45. The BIOS program repeats searching for an identifier matching the identifier stored in the ROM 40 through the table. As with the exemplary embodiments above, the identifiers represent several types of computer architectures, but in this embodiment the identifiers do not function as indexes and simply identify another type of architecture. Therefore, the BIOS program must repeatedly search through the table 45 for an appropriate identifier, rather than proceeding specifically to the appropriate identifier for the table 45, as in the case of having an identifier functioning as an index.

After the identifier is placed in the table 45, the BIOS program reads the memory location associated with the identifier and accesses the appropriate master boot record placed in the removable storage 35. The BIOS program copies the master boot record from the removable storage device 35 and loads it into the RAM 45 where the processor 15 executes the master boot record.

In this embodiment of the present invention, there are no empty entries (eg null or "0" values) in the architecture column of the table because the identifiers of this embodiment do not function as indexes. The table stores only the identifiers with the master boot record stored in the removable device 35 so that there are no empty entries in the table and smaller tables. For example, if you do not use a removable storage device 35 with a computer system with an Arm® architecture, there is no Arm ™ compatible master boot record stored in the removable storage device 35, There is no identifier or memory location. Of course, because the identifier does not act as an index, the BIOS program repeatedly places the identifier for the correct architecture through each identifier in the table.

In another embodiment of the invention, the computer system is operated and the operating system is already loaded. In this embodiment of the present invention, multiple applications are stored on a removable storage device (eg SD card). For example, three playback music applications may be stored on removable storage devices, each of which may be compatible with other computer architectures. When a removable storage device is operably coupled to a computer system, the removable storage device is recognized. An autonomous program that knows the identifier of the computer system and the table in the removable storage device locates the memory location where the playback music application associated with the identifier is located. Subsequently, the autopilot program loads a compatible playback music application on the computer system, where the application can play the content (data files, music files) stored on the removable storage device. Exemplary computer system architectures are Palm, Windows CE, and Windows.

In addition, the system is disclosed in the form in which various functions are performed by discrete functional blocks. However, any one or more of these functions may include one or more suitably programmed processes in which any one or more functions of these blocks operate software programs stored on various media or have functions programmed in firmware. The same may be implemented in a device implemented by the devices.

In addition, those skilled in the art will appreciate that the present invention may include other computer system configurations, including handheld devices, microprocessor systems, microprocessor based or programmable customer electronics, network PCs, minicomputers, mainframe computers, and the like. It will be appreciated that this can be done with

Finally, the present inventions may be implemented in a configured computer program storage medium (eg, CD-ROM, hard disk, RAM) that includes software for performing the methods.

According to various disclosed embodiments, an electronic system is provided; The electronic system includes at least one control processor; And a portable data module operably connected to access the control processor; The portable data module includes boot code for at least two mutually incompatible architectures; The portable data module includes a data structure indicating which of the boot codes require which of the incompatible architectures; The control processor can find the data structure at boot time and continues the boot process using any of the boot codes required by the architecture of the control discipline.

According to various disclosed embodiments, an electronic system is provided comprising: at least one control processor; A portable data module temporarily connected and thus temporarily accessible to the control processor; The portable data module includes boot codes for at least two mutually incompatible architectures, and a data structure indicating which of the boot codes the architectures require; And a stored initial command sequence, wherein the control processor is configured to execute upon power up and use the data structure to continue boot processing using any of the boot codes required by the architecture of the control processor. do.

According to various disclosed embodiments, a computer system is provided: the computer system includes a read only memory (ROM) having a basic input / output system (BIOS) code stored therein, wherein the BIOS code is a Know a predefined memory location with a table that identifies an identifier associated with the architecture type and that identifies a plurality of memory locations in the removable storage device where the plurality of bootstrap codes for the plurality of computer architectures are stored; An interface coupled to the ROM; And a processor coupled to the interface, wherein the processor executes the BIOS code to detect a removable storage device and, if detected, locates in a predefined memory location and locates the bootstrap location associated with the identifier from a table. Determine, load the bootstrap code on the computer system, and execute the bootstrap code.

According to various disclosed embodiments, a removable nonvolatile memory is provided, the removable nonvolatile memory comprising: a table stored at a predefined memory location of the removable nonvolatile memory, the table in a nonvolatile memory; Identify a plurality of memory locations; And a number of applications associated with a number of computer architectures stored in a number of memory locations associated with a table.

In accordance with various disclosed embodiments, a method is provided for operating a programmable system, the method comprising: a) an address specified by a data structure indicating different locations for different boot files depending on the architecture type of the system at startup; Retrieving a boot file for execution from the portable data module at; And b) using the boot file to automatically start the system into operation.

According to various disclosed embodiments, a method is provided for operating a programmable system, the method comprising: applying power to a system using an initial command sequence stored at a host system; And load several of the multiple boot files from the location of the portable data module specified by the data structure of the portable data module specifying different locations for different boot files according to the architecture type of the system under the control of the initial command sequence. Not loading multiple boot files; And using the boot file to automatically start the system in operation.

In accordance with various disclosed embodiments, a method is provided that executes on a computer system, the method comprising: executing a basic input / output system (BIOS) to locate a predefined memory location in a removable nonvolatile memory. Wherein the predefined memory location has a table identifying a plurality of memory locations in removable non-volatile memory in which a plurality of bootstrap codes for a plurality of computer architectures are stored; Executing a BIOS to determine from a table a location of bootstrap code associated with an identifier associated with an architecture type of the computer system; And executing the BIOS to load the bootstrap code into the computer system and to execute the bootstrap code.

In accordance with various disclosed embodiments, methods, systems, and architectures for multiplatform booting from a portable module with nonvolatile memory are provided. Preferably the portable module has the correct binaries for booting the multi-system architecture along with a table where the host can calculate the correct offset to load the proper binary upon power up.

Modifications and variations

As will be appreciated by those skilled in the art, the innovative concepts described in this application are modified and varied over a vast range of applications, and therefore the scope of the present patent subject matter is not limited to any of the specific illustrative instructions given. All such alternatives, modifications, and variations fall within the spirit and broad scope of the appended claims.

The system booting from the portable module can be not only a computer in the strict sense of the word, but also a gaming machine, PDA, or other complex system capable of running programs.

The portable module can follow any wide range of physical and electronic specifications for removable memory, including those that are not yet present, not SD or MS memory units.

The various operating systems and hardware architectures described above are merely examples-the disclosed inventions are applicable to a very wide range of environments that may appear in the future.

The table format and coding is not described in the above embodiments, but can of course vary widely as will be appreciated by those skilled in the art.

The table position does not need to have the position described in the above embodiments too. In one optional alternative, other versions of the table are included in other locations besides or instead of the table locations described above.

It is possible that booting from the portable module can be assisted manually. For example, a compact unit may allow the user to interact to set up a state that allows booting from the location specified in the data table in the portable module to which the loader program is attached, although the normal boot sequence does not branch into the portable module. Can be.

Nothing in the description of the present application is read to mean that any particular element, step, or function is an essential element that should be included in the claims: the scope of the patent subject matter is defined only by the allowed claims. In addition, none of these claims is intended to call graph 6 of 35 USC section 112 if no injection follows the correct words “means”.

The claimed claims are as inclusive as possible and the subject matter is not intentionally waived, dedicated or withdrawn.

As noted above, the present invention is used to provide a system and method for multiple architecture bootstrapping from removable storage devices.

Claims (54)

A removable memory system that interfaces with the host system for a single architecture type of boot for the host system. A memory including boot code for at least two mutually incompatible computer system architecture types and a data structure correlated with the incompatible architecture type according to a memory location of the boot code; And And a communication interface with the memory, the interface for removable interface with the host system. The interface receives a first request from a host system, wherein the first request of the host system is for accessing a data structure for identifying a memory location of the boot code based on a single architecture type of the host system , The interface receives from the host system a second request to load the architecture type boot code from a memory location of the boot code, wherein the second request is to initiate booting of the host system . The method of claim 1, wherein the memory is At least four mutually incompatible architectures of the computer system architecture type of boot code. 2. The memory system of claim 1 wherein the data structure is a table. The system of claim 1, wherein the memory system is And a cryptographic engine and memory space accessible only through the cryptographic engine. The method of claim 1, wherein the memory is And a boot file for the ARM and PPC architectures, along with a boot file for the at least one desktop computer architecture. The method of claim 1, wherein the data structure And store at a predetermined position in the memory. 2. The memory system of claim 1 wherein the computer system includes a telephone function. 2. The memory system of claim 1 wherein the host system is of a single architecture type. The method of claim 1, wherein the data structure And correlate with at least one architecture type having an indicator indicating a memory system that does not support booting for at least one architecture type. As a computer system, A stored identifier for identifying an architecture type of the computer system; Read-only memory (ROM) having a basic input / output system (BIOS) code stored therein, wherein the BIOS code is a plurality of memories in a removable storage device storing the identifier and a plurality of bootstrap codes for a plurality of computer architectures. Read-only memory (ROM) having knowledge of a predefined memory location having a table identifying the location; An external interface for interfacing with the removable storage device; And A processor in communication with the ROM and the external interface, the processor executing the BIOS code, detecting the removable storage device and, if detected, placing a predefined memory location in the removable storage device; The identifier is used to determine the location of bootstrap code compatible with an architecture type of a computer system from the table, to load the bootstrap code into the computer system, and to start booting the computer system. And the processor to execute the computer system. The method of claim 10, wherein the table is And a plurality of identifiers, each unique in a plurality of computer architectures and a plurality of associated memory locations. 11. The computer system of claim 10 wherein the identifier is an index. The processor of claim 10, wherein the processor A computer system for copying a table to a computer system and executing BIOS code to retrieve the table. The device of claim 10, wherein the removable storage device is At least one of an SD memory card, a compact flash, a hard drive, and an optical disk. 11. The method of claim 10, wherein the plurality of bootstrap code is A computer system comprising at least two of architecture types IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh, Sh64, Sparc, and Sparc64. The method of claim 10, wherein the predefined memory location is And a first logical block address (LBA). 11. The method of claim 10, wherein the predetermined memory location is And wherein the master boot record is the location where the master boot record is located according to the architecture type of the computer system. 18. The system of claim 17, wherein the master boot record is And at one of a plurality of memory locations within said removable storage device. The computer system of claim 10, wherein the computer system is A computer system comprising a single architecture type. A method of booting a host computer system using removable memory that interfaces with the host system, Applying power to the host computer system using an initial sequence of instructions stored in the host computer system; Detecting the removable storage device interfacing with the host computer system via an external interface; Identifying an architecture type of the host computer system and reading an identifier stored in the host computer system; The predefined memory has a table identifying a plurality of memory locations in a removable storage device having stored therein a plurality of bootstrap code for a plurality of computer architectures, the method comprising: placing a predefined memory location on the removable storage device; Using the identifier to determine a location in the removable storage of bootstrap code that is compatible with the architecture type of the host computer system; Loading the bootstrap code into the host computer system; And Executing bootstrap code to initiate booting of the host computer system. 21. The method of claim 20, wherein locating a predefined memory location in the removable storage device Copying the table from the removable storage device to the host computer system. 22. The system of claim 21, wherein said host computer system is Boot method, characterized in that consisting of a single architecture type. The method of claim 21, And determining, by the removable storage device, whether the booting of the architecture type of the host computer system is supported using the identifier. The method of claim 23, wherein the table is And correlating with the architecture type of the host computer system having an indicator that the removable storage device does not support booting of the architecture type of the host computer system. delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete

Images