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

Portable multi-platform booting systems and architectures Download PDF

Info

Publication number
TWI441077B
TWI441077B TW96151677A TW96151677A TWI441077B TW I441077 B TWI441077 B TW I441077B TW 96151677 A TW96151677 A TW 96151677A TW 96151677 A TW96151677 A TW 96151677A TW I441077 B TWI441077 B TW I441077B
Authority
TW
Taiwan
Prior art keywords
computer system
memory
system
storage device
removable storage
Prior art date
Application number
TW96151677A
Other languages
Chinese (zh)
Other versions
TW200844850A (en
Inventor
Paul Mcavoy
Original Assignee
Sandisk Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US11/618,870 priority Critical patent/US20080162916A1/en
Priority to US11/618,872 priority patent/US7925875B2/en
Application filed by Sandisk Technologies Inc filed Critical Sandisk Technologies Inc
Publication of TW200844850A publication Critical patent/TW200844850A/en
Application granted granted Critical
Publication of TWI441077B publication Critical patent/TWI441077B/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/22Microcontrol or microprogram arrangements
    • G06F9/24Loading of the microprogram
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4406Loading of operating system
    • G06F9/441Multiboot arrangements, i.e. selecting an operating system to be loaded
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44536Selecting among different versions
    • G06F9/44542Retargetable

Description

Portable multi-platform boot system and architecture

The present application is generally directed to the field of computer systems and, more particularly, to systems and methods for multi-architecture self-starting of self-removable storage devices.

In order to serve as a medium between the application and the underlying hardware, several layers of software and firmware structures are used. When electrical energy is initially applied to the computer, the various hardware components (wafers and subsystems) will each return their own internal program (reset procedure) back to a stable and known state. However, at some point (if the hard system is complete), these resets will have ended, and at this point, the CPU performs various important management tasks. These management consuming tasks include, for example, investigating system configuration, performing a sanity check on the system hardware, and allowing the user to branch to the NVRAM configuration program under software control. This phase of operation is often referred to as "POST" (boot self test).

After POST, the "self-start" (or "start") program is automatically started to allow the CPU to start executing other software. The boot program uses the data from the master boot record. In the PC architecture, the master boot record is typically stored in section 1 (512-bit field) of the drive, and the boot file is located in the drive. At execution time, the master boot record loads the initial system file from the disc into memory. The self-starter launches the operating system after all operating system files have been loaded. The self-starter program causes the CPU to begin executing the main operating system software; depending on how the system is set up, the boot software can direct program execution to Vista, OS/X, Unix, or another operating system. This is usually automatic And scheduled, but in some systems, this user can manually select. At this point, the work of the self-starting program ends. The operating system then performs any initialization steps that have been configured for it, and finally the user can use the computer to launch any desired application.

The above description relates to the computer field, but many low power portable electronic systems present similar problems. As systems become more prevalent and more versatile, their architectures have become more diverse. (The demand for very low power consumption and custom I/O is prone to discrepancies.) Many of these devices have processor and/or memory specifications comparable to personal computers about a decade ago, and some There are more devices. Many of these portable electronic product designs are designed around a primary application while incorporating other features. For example, depending on whether the product (or company) is based on the phone or on a PDA (personal digital assistant), the PDA phone design can show some design differences. The combination of expensive computing power and battery power is a powerful force for functional convergence, but many of the portable electronics market segments still show signs of more specific origin. Various complex portable electronic product functions including game consoles, telephones, music and movie players, cameras and video recorders, PDAs, position sensing, heart monitors, a mix of such devices, and may also include such as image understanding New features for safety monitors, face recognition software and collision avoidance. Therefore, even as the likelihood of convergence increases, the extreme diversity of hardware will continue at least in the near future.

Content ownership has driven many developments in portable electronics. Music, video and games are frequently pirated, and the difference between the unit price paid by honest buyers and the average unit price received by copyright owners is the development negative. Therefore, every effort has been made to study non-volatile memory modules that cannot be destroyed. Advanced memory modules, such as those sold by SanDisk, typically contain a processor that performs an encryption algorithm that is not perceptible to the host, making it impossible to directly access protected content.

More advanced security can be provided by the controlled software environment in the host. This is not easily achieved by a program in a non-volatile memory module, but this can be achieved when the system is booted from a non-volatile memory module. In this case, the launcher can limit the loading of non-standard operating system components and/or load monitoring processes other than the standard operating system components.

The original PC was booted from a removable disk (floppy), but attempts have been made to allow booting from a non-volatile memory module. See U.S. Application Serial No. 07/901,645, which is incorporated herein by reference.

Multi-platform startup is a more difficult issue. The self-starter must know which files must be loaded into the memory before starting the operating system, and usually must also understand the file ordering and memory location constraints. This depends on the operating system and the hardware environment. For example, since 2006, SD cards can be plugged into many systems, but a significant portion of their systems will not execute IA32 instructions. ARM systems and PowerPC systems are just two alternative architectures that are widely used and are not compatible with IA32. Self-initiated behavior cannot be achieved on such systems unless a compatible binary file is provided for their platform.

A personal computer with a BIOS extension is described in U.S. Patent No. 5,291,585, which is incorporated herein by reference. These BIOS extensions are indexed by a self-describing feature table, which is also stored in the BIOS extension.

This application discloses a new method for booting from a multi-platform of a portable storage module. The portable module carries a table (or other data structure) that redirects various architectures and operating systems to different locations within the portable module to access the appropriate binary file for booting.

In order to achieve full boot compatibility, the system's boot code is better known to view the module's table and branch appropriately. However, even if full startup compatibility is not achieved in all architectures, the disclosed embodiments can help prevent startup incompatibilities, i.e., due to mis-starting files or other undesirable outcomes.

In various embodiments, the disclosed innovations provide at least one or more of the following advantages: ̇ More applications can be based on a portable data module. The benefits of cross-platform compatibility will open up many new markets for porting desired functionality to any platform the user wants.

更 ensures more advanced security for portable data modules that are compatible with many platforms, including complex electronic systems that are not configured as personal computers.

A particular advantage of the embodiment using an SD card is that the SD card specification is defined by the file structure of the disk, so that the PC can be easily achieved by adding the MBR (Master Boot Record) element to the existing organization of the SD card. The module that is activated.

Another advantage is the backward compatibility with existing PC architectures while allowing many new applications for the new architecture. This expects users to be active in their activities. The application of shuttle between the device and the computer is especially useful.

Another advantage of the disclosed invention is that the firmware update in a mobile system or a device that is substantially free of permanent storage, such as an appliance, is easy and safe.

Numerous innovative teachings of the present application are described with particular reference to the presently preferred embodiments, by way of example, and not limitation.

According to an exemplary embodiment, a removable non-volatile memory includes: a table stored in a predefined memory location of the removable non-volatile memory, the table identifying the non-volatile memory a plurality of memory locations; and a plurality of self-starting codes associated with a plurality of computer architectures stored in the plurality of memory locations associated with the table.

The predefined memory location is known as a basic input/output system (BIOS) coupled to the computer system of the removable non-volatile memory, and the table includes a plurality of identifiers, each identifier for each identifier The plurality of computer architectures and associated plurality of memory locations are unique. The identifiers may be indexes, and the plurality of self-starting codes may include two or more of the following architectural types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64 , S390, S390x, Sh, Sh64, Sparc, and/or Sparc64. The predefined memory location can be a first logical block address (LBA), and the predefined memory location can be a master boot record according to a computer system coupled to the removable non-volatile memory The location where the schema type should be. The master boot record can be located in the plurality of memory locations in the removable non-volatile memory One of the settings.

According to another embodiment, a method performed on a computer system includes executing a basic input/output system (BIOS) to locate a predefined memory of a removable non-volatile memory coupled to the BIOS. a location of the memory, the predefined memory location having a table identifying a plurality of memory locations in the removable non-volatile memory, the plurality of self-starting code systems for the plurality of computer architectures being stored in the removable In volatile memory. Executing the BIOS to determine a location of the self-boot code from the table, associated with an identifier associated with an architectural type of the computer system, and executing the BIOS to load the self-boot code into the computer The self-start code is executed in the system.

The table preferably includes a plurality of identifiers, each of which is unique to the plurality of computer architectures and associated plurality of memory locations, and the identifiers can be indices. The BIOS code can be executed to copy the table to the computer system and search for the table, and the removable non-volatile memory can be an SD memory card, a compact flash card, a hard disk drive or a compact disc. As described above, the plurality of self-starting codes may include two or more of the following architectural types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh , Sh64, Sparc, and/or Sparc64. The predefined memory location can be a first logical block address (LBA), and the predefined memory location can be a location where a master boot record should be based on the architecture type of the computer system. The master boot record can be located in one of the plurality of memory locations in the removable non-volatile memory.

In accordance with 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 is associated with an architecture of the computer system a type-associated identifier and knowing a predefined memory location having a table identifying a plurality of memory locations within a removable memory device, the plurality of self-starting code systems for the plurality of computer architectures being stored Removable storage device. An interface is coupled to the ROM and a processor is coupled to the interface, the processor executes the BIOS code to detect the removable storage device, and if the removable storage device is detected, the processor The predefined memory location is located, a location of the self-activation code associated with the identifier is determined from the table, the self-activation code is loaded into the computer system, and the self-activation code is executed.

The table includes a plurality of identifiers, each of which is unique to the plurality of computer architectures and associated plurality of memory locations, wherein the identifiers can be indices. The processor can execute the BIOS code to copy the table to the computer system and search for the table, and the removable storage device can be an SD memory card, a compact flash card, a hard disk drive or a compact disc. As described above, the plurality of self-starting codes may include two or more of the following architectural types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh , Sh64, Sparc, and/or Sparc64. The predefined memory location can be a first logical block address (LBA), and the predetermined memory location can be a location where a master boot record should be based on the architecture type of the computer system. The master boot record can be located in the plurality of memory locations in the removable storage device One of the settings.

In yet another embodiment, a removable non-volatile memory includes: a table stored in a predefined memory location of the removable non-volatile memory, the table identifying the non-volatile a plurality of memory locations in the memory; and a plurality of applications associated with a plurality of computer architectures stored in the plurality of memory locations associated with the table.

The predefined memory location is known to the computer system coupled to the removable non-volatile memory, and the table includes a plurality of identifiers, each of which is associated with the plurality of computer architecture types Applications are unique. These identifiers can be indexes. As mentioned above, the plurality of applications may include two or more of the following architectural 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 applications can be music playback applications for various types of computer architectures, each of which is capable of executing data files stored on the removable non-volatile memory. For example, such data files are music files.

In accordance with an embodiment of the present invention, a system and method enables a removable storage device to provide an appropriate or compatible master boot record and self-start program to self-start various computer systems having various architectural types.

1 is a diagram of a hardware and an operating environment in which embodiments of the present invention can be practiced in conjunction with the hardware and operating environment. 1 is used to provide a general description of a suitable computer hardware and a suitable computing environment to which the present invention can be incorporated. Brain hardware and computing environment implementation.

The computer system 10 and the removable storage device 35 embody the principles of the present invention, wherein the removable storage device 35 provides a particular architecture type for the computer system 10 (eg, IA32, Intel) Architecture) and for various other types of computer architecture (such as Arm Alpha And Sparc , just to name a few examples of the appropriate self-start code. In accordance with the principles of the present invention, the removable storage device 35 can be removed from the computer system 10 and operatively coupled to other systems having different architectures, wherein the removable storage device 35 can be provided for different types of computer architectures. Compatible with master boot record and self-starter. A master boot record includes a self-start code that initiates a loader or a program for one of the cores of the starting operating system. They are all programs that load an operating system into system memory when executed by a processor. The instance boot loader is the Grand Unified Boot Loader (GRUB) or System Commander. The master boot record and the self-starter are treated as boot code.

The exemplary hardware and operating environment of FIG. 1 for implementing the present invention includes a programmable device in the form of a computer system 10 including a processor 15, a system memory 25, and a system bus 30, system sink Row 30 operatively couples various system components including system memory 25 to processor 15. There may be only one processor 15 or more than one processor 15 such that the processor of computer system 10 includes a single central processing unit (CPU) or a plurality of processing units (commonly referred to as a parallel processing environment). Computer system 10 can be a conventional computer or any other type of computer; the invention is not so limited.

The system bus 30 can be any of a plurality of bus structure structures including a memory bus or memory controller, a peripheral bus, and a use of any of a plurality of bus architectures. Regional bus. System memory 25 may also be referred to simply as memory and includes read only memory (ROM) 40 and random access memory (RAM) 45. A basic input/output system (BIOS) program 50 is stored in ROM 40 and contains code containing basic programs or programs that facilitate transfer between components within computer system 10, such as during startup. Information, as discussed in detail below. The computer system 10 further includes a hard disk drive 55 and a compact disk drive 65 such as a CD ROM or other optical medium.

The hard disk drive 55 and the optical disk drive 65 are respectively connected to the system bus 30 via a hard disk drive interface and a CD player interface. The drives and their associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for computer system 10. It should be recognized that any type of computer readable medium (such as a magnetic tape cartridge, a flash memory card, a digital video disc, a random access memory (RAM), a read only memory (which can store data accessible by a computer) can be recognized. ROM) and the like) can be used in an exemplary operating environment. A plurality of program modules can be stored on the hard disk drive 55, the optical drive 65, the ROM 40 or the RAM 45, and include an operating system 70, one or more application programs 75, other program modules 80, and program data 85.

In an exemplary embodiment of the invention, the removable storage device 35 is a hard disk drive that conforms to a logical block addressing (LBA) partitioning scheme for a PC. In accordance with an embodiment of the present invention, a table 450 is included in section 1 at offset (0x3E) of the removable storage device 35, and the master initiates record 60-1 to 60-y is included in other block locations, where y is a number greater than one. Table 450 identifies various memory locations within the removable storage device 35, and various master boot records 60-1 through 60 that are compatible with various types of computer architectures (eg, IA32, Alpha®, Sparc®, to name a few examples). -y is located at these locations. As mentioned above, in this particular embodiment of the invention, the architecture type of computer system 10 is the Intel® Platform-Windows® operating system. Therefore, in order to self-start the computer system 10 by the removable storage device 35, at least one of the master boot records 60-1 to 60-y stored in the removable storage device 35 is compatible with the Intel®-Windows® architecture. The remaining master boot records are compatible with the type of computer architecture that the removable storage device 35 is intended to support.

2 shows an illustrative table 450 that identifies various memory locations within the removable storage device 35 in which various master boot records that are compatible with various computer architecture types are located. The BIOS program 50 stored in the ROM 40 of the computer system 10 and all other BIOS programs stored in the computer intended to interface with the removable storage device 35 are compatible with the table 450. In the present embodiment of the invention, the illustrative table 450 has two columns, an identifier bar 205 and an architecture bar 210. The identifier field 205 lists each identifier (denoted as 205-1 to 205-x) for each computer system architecture type, where x is a number greater than one. In this particular example, x is equal to 17 because there are 17 different architectures that the removable storage device 35 can support. The identifiers serve as indices and consist of a unique 8-bit entry that represents a unique location in the identifier field 205.

Each type of computer system architecture is assigned a unique identifier that identifies the type of computer system architecture. This identifier is stored, equipped or "burned" to the intended In the ROM of each computer system that establishes an interface with a removable storage device designed in accordance with the present invention. This identifier can be operated by the BIOS of the computer system in which it is located. This identifier is also used to identify the type of architecture of its computer system.

In this embodiment of the invention, an exemplary identifier "8686" is assigned to the Intel®-Windows® architecture. The identifier "8686" is "burned" into the ROM 40 and becomes part of the BIOS. It should be recognized that all other computer systems with the Intel®-Windows® architecture will have the same identifier "8686" in the ROM of the computer system. Of course, a computer system with a different architecture type (such as Alpha®) will have a different name that is "burned" into the ROM of the computer system, such as "2218". As mentioned above, the identifier represents a particular type of computer architecture or platform. Therefore, the type of architecture of the computer system can be determined by reading the identifier. Each identifier is also associated with a corresponding entry in one of the schema columns 210 of the table 450.

The table (45) includes an architecture bar 210 listing the memory locations (denoted 210-1 through 210-x) of the master boot records of the various computer architectures supported by the removable storage device 35. As mentioned above, x is equal to 17. It will be appreciated that although there is one identifier for each of the 17 different architectures, the removable storage device 35 does not have to store or make 17 master boot records available. Thus, table 450 may indicate an identifier "7999" assigned to the Arm® architecture, but it may be desirable for removable storage device 35 not to store a compatible master boot record therein to, for example, save memory space, which would This will be discussed in more detail later.

The memory location entries 210-1 through 210-17 in the architecture column are block addresses indicating the location of the master boot records recorded in the removable storage device 35 for various architectural types. Each entry in the architecture column 210 is 6 bytes, with the first four bytes specifying a logical block address (LBA) offset. The LBA offset indicates where the master boot record of a particular architecture resides in the removable storage device 35. The remaining 2 bytes specify the length of the binary data as the number of LBA segments. The removable storage device 35 utilizes the logical block address scheme, wherein the scheme includes translating the logical block address location into a physical block address location on the removable storage device.

In summary, the identifiers (denoted 205-1 through 205-17) are associated with the memory locations (denoted 210-1 through 210-17) in which the master boot record and the self-start program are stored. Thus, if an identifier of a particular type of computer architecture is known, the table 450 can be used to locate a compatible or corresponding master boot record and self-starter (eg, boot loader) stored in the removable storage device 35. .

As mentioned above, although there is an identifier in table 450 for each of the 17 different architectures, the removable storage device 35 does not have to store or make 17 master boot records available. In the event that it is not desirable to include a master boot record for a particular type of architecture, a null value or a value of "0" is used to specify an empty entry in the schema column 210 that corresponds to an identifier of the unsupported schema type. For example, if the removable storage device 35 is not required to support the Cris® architecture, its identifier "7853" should be associated with a null or "0" value in the architecture column 210, rather than a memory location. Union. In addition, the removable storage device 35 will not store compatible master boot records for the Cris® architecture, from Save memory space. Referring to Table 450, the Cris® architecture memory location (denoted 210-3) can have a "0000" input. The first entry in table 450 is an index "0" (denoted 220) having a corresponding value x86 HLT (0xF4) (denoted 215). The x86 HLT (0xF4) job code is a shutdown command that prevents the old Intel® architecture from erroneously executing any master boot record in the removable storage device 35.

3 is a flow chart showing a method performed by computer system 10 and removable storage device 35, in accordance with an illustrative embodiment. When the computer system 10 is turned on, the processor 15 turns to a memory location in the ROM 40 and begins executing the BIOS program 50 (block 305). As with any Intel®-Windows® architecture, the BIOS program 50 performs a Power On Self Test (POST) and searches for a master boot record. BIOS program 50 is aware of devices that are coupled to computer system 10 and that are part of computer system 10, such as optical disk drive 65, hard disk drive 55, and a universal serial bus bar that is operatively coupled to interface 90. Thus, BIOS program 50 can interact with and detect such devices. For example, the BIOS program 50 interacts with the removable storage device 35 and detects the removable storage device 35.

In prior art systems, the drive device in which the master boot record is located is identified, and a BIOS program looks at section 1 (a 512-bit region) of a device, LBA #0 (the master boot record is stored therein), and Offset 0x3E (448 byte area) (self-start code is stored here). The BIOS program copies the master boot record to RAM and passes control to the master boot record. The master boot record controls its computer system and loads the code until it is no longer needed.

In accordance with an embodiment of the present invention, the table 450, rather than the master boot record, is stored in section 1 of the removable storage device 35. Master boot record and self-start The code is relocated to one of the memory locations 60-1 through 60-y in the removable device 35 according to the table 450, where y is equal to the number of master boot records stored in the removable storage device 35. Moreover, according to an embodiment of the present invention, the master boot record and the self-start code are stored in the middle of the other master boot record and the self-start code, and each of the master boot record and the self-start code can be associated with a different computer system architecture. Type compatible. Referring to Figure 2, the memory location of the master boot record and the self-start code for the Intel®-Windows® architecture is XXX (represented by 210-4).

Thus, the BIOS program 50 reads the table 450 located in the segment 1 and uses the "burn" to the identifier in the ROM 40 to find the location of the master boot record and the self-start code that are compatible with the architecture of the computer system 10. In addition, BIOS program 50 is configured to select information and implementation options from table 450. Alternatively, the information and options in table 450 can be selected and implemented via a program stored in ROM 40 that works with BIOS 50.

Referring again to FIG. 3, processor 15 continues with BIOS program 50, which identifies removable storage device 35 and accesses table 450 at a predefined memory location (block 310). In this example, the predefined memory location is section 1 (a 512-bit region) of the removable storage device 35 and, more specifically, offset 0x3E (a 448-bit region). Knowing the identifier of the computer system 10, the BIOS program 50 locates the identifier "8686" in the table 450 (denoted as 205-4) (block 315). As mentioned above, according to the embodiment of the invention, the identifier acts as an index. Therefore, the BIOS program 50 is allowed to find its specific location in the table 450 without having to repeatedly pass the table. As mentioned above, in this example, computer system 10 is based on the assigned "8686" identifier. Intel®-Windows® architecture.

The BIOS program 50 then reads the memory location entry associated with the identifier "8686" in the architecture column 210 (block 320). In this example, the entry associated with the identifier "8686" in the schema column 210 is XXXX (denoted 210-4), which specifies the memory in which the compatible master boot record is located in the removable storage device 35. position. After the LBA scheme, the removable storage device 35 translates the logical block address into a physical block address that indicates the location of the compatible master boot record on the media. The BIOS program 50 accesses the memory location at the LBA offset xxx and copies the master boot record to the RAM 45 (block 325). Computer system 10 performs a master boot record and passes control to the master boot record (block 330). The master boot record controls the computer system 10 and continues to load the code until it is no longer needed. The process includes loading the computer system's operating system from the hard disk drive 55 into the RAM 45.

As mentioned above, in accordance with an embodiment of the present invention, the removable storage device 35 can be disconnected from the computer system 10, operatively coupled to a second computer system having a different architecture, and self-activated.

For example, FIG. 4 shows a general illustrative block diagram of a removable storage device 35 in accordance with the above method and system. In a first exemplary embodiment, the removable storage device 35 is operatively coupled to a computer system 410 that includes an Intel® architecture. When computer system 410 is turned on, its BIOS program accesses its identifier in table 450. According to table 450, the BIOS program determines the location of its master boot record 430, copies the master boot record and stores it in RAM in computer system 410, which is executed in RAM.

In a second exemplary embodiment, the removable storage device 35 operates The system is coupled to a computer system 420 that includes an Alpha® architecture. When computer system 420 is turned on, its BIOS program accesses its identifier in table 450. According to table 450, the BIOS program determines the location of its master boot record 440, copies the master boot record and stores it in RAM in computer system 420, which is executed in RAM.

The foregoing merely illustrates the principles of the invention. It will be appreciated that those skilled in the art will be able to devise various other configurations that are embodied in the principles of the invention and are therefore within the spirit and scope of the invention.

For example, based on the above disclosure, it is apparent that the removable storage device can be a memory (such as an SD memory card, a compact flash card, a multimedia card or other removable card or memory device) and is easily adaptable to the present invention. The principle.

Additionally, based on this disclosure, it will be apparent that the principles of the present invention can be readily adapted to a table loaded into RAM 45 of computer system 10. In this exemplary embodiment of the invention, the BIOS program in ROM 40 locates table 450 stored in removable storage device 35 and loads table 450 into RAM 45. The BIOS program repeatedly passes through the table to search for an identifier that matches the identifier stored in ROM 40. As in the above exemplary embodiment, the identifiers represent various types of computer architectures, but in this example, the identifiers only recognize different types of architectures and do not serve as indexes. Therefore, the BIOS program must repeatedly search through table 450 for the appropriate identifier, rather than the appropriate identifier in the particular steering table 450 (e.g., if the identifier acts as an index).

After the identifier is located in the table 450, the BIOS program reads the memory location associated with the identifier and accesses the location in the removable storage device 35. Proper master startup record. The BIOS program copies the master boot record from the removable storage device 35 and loads the record into the RAM 45, which executes the master boot record in the RAM 45.

In this embodiment of the invention, there are no empty entries (e.g., null values or "0" values) in the schema column of the table because the identifiers in this embodiment do not serve as indices. The table stores only the identifier of the master boot record stored in the removable device 35, resulting in no empty entries in the table and a smaller table. For example, if you do not want to use the removable storage device 35 for one with Arm The computer system of the architecture does not only have the Arm stored in the removable storage device 35. Compatible master boot record, and Arm does not exist in the table Identifier or memory location. Of course, because the identifier does not act as an index, the BIOS program repeatedly passes each identifier in the table to locate the identifier of the correct architecture.

In another embodiment of the invention, a computer system is executing and an operating system is loaded. In this embodiment of the invention, a plurality of applications are stored on a removable storage device (e.g., an SD card). For example, three music playback applications are stored on the removable storage device, each application being compatible with a different computer architecture. The removable storage device is identified when the removable storage device is operatively coupled to a computer system. An automatic execution program that knows the identifier of the computer system and the table in the removable storage device locates the memory location of the music playback application associated with the identifier. The automatic execution program then loads a compatible music playback application onto the computer system, the application can play the content (data file, music file) stored in the removable storage device in the computer system. . The example computer system architecture is Palm , Windows CE And Windows .

In addition, the system is disclosed in the form of various functional blocks being executed by discrete functional blocks. However, any one or more of these functions may equally be embodied in a configuration in which the functionality of any one or more of the blocks is appropriately stylized by one or more The processing device (which executes a software program stored in various media or has a function of being programmed in a firmware) is implemented.

Moreover, those skilled in the art will appreciate that the present invention can be practiced in conjunction with other computer system configurations, including palm-sized devices, multi-processor systems, microprocessor-based or programmable consumer electronics, Internet PCs, mini computers, mainframe computers and the like.

Finally, the invention can also be embodied in a configured computer program storage medium (e.g., CD-ROM, hard disk, RAM) that contains software to perform the method.

In accordance with various embodiments disclosed, an electronic system is provided that includes: at least one control processor; and a portable data module operatively coupled for access by the control processor; the portable The data module includes a boot code for at least two mutually incompatible architectures; the portable data module also includes a data structure indicating which of the incompatible architectures are required for the boot code; Thereby the control processor can view the data structure at startup and continue the boot process using any of the boot code required for the architecture of the control processor.

In accordance with various embodiments disclosed, an electronic system is provided that includes: At least one control processor; a portable data module that is temporarily connected and thus temporarily accessible by the control processor; the portable data module includes a boot for at least two mutually incompatible architectures a code, and also a data structure indicating which architectures require which of the boot codes; and a stored initial sequence of instructions, the control processor executing the sequence when the power is turned on, allowing the control processor to use the data The structure continues with the boot process by using any of the boot code required for the architecture of the control processor.

In accordance with various embodiments disclosed, a computer system is provided comprising: a read only memory (ROM) having a basic input/output system (BIOS) code stored therein, wherein the BIOS code knows An identifier associated with an architectural type of a computer system and knowing a predefined memory location having a table identifying a plurality of memory locations within a removable storage device for a plurality of self-starting of a plurality of computer architectures The code is stored in the removable storage device; a processor coupled to the ROM; and a processor coupled to the interface, the processor executing the BIOS code to detect the removable storage device, and If the removable storage device is detected, the processor locates the predefined memory location, determines a location of the self-activation code associated with the identifier from the table, and loads the self-boot code into the The self-start code is executed in the computer system.

According to various embodiments disclosed, a removable non-volatile memory is provided, comprising: a table stored in one of the pre-defined memory locations in the removable non-volatile memory, the table identifying a plurality of memory locations in the non-volatile memory; and a plurality of applications, storage and storage Associated with a plurality of computer architectures in the plurality of memory locations associated with the table.

In accordance with various embodiments disclosed, a method for operating a programmable system is provided that includes the following actions: a) at startup, depending on the type of architecture of the system, from a portable data module The boot file is retrieved for execution by an address specified by a data structure indicating different locations for different boot files; and b) the system is automatically launched using the boot files to perform the job.

In accordance with various embodiments disclosed, a method for operating a programmable system includes the steps of: powering up the system, using an initial sequence of instructions stored in the host system; and in the initial instruction Under the control of the sequence, depending on the type of the architecture of the system, one of the plurality of boot files is loaded from a location specified by one of the portable data modules from one of the portable data modules. Start the file without loading other files, the data structure specifies different locations for different startup files; and use the startup files to automatically launch the system for jobs.

In accordance with various embodiments disclosed, a method for performing on a computer system is provided, comprising: executing a basic input/output system (BIOS) to locate one of a pre-defined memory in a removable non-volatile memory Position, the predefined memory location has a table identifying a plurality of memory locations in the removable non-volatile memory, and a plurality of self-starting code sequences for the plurality of computer architectures are stored in the removable non-volatile In the memory; executing the BIOS to determine a location of the self-boot code from the table associated with an identifier associated with an architectural type of the computer system; The BIOS is loaded to load the self-boot code into the computer system and execute the self-start code.

In accordance with various embodiments disclosed, methods, systems, and architectures for multi-platform booting of portable modules with non-volatile memory are provided. Preferably, the portable module carries the correct binary number for starting multiple system architectures, and a table that the host can calculate the correct offset to load the appropriate binary number when the power is turned on.

Modifications and changes

As will be appreciated by those skilled in the art, the innovative concepts described in this application can be modified and varied within a wide range of applications and, therefore, the scope of patents is not subject to the specific exemplary teachings. Any of them is limited. All such substitutions, modifications and variations are intended to be included within the spirit and scope of the appended claims.

The system that boots from the portable module does not have to be a computer in a strict sense, but can also be a game console, a PDA, or other complex system capable of executing programs.

The portable module need not be an SD or MS memory unit, but can conform to any of a number of physical and electronic device specifications for removable memory, including specifications that do not yet exist.

The various operating systems and hardware architectures mentioned above are merely examples - the disclosed invention can be applied to a wide range of situations, including situations that may arise in the future.

As is well known to those skilled in the art, the format and encoding of the tables need not be as described in the previous embodiments, but may of course vary widely.

The table position also does not have to be the table position described in the previous embodiment. In one In alternative embodiments, a different version of the table is included at a different location than or in lieu of the above-described table locations.

It is also possible to manually assist in the activation of the self-portable module. For example, a compact unit may allow a user interaction to set a state that forces the loader program to allow launching from a location specified in the data sheet in an attached portable module, although the normal boot sequence will Does not branch to the portable module.

The description of the present application is not intended to imply that any particular element, step or function is required to be included in the scope of the claimed invention. The scope of the patent is defined only by the scope of the permissible patent application. Moreover, unless the exact word "means for" is followed by a participle, none of these claims is intended to invoke 35 USC Article 112, paragraph 6.

The scope of the patent application filed is intended to be as detailed as possible, and the unmarked is intentionally sold, donated or abandoned.

10‧‧‧ computer system

15‧‧‧ processor

25‧‧‧System Memory

30‧‧‧System Bus

35‧‧‧Removable storage device

40‧‧‧Reading Memory (ROM)

45‧‧‧ Random Access Memory (RAM)/Table

50‧‧‧Basic Input/Output System (BIOS) Program

55‧‧‧ Hard disk drive

65‧‧‧CD player

70‧‧‧Operating system

75‧‧‧Application

80‧‧‧Program Module

85‧‧‧Program data

90‧‧‧ interface

205‧‧‧identifier column

210‧‧‧Architecture

410‧‧‧ computer system

420‧‧‧ computer system

430‧‧‧Master boot record

440‧‧‧Master boot record

450‧‧‧Table

Figure 1 is a block diagram of a computer system.

2 shows an example of a table for identifying memory locations for master boot records for different types of architectures.

3 is a flow chart illustrating the process for self-starting a computer system from a removable device capable of self-starting a computer system having a different architecture.

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

35‧‧‧Removable storage device

45‧‧‧ Random access memory

410‧‧‧ computer system

420‧‧‧ computer system

430‧‧‧Master boot record

440‧‧‧Master boot record

450‧‧‧Table

Claims (24)

  1. A removable memory system configured to interface to a host system to initiate a single architecture type of the host system, the memory system comprising: a memory comprising: for at least two a boot code compatible with a computer system architecture type; and a data structure that associates the incompatible architecture type with a memory location of the boot code; and an interface communicating with the memory, the interface is extractable Connected to the host system and configured to: receive a first request from the host system, the first request of the host system accessing the data structure to identify based on the single architecture type of the host system a boot code memory location; and receiving a second request from the host system to download a boot code of the architecture type from the boot code memory location, the second request being used to initiate booting of the host system.
  2. A memory system as claimed in claim 1, wherein the memory comprises a boot code for at least four mutually incompatible computer system architecture types.
  3. The memory system of claim 1, wherein the data structure is a table.
  4. The memory system of claim 1, further comprising an encryption engine and also having a memory space accessible only through the encryption engine.
  5. The memory system of claim 1, wherein the memory includes an ARM architecture and a PPC shelf for use in addition to at least one desktop computer startup file. Start the file.
  6. The memory system of claim 1, wherein the data structure is stored at a predetermined location in the memory.
  7. A memory system as claimed in claim 1, wherein the computer system comprises telephone functionality.
  8. The memory system of claim 1, wherein the host system is comprised of a single architectural type.
  9. The memory system of claim 1, wherein the data structure is further associated with at least one architectural type and an indicator that the memory system does not support initiating the at least one architectural type.
  10. A computer system comprising: a stored identifier identifying an architectural type of the computer system; a read only memory (ROM) having a basic input/output system (BIOS) code stored therein, wherein The BIOS code knows the identifier and knows a predefined memory location, the predefined memory location has a table identifying a plurality of memory locations in a removable storage device, and a plurality of self-starting of the plurality of computer architectures The code system is stored in the removable storage device; an external interface configured to interface with the removable storage device; and a processor in communication with the ROM and the external interface, the processor executing the BIOS And detecting the removable storage device, and if the removable storage device is detected, the processor locates the predefined memory location in the removable storage device, and uses the identifier to Table Positioning one of the self-starting codes compatible with the architecture type of the computer system, loading the self-starting code into the computer system and executing the self-starting code to start booting the computer system.
  11. The computer system of claim 10, wherein the table includes a plurality of identifiers, each identifier being unique to the plurality of computer architectures and associated plurality of memory locations.
  12. The computer system of claim 10, wherein the identifiers are indices.
  13. The computer system of claim 10, wherein the processor executes the BIOS code to copy the table to the computer system and search for the table.
  14. The computer system of claim 10, wherein the removable storage device is an SD memory card, a compact flash memory card, a hard disk drive or a compact disc.
  15. The computer system of claim 10, wherein the plurality of self-starting codes comprise two or more of the following architectural types: IA32, Alpha, Arm, Cris, IA64, M64k, Mips, Mips64, Parisc, Ppc, Ppc64, S390, S390x, Sh, Sh64, Sparc, and/or Sparc64.
  16. The computer system of claim 10, wherein the predefined memory location is a first logical block address (LBA).
  17. The computer system of claim 10, wherein the predetermined memory location is a location at which a master boot record is based on the type of architecture of the computer system.
  18. The computer system of claim 17, wherein the master boot record is located in one of the plurality of memory locations within the removable storage device.
  19. The computer system of claim 10, wherein the computer system is comprised of a single architecture type.
  20. A method for booting a host computer system using a removable memory system interfaced to a host computer system, comprising: powering on a host computer system using an initial sequence of instructions stored in the host computer system Detecting the removable storage device, the removable computer storage device is connected to the host computer system through an external interface; and reading an identifier stored in the host computer system, the identifier identifying the host computer system An architecture type; positioning a predefined memory location in the removable storage device, the predefined memory location having a table identifying a plurality of memory locations in the removable storage device, and a plurality of computer architectures a plurality of self-starting code stores are stored in the removable storage device; the identifier is used to determine a location of the self-starting code in the removable storage device from the table, the self-starting code and the host computer system An architecture type compatible; loading the self-boot code to the host computer system; and executing the self-boot code to open Power on the host computer system.
  21. The method of claim 20, wherein the step of locating the predefined memory location within the removable storage device comprises copying the table from the removable storage device to the host computer system.
  22. The method of claim 21, wherein the host computer system is comprised of a single architecture type.
  23. The method of claim 21, further comprising using the identifier to determine that the removable storage device does not support starting the architecture of the host computer system type.
  24. The method of claim 23, wherein the table associates the type of architecture of the host computer system with an indicator indicating that the removable storage device does not support the type of architecture in which the host computer system is booted.
TW96151677A 2006-12-31 2007-12-31 Portable multi-platform booting systems and architectures TWI441077B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/618,870 US20080162916A1 (en) 2006-12-31 2006-12-31 Portable Multi-Platform Booting
US11/618,872 US7925875B2 (en) 2006-12-31 2006-12-31 Systems and methods for identifying and booting a computer architecture

Publications (2)

Publication Number Publication Date
TW200844850A TW200844850A (en) 2008-11-16
TWI441077B true TWI441077B (en) 2014-06-11

Family

ID=39588994

Family Applications (1)

Application Number Title Priority Date Filing Date
TW96151677A TWI441077B (en) 2006-12-31 2007-12-31 Portable multi-platform booting systems and architectures

Country Status (3)

Country Link
KR (1) KR101120956B1 (en)
TW (1) TWI441077B (en)
WO (1) WO2008083277A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9916185B2 (en) 2014-03-18 2018-03-13 International Business Machines Corporation Managing processing associated with selected architectural facilities
US9582295B2 (en) 2014-03-18 2017-02-28 International Business Machines Corporation Architectural mode configuration
US9588774B2 (en) 2014-03-18 2017-03-07 International Business Machines Corporation Common boot sequence for control utility able to be initialized in multiple architectures

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100247952B1 (en) * 1997-04-11 2000-03-15 윤종용 Booting control apparatus and method of pda
DE60210434T2 (en) 2002-06-28 2006-09-28 Hewlett-Packard Development Co., L.P., Houston OS selector and disk space
SG138439A1 (en) * 2003-04-02 2008-01-28 Trek 2000 Int Ltd Portable operating system and method to load the same
US7664836B2 (en) * 2004-02-17 2010-02-16 Zhe Khi Pak Device and method for booting an operation system for a computer from a passive directly attached network device
KR100677327B1 (en) * 2004-06-16 2007-02-02 엘지전자 주식회사 Mobile communication terminal with dual operating system
US7490318B2 (en) * 2005-02-25 2009-02-10 Inventec Corporation Computer platform operating system compatibility management method and system

Also Published As

Publication number Publication date
KR20090097171A (en) 2009-09-15
WO2008083277A1 (en) 2008-07-10
KR101120956B1 (en) 2012-03-05
TW200844850A (en) 2008-11-16
WO2008083277A9 (en) 2008-12-31

Similar Documents

Publication Publication Date Title
EP0417888B1 (en) Loading method and apparatus for computer system
US7334227B2 (en) Device driver installing method
US6594723B1 (en) Method and apparatus for updating data in nonvolatile memory
US7730295B1 (en) Updating firmware of a peripheral device
US5214695A (en) Apparatus and method for loading a system reference diskette image from a system partition in a personal computer system
US6804774B1 (en) Software image transition aid comprising building a disk image based on identified hardware
US5128995A (en) Apparatus and method for loading a system reference diskette image from a system partition in a personal computer system
US20060190941A1 (en) Removable device and program startup method
US7853944B2 (en) Apparatus and method for managing firmware of removable media device
US7689817B2 (en) Methods and apparatus for defeating malware
US7032107B2 (en) Virtual partition for recording and restoring computer data files
US20020194313A1 (en) Method and apparatus for distributing computer platform firmware across a network
US7555568B2 (en) Method and apparatus for operating a host computer from a portable apparatus
US6725178B2 (en) Use of hidden partitions in a storage device for storing BIOS extension files
US5787491A (en) Fast method and apparatus for creating a partition on a hard disk drive of a computer system and installing software into the new partition
US8407396B2 (en) Providing block data access for an operating system using solid-state memory
US8090938B2 (en) Methods and systems for running multiple operating systems in a single mobile device
US6772281B2 (en) Disk drive for selectively satisfying a read request from a host computer for a first valid data block with a second valid data block
EP1510920A2 (en) Apparatus and method for controlling booting operation of computer system
US8291209B2 (en) Integration model for instant-on environment
TWI384399B (en) Apparatus and methods for updating firmware
US8091084B1 (en) Portable virtual machine
US6862681B2 (en) Method and system for master boot record recovery
US20060242398A1 (en) Booting from non-volatile memory
DE60018807T2 (en) Method and device for recovering the configuration of a computer