KR100302926B1 - Disk-based software image use from a read only memory device - Google Patents

Abstract

The present invention accesses a disk based operating system stored in a ROM device by intercepting system requests for data originating from the disk-based operating system system and converting those requests into ROM memory access. . Device drivers are introduced into computer systems to intercept disk-based addresses generated by interrupts or direct system requests. The device driver remaps disk geometry based access to ROM memory based access. System calls are intercepted and converted from disk based calls to ROM based calls, allowing the disk based operating system to run from R0M without modification.

[Index]

Operating system, memory, R0M, memory

Description

Using Disk-Based Software Images from R0M Devices {DISK-BASED SOFTWARE IMAGE USE FROM A READ ONLY MEMORY DEVICE}

The present invention is directed to a method and system for causing a computer system to use a read only memory (ROM) device to store and execute recorded software for a disk-based environment. More specifically, the present invention relates to operating system processing and architecture and computer systems required to use disk-based software stored in linear ROM.

Semiconductor ROM devices have historically been used in computer systems to store unaltered portions of executable code, such as system initialization tasks and initial program load (IPL) of the operating system. The requirement that the ROM code be invariant, and that the ROM devices are relatively expensive compared to other forms of media, is why these ROM devices are limited in only a small portion of the code. Traditionally, only major parts of personal computer operating systems have been held on removable diskettes or hard disk drives. Semiconductor ROM devices, such as memory manufactured by Texas Instruments and Advanced Micro Devices, are computer chips that store data in linearly addressable locations. Such memory is distinguished from compact disk read only memory (COROM), which uses optical technology to store read-only code on a removable medium having a special physical structure.

Personal computer operating systems such as DOS, IBM OS / 2, and Microsoft Windows have been created for systems that use hard disk storage or diskettes for operating system storage. The loading and execution of such programs assumes that the operating system is stored on a disk based on the geometry of these disks. Initially loading the operating system and supporting application programs to access operating system features depends on the disk geometry of the removable disk or hard disk. Disk geometry includes defined disk sectors that hold data. The performance of the operating system is improved by directly accessing disk sectors based on location. Thus, the system depends on the physical structure of the disc.

The reduction in size and cost of microprocessors and semiconductor memories is driving the use of computers to provide embedded functions in machines ranging from automobiles to home electronics. Embedded controllers provide more functionality and sometimes operate in a manner similar to an independent personal computer. In the development stage, if a programmer can simply load such an application program into a read-only device as part of an embedded system using a standard personal computer or workstation tool, the application program for the embedded system is faster and more efficient. Can be developed as. Historically, embedded microprocessors have used specialized operating environments or dedicated operating systems to support the functionality of the microprocessor. Development using a standard operating system requires that R0M be provided with standard operating system functionality for embedded systems.

Special versions of standard disk-based operating systems are available in the embedded systems market. For example, Microsoft offers a product named "ROM D0S", which is a version of the DOS operating system available on ROM devices. IBM offers a version of IBM Microkernel for use in embedded controllers. However, one thing to consider when creating a ROM-based operating system version is that the operating system must be modified because of the fact that such operating system runs from a ROM device rather than from a disk image. The analysis and remediation required for a complex operating system such as IBM 0S / 2 or Microsoft Windows 95 can take several years to be uneconomical.

Therefore, it is a technical challenge to invent a system and method for allowing a standard disk-based operating system to run from a R0M image. There is a need for a solution that addresses the limitations imposed by operating systems that rely on disk geometry.

One object of the present invention is to provide a method of loading a disk-based operating system from a ROM device.

Another object of the present invention is to allow an application program to use an operating system service of a disk-based operating system stored as a ROM image.

It is yet another object of the present invention to provide a method of creating and using a ROM image having a disk-based operating system in an embedded environment.

1 illustrates a processing sequence of a conventional computer system during booting and loading (1oad) an operating system.

FIG. 2 illustrates an application request sequence for operating system functionality in a real mode and protect mode computer system. FIG.

3 illustrates disk sector geometry of a conventional hard disk.

4 illustrates a linear memory of a ROM device in accordance with a preferred embodiment of the present invention.

5 is a block diagram illustrating a hardware configuration diagram in accordance with the present invention.

6 illustrates a memory interrelationship in accordance with the present invention.

7 is a flow chart illustrating a process for creating an executable R0M image of a disk-based operating system in accordance with the present invention.

8 is a flowchart illustrating a control flow during operation and IPL of a computer system according to the invention.

9 is a process diagram illustrating the flow of power on, IPL and execution of a disk-based operating system from a ROM image according to the invention.

* Explanation of symbols for main parts of the drawings

104: ROM 110: Disk / Diskette

112: operating system 114: applications

206: hard disk controller 208: hard disk

302: disk sector

The present invention is to provide a system and method for loading and using a disk-based operating system from a ROM image in a computer system. The present invention provides a means for using a ROM image as well as creating a ROM image.

The present invention provides a means for intercepting computer system requests for data originating from an operating system disk image and redirecting these requests to an R0M image.

The present invention relates to a method of executing a disk based operating system stored in a R0M device, the method operating on a computer system having a processor and a memory. The method includes generating disk geometry mapping to a ROM device address for a disk based operating system; Intercepting system requests for accessing the disk based operating system; Transforming the disk based access request to a ROM access request; And accessing and returning ROM data corresponding to the disk-based access request.

The above-mentioned objects and other objects, features, and advantages of the present invention will become apparent from the following detailed description of the preferred embodiments of the present invention illustrated with reference to the accompanying drawings.

Programmed instructions are required for the computer system to operate. Most computer systems today employ some form of operating system to control the processing of application programs that perform user functions. Operating system programs manage computer resources such as memory, storage devices, and communication devices. The operating system is initially loaded when the computer system is powered up, but the system hardware cannot begin loading the operating system without the programmed instructions to load the operating system. Thus, computer hardware typically includes a ROM that allows the computer's operation to begin and holds the basic instructions necessary to initiate loading of an operating system from a disk drive or diskette.

Preferred embodiments of the present invention operate in conjunction with computer systems such as Intel microprocessors and IBM PCs. A preferred embodiment is an embedded computer system designed to perform a limited set of application functions without the general purpose interactions common to personal computers. The embedded computer system of the present invention limits the ability of a user to change programs and applications, and in most cases will not provide any recordable storage device to the system user.

When the power switch 100 of the computer system according to the preferred embodiment is turned on (FIG. 1), the system performs an initial hardware test and begins loading the operating system to verify the hardware configuration. The power-on self test (POST) function 102 is stored in the semiconductor ROM device 104. The final step of the power-on self test process is to initiate an initial program load (IPL) 106 of the operating system. System configuration typically causes the system to first scan removable media, such as diskettes, and secondly to the hard disk to find operating system code. The loading 108 of the operating system proceeds from the selected disk or diskette 110 until the operating system is fully initialized. Once initialization is complete, the operating system performs the necessary supervisory function 112 which includes servicing application program requests for operating system services.

The application's access to operating system functions stored on the disk drive is in the order illustrated in FIG. Application 114 issues a request of operating system 112. In a real mode operating system, such as DOS, the operating system generates an interrupt 13 202 that requires access to data on the hard disk. Interrupt 13 (INT13) is a system application program interface (API) that requests services from a basic input / output system (BIOS) that is responsible for interaction with hardware.

The operating system's INT13 202 requests input / output from a particular address. The address relative block address (RBA) is translated into a specific disk sector address, which is passed to the hard disk controller 206 which accesses the hard disk itself 208. In this sequence, the hard disk is a permanently mounted disk or a removable diskette device. If the operating system operates in processor protect mode, the operating system may request data directly from hard disk controller 206. In both real mode and protect mode, the input / output request depends on the disk geometry. For example, INT13 request 202 allows input / output (I / O) address RBA translation 204 to provide hard disk controller 206 with a request (sector request) based on specific disk geometry. In the protect mode, sector requests are issued directly to the hard disk controller 206.

The layout of the hard disk is illustrated in FIG. The hard disk is divided into a number of cylinders and sectors each holding data. Hard disk controller 206 accesses disk 302 by specifying the sector to search.

The operating system loaded into the ROM device is configured linearly, for example, in the address space following from address OX to address nnnX. Access to data in random access ROM does not require hard disk sector specification, but rather a linear memory address specification.

Conventional solutions for providing a ROM mood operating system require that the operating system code be analyzed each time the INT13 API is called, or that the protect mode hard disk access is located and changed to access the linear memory of the ROM device. This effort consumes a significant amount of development resources so that the operating system can only be used in a situation that justifies these high costs.

Preferred embodiments of the present invention enable the use of any disk-based operating system in a ROM environment. The present invention introduces a device driver into the system environment, which intercepts INT13 interrupts and hard disk controller access and translates these requests into addressable reads of the ROM device. Introducing these device drivers allows the operating system to run unchanged even when loaded into a ROM device.

5 is generally shown in the hardware environment of the present invention. Embedded systems typically have a processing unit made up of one or more central processing units (CPUs), such as an Intel Pentium processor (Pentium is a trademark of Intel Corporation) or an IBM PowerPC processor (PowerPC is a trademark of IBM Corporation). The system also has a RAM 504 and a ROM memory 506. Input / output controller 508 allows the system to communicate with external devices required for operation of the system. Such devices may include a keyboard and a display or may be connected to special equipment for interacting with a supported environment.

The ROM device 506 may be a single ROM chip or a plurality of ROM chips, depending on the particular structure of the application. Using a single ROM could replace the standard system ROM with a larger ROM that contains both system functionality and an embedded operating system. Another approach is to separate the system ROM from the operating system ROM to provide two different devices.

The present invention uses the system ability to "hook" an interrupt so that specific code is executed whenever that interrupt occurs. The ability to hook and execute provided code is also used in existing systems to implement device driver logic. The present invention discloses a device driver-like architecture that hooks operating system disk interrupt 13 and disk controller I / 0 access.

As mentioned above, the operating system on the ROM device is configured linearly, much like the memory of the computer system itself. This linear access to memory requires a device driver to specify the address of the memory section holding the required code. 6 illustrates an exemplary memory layout of a computer system in accordance with the present invention. The memory is shown as a memory that extends from the bottom of the figure to the top, that is, from zero (0) to 16M (16 megabyte memory). An address area between zero (0) and CO000 is reserved for program execution. A portion of this memory area (640 KB in the range 0000-A0000) is used by DOS or Windows applications while the program is running. The remainder of the area is used for VGA and monochrome video adapter memory.

Memory between C0000 and 1Mega is reserved for device operation. Drivers associated with video device drivers, adapter cards, and the like are mapped into these memory areas. This mapping allows the operating system to access data held on the adapter by accessing the addresses in this memory range. Accessing the address through the system bus will properly return the data from the adapter or RAM.

The example of FIG. 6 assumes that a computer system has a physical size of RAM that is 8 megabytes. The preferred embodiment maps a ROM based operating system into an area outside of the system's physical memory. In this example, the operating system ROM may be mapped to a memory location starting at 8 megabytes and extending to 16 megabytes. Access to this memory address will be intercepted by the ROM and appropriate operating system information will be returned.

The disk-based operating system is converted into a ROM image using the process shown in FIG. First, a bootable disk containing an operating system is created.

The occupied disk area on the boot disk is then defragmented to ensure that the code is compressed into a single block rather than being located on a disk with unused disk area space between the blocks. Conventional disc writing algorithms place data in available sectors in the disc image that are not contiguous and can leave some unused space.

The defragmented image 704 is compressed in that the file is placed linearly from the beginning of the disk without blank space. Next, a sector based copy of the disk including the boot record is created (706). This sector-based copy is one linear image created from the disk but retains information on related sectors. The image is then loaded onto the ROM device with the INT13 hook device. In this way, the ROM device can be used in an embedded system.

One additional step is required to make the ROM image available to the computer system. Initiate the operating system's IPL to end the power-on self test. On Intel based systems, IPL occurs using interrupt 19 (INT19). The initial boot ROM must be modified in accordance with the present invention so that the last step of the boot sequence can load the INT13 device driver before loading the operating system.

In FIG. 8, a power-on self test is first performed 802. Next, the system hooks interrupt 19 to see if the IPL sequence needs to load the INT13 device driver. During the IPL, the INT13 and hard disk controller trap device drivers are loaded and the operating system is IPLed. The mapping of disk RBA and sector information to linear ROM addresses may be hand coded or generated by the device driver when the device driver detects an R0M image. Thereafter, the operating system is performed 808 in a standard manner. The overall process is shown in Figure 9, which shows a conventional boot sequence and the improved steps of the present invention. The R0M 104 'stores the improved system power-on self test and IPL initial sequence. This is slightly changed to hook INT19. ROM 902 holds an image of the operating system and the INT13 device driver code.

A hook routine that hooks INT13 for real mode and traps I / O requests in protect mode finds the location of the OS ROM and associated files from that ROM. Read the system structure. The system uses the physical disk geometry information collected from the file system in the OS ROM to create a table that correlates the physical read request to a specific RBA (memory location holding the data). The system uses the table to access the ROM device to satisfy operating system code requirements referenced by the disk geometry.

Physical disk geometry depends on the operating system and file system. The present invention can be adapted for use in any operating system and file system and can also be used in processors with different BIOS structures. Different geometry and BIOS processes are reflected in modified device driver code and disk request intercept processing.

A preferred embodiment of the present invention locates the device driver in a ROM scan area 602 of the system. This area is scanned at boot time by systems using the IBM Personal Computer Compatibility Architecture. In order to use the present invention on different architectures, it is necessary to place the intercepting device driver code in the proper place in the system.

It will be appreciated by those skilled in the art from the foregoing that various changes can be made in the preferred embodiments of the invention without departing from the spirit of the invention. The above description is for illustrative purposes only and should not be construed as limiting the invention. It is intended that the scope of the invention only be limited by the claims.

Claims (11)

CLAIMS 1. A method for executing a disk-based operating system stored in a ROM device, the method operating on a computer system having a processor and memory, the method comprising: a) a ROM device address for a disk-based operating system; Creating a disk geometry mapping to the furnace; b) intercepting system requirements for accessing a disk-based operating system; c) converting the disk-based access request to a ROM access request; And d) accessing and returning ROM data in response to a disk-based access request. The method of claim 1, wherein creating the mapping comprises: a) creating a bootable disk image of the disk-based operating system; b) copying a bootable image to the ROM device; And c) generating data indicative of a corresponding ROM address location for each bootable disk image sector based on the bootable disk image geometry. 2. The method of claim 1, wherein said intercepting comprises: a) intercepting an interrupt request for disk access to a disk sector; And b) intercepting a request to a disk controller for access to a disk sector. 2. The method of claim 1, wherein said intercepting comprises: a) loading a disk driver in response to a disk access request; And b) transferring control to the device driver each time a disk access interrupt or disk access command is detected. 5. The method of claim 4, wherein the disk access interrupt that is intercepted is INT13 on an Intel processor. A system for executing a disk-based operating system held in a ROM device, the ROM device being addressable using a linear memory address, the system comprising: a) means for intercepting an operating system disk access request; b) means for converting a disk access request into a ROM device addressable request; And c) means for accessing the ROM device using the converted request. 7. The system of claim 6, comprising means for returning the accessed information to the process that requested access. 7. The system of claim 6, wherein the means for intercepting is a device driver. 9. The system of claim 8, wherein the means for intercepting intercepts INT13 interrupts. 10. The system of claim 8, wherein the means for intercepting intercepts a protect mode disk sector access request to a hard disk controller. 7. The system of claim 6 including means for converting disk sector requests into linear memory addressable requests.

Images