KR20050016256A - Creating file systems within a file in a storage technology-abstracted manner - Google Patents

Abstract

PURPOSE: A system for generating a file system within a file through a storage technology-extracting method is provided to supply a mechanism for converting operating system image components into file system-based images, thereby easily conducting a device component update function while being applicable to an initial image. CONSTITUTION: Two basic components such as a disk image utility(230) and an image following processor(232) are provided. The disk image utility(230) takes sets of a technology(file,236) which is related to partitions/file systems desired by a user, a technology(file,238) which is related to a mapping of partition structures of packages(234), and packetized operating system components(or packages). The disk image utility(230) generates one output file(206) including various partitions(209-212). Contents of each package are stored in proper partitions, and executable codes are disposed in virtual address space-based addresses.

Description

CREATING FILE SYSTEMS WITHIN A FILE IN A STORAGE TECHNOLOGY-ABSTRACTED MANNER}

Cross-Reference to Related Applications

The present invention claims priority to US Provisional Tax Application No. 60 / 530,135, filed December 16, 2003, which is incorporated herein by reference in its entirety.

The present invention relates to the following US patent applications filed concurrently with the present invention and to which reference is hereby made in their entirety.

"Applying Custom Software Image Updates To Non-Volatile Storage in a Failsafe Manner", document number 4271 / 307,649;

"Determining the Maximal Set of Dependent Software Updates Valid for Installation" of document number 4281 / 307,650;

"Ensuring that a Software Update may be Installed or Run only on a Specific Device or Class of Devices" of document number 4291 / 307,651; And

"Self-Describing Software Image Update Components" of document number 4301 / 307,652

Field of invention

TECHNICAL FIELD The present invention relates generally to computing devices having embedded operating systems, and more particularly, to configuring nonvolatile storage space of computing devices.

background

Personal digital assistants (PDAs), modern cell phones, and mobile computing devices such as hand-held and pocket-sized computers have become important and generalized user tools. In general, their power consumption has been reduced, while being compact enough to be quite convenient, while at the same time enabling more powerful applications.

During the manufacturing process of these devices, the built-in operating system images are typically built into a monolithic image file, so that each device's nonvolatile storage space (e.g., NAND or NOR flash memory, hard disk, etc.) Stored. Thus, a monolithic image file must be preconfigured from the various parts that make up the operating system. In addition, it is sometimes desirable or desirable to update such a device, which update requires a change to the operating system.

However, when dealing with monolithic images, it may be necessary to install an update that requires replacement of the entire image (or maybe some subset thereof), which requires a large amount of resources, including temporary storage space and bandwidth. There are a number of disadvantages. Due to various conflicts and dependencies, updating the individual components of the operating system is a difficult task, so far monolithic replacements have been used to update these devices. In addition, any such componentization introduces another problem that the initial image is still required for manufacturing, but until now the initial images were essentially monolithic groups of bits delivered to the devices.

What is needed is a mechanism to convert operating system image components into a file system-based manufacturing image suitable for use as an initial image, but designed to facilitate componentized updating of the device.

For simplicity, the present invention provides a method and system for generating a single manufacturing image file, in which the individual operating system component packages are installed at build time, including a partition and file system layout. This processing is a storage technology-extraction scheme where the system and method are not concerned with the type of basic storage space (e.g. flash), and / or any requirements that the basic storage space may impose on the layout of the image. Is performed. Rather, in a separate step, the resulting image file is post-processed, including individualizing the image file with respect to the actual type of storage device present.

In one implementation, various types of partitions are created in a file, each corresponding to a file system. The set of operating system image components (called packages) is converted into file system-based manufacturing image partitions. From that file, an initial operating system image can be established on the device during the manufacturing process, in such a way that the image update technique can later use similar partition and file system models on the device.

To convert the various packages into the initial manufacturing image, one manufacturing image file is created in which the images are arranged in partitions and file system layouts. This file is then post-processed as needed to add the metadata needed to install the content at the time of manufacture.

In order to ultimately build the file to be written to the virtual flash, various partitions are created. Some of the entire flash may be reserved for various purposes by the device manufacturer, while the remaining memory remains available as virtual memory for use by the operating system components and optional user storage space. Each partition has a purpose and can be considered a unique file system. For example, there may be binary partitions, such as for update loaders, and RAMIMAGE / ROMIMAGE partitions for kernel (NK) partitions. An IMGFS partition can contain operating system files and a user storage space partition can be specified for storing user data. A master boot record can be created in the file to point to the partitions. Additional data may be included in the file.

In one implementation, a disk image utility creates a file, and the image post processor adds metadata to allow the file to be written to a given storage medium. The disk image utility takes the operating system packages and puts them into a memory description (memory configuration file) of how the partitions are laid out in storage along with a description of how the packages should be mapped to such a partition structure. Based on this, an output file is created that contains various partitions where the contents of each package are stored in the appropriate partition. In addition, any executable code is placed at the appropriate virtual address space-based address. The memory configuration file provides an operating system run-time virtual address space memory map for both nonvolatile storage space and system RAM. The partition mapping file contains a list of uniquely identified packages and is used to map packages to specific partitions.

The post processor works on the output file and introduces any changes to the partition and file system layout required by the particular storage technique. For example, different flash parts may need to be adjusted to handle different ways of managing sector-level information of the flash.

Other advantages will be apparent from the following detailed description with reference to the drawings.

details

Example Operating Environment

1 illustrates one such handheld computing device, including a processor 122, a memory 124, a display 126, and a keyboard 128 (which may be a physical or virtual keyboard, or both). Represent functional components of 120. Microphone 129 may be present to receive audio input. Memory 124 generally includes both volatile memory (eg, RAM) and nonvolatile memory (eg, ROM, PCMCIA card, etc.). Microsoft Corporation Windows ^? Operating system 130, such as an operating system or other operating system, resides in memory 124.

One or more application programs 132 are loaded into the memory 124 and run in the operating system 130. Examples of applications include email programs, scheduling programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, and the like. The handheld personal computer 120 may also include a notification manager 134 loaded in the memory 124, which is executed on the processor 122. Notification manager 134 handles notification requests from, for example, application programs 132. In addition, as described below, the handheld personal computer 120 may include networking software suitable for connecting the handheld personal computer 120 to a network, which may include making a phone call (e.g., a hardware driver, or the like). And network components 138 (eg, radio and antenna).

Handheld personal computer 120 has a power source 140 implemented with one or more batteries. The power source 140 may further include an external power source that replaces or charges internal batteries, such as an AC adapter or a powered docking cradle.

The exemplary handheld personal computer 120 shown in FIG. 1 is shown having three types of external notification mechanisms: one or more LEDs 142 and an audio generator 144. These devices, when activated, power the power supply 140 such that the handheld personal computer processor 122 and other components remain in the ON state for the period indicated by the notification mechanism even if they are shut off to conserve battery power. Can be combined directly. The LED 142 preferably remains in an ON state indefinitely until the user takes action. Current versions of the audio generator 144 use too much power for today's handheld personal computer batteries, so they are configured to turn off when the rest of the system is operating or in some limited period after activation.

Although a basic handheld personal computer is shown, virtually any device capable of receiving data communications, such as a mobile telephone, and processing the data in some way for use by a program is the same for the purpose of implementing the present invention. It can be seen that it can be used.

Creating file systems in a file

In general, the present invention includes writing initial software or software updates to non-volatile memory, such as flash memory, of an embedded device ^. And installing and / or updating software stored on small mobile computing devices, such as CE .NET-based portable devices. Nevertheless, the present invention provides advantages for general purpose computing, and therefore may be applied to other computing devices and other types of storage space, including other types of storage media such as various types of memory and / or hard disk drivers. have. For the sake of simplicity, the term "flash" will hereinafter be used to indicate an updateable storage space of a device, although it may be understood that it is the same as any storage mechanism. In addition, the term "image" will generally encompass the concept of subsequent software updates to the image as well as the initial software installation image, even if only a portion of the existing image is updated.

Images containing both executable code and data can be applied to the storage space. The executable code is individualized at installation time according to the virtual address space environment of the embedded device. According to one aspect of the invention, a universal image update technique decomposes an operating system image into updateable components that can be updated individually while maintaining any cross-component dependencies. As can be seen, the initial image is aligned in a manner that facilitates initial installation of the device as well as subsequent updates accordingly.

According to one aspect of the present invention, a system and method are provided for converting operating system image components (called packages) into a file system-based manufacturing image. This is done in such a way that output files are generated through partition and file system models. From that file, during the manufacturing process, an initial operating system image can be established on the device in such a way that the image update technique can later use similar partition and file system models on the device. This facilitates a stable and malfunction-safe update of the individual components, the entire partitions or, if necessary, the entire image.

In order to convert the various packages into an initial manufacturing image, a general method and system are provided for creating one manufacturing image file that includes an image arranged in a partition and file system layout. This file is then post-processed to prepare the content for installation at build time. Thus, it is this manufacturing file in which the individual operating system component packages are written. The overall file organization process is a storage (e.g. flash) technique-extraction where the system and method are not concerned with the type of basic storage space and / or any requirements that the basic storage space may impose on the layout of the image. Is done in a manner. Rather, in an individual step, the resulting image file can be applied to any desired device by post-processing, including individualizing the image file for the actual type of storage device present.

2 provides an example of a storage space (eg, flash) of a device in which a manufacturing image is to be laid out in a manner facilitated by various aspects of the present invention as described below. In FIG. 2, a portion of the total flash 202 (eg, 32 MB out of 64 MB in total) is reserved for various purposes (eg, for code associated with the device's radio) by the device manufacturer. The remaining (eg, 32 MB) is flash memory that can be used as virtual memory 204 for use by the operating system and (optionally) user storage. As discussed below, the file will take into account reserved sections.

In accordance with one aspect of the present invention as described below, various partitions are created in file 206, which is a file to be written to virtual flash 204. Each partition has a purpose and includes (or can be considered to include) its own file system. For example, in the embodiment of Figure 2, the update loader partition 209, kernel (NK) partition 210, system partition 211 and user storage space (e.g., formatted for storing user data). Partition 212 is present. As described below, a master boot record (213) is created in the file to indicate the partitions. Also, for the sake of completeness, as shown in FIG. 2, additional booths, such as the existing boot loader 214 (optional for new devices, but for older devices), and an initial program loader (IPL) 215. Data can be included in file 206, for example, by pre-locating the data. As can be seen, some or all of this additional data may be flashed to a device independent of other partitions, such that file 206 will be flashed to the rest of the virtual flash, but these bits will be written to manufacturing file 206. ) Eliminates this additional manufacturing step. The partitions in FIG. 2 are not to scale, and the total amount of memory and / or available memory is only one example.

As can be seen, the present invention provides the ability to create manufacturing images using standard file system concepts in one file and store-extract scheme. As such, embedded and other solutions can be applied to any new storage technologies available in a direct manner and with little / no impact on the core procedure. For example, through post-processing, the system image of the flash file can be modified to be a hard-disk image.

In addition, being able to create file systems in individual files at build time means that complex partitioning, formatting, and other file system logic need not be implemented in a manufacturing environment. Instead, standard means by which images are written to the current storage space (e.g., flash population programmers, JTAG, or byte stream copies) can be used later by the operating system image at run time. Even in the case of potentially complex partition and file system-based schemes, they still work.

In order to realize various aspects of the present invention, in one exemplary implementation (roughly described above with reference to FIG. 2), two basic components are provided, namely disk image utility 230 and image post processor 232. do. The disk image utility 230 provides a description of how a user (eg, a manufacturer) wants to layout partitions / file systems in storage space (file 236) and how packages 234 can be incorporated into such partition structure. Takes a set of packaged operating system components (or packages), along with a description of what should be mapped (file 238, also known as a package-to-partition mapping file and / or an image listing file). From this information, disk image utility 230 generates one output file 206 containing various partitions 209-212, where the contents of each package are stored in the appropriate partition, and the appropriate virtual address space. Executable code is placed at the base address.

 Once in this output file state, the post processor 232 acts on this output file to introduce any changes to the partition and file system layout as required by the particular storage technique. For example, as outlined below with respect to the post processor, different flash parts may need to be adjusted to handle different ways of managing sector-level information of the flash.

Thus, in the implementation example of FIG. 2, disk image utility 230 may include two input files 236 and 238, a memory configuration file 236 (eg, memory.cfg.xml) and a package-to- Driven by partition mapping file 238 (e.g., * .sk.xml, where * represents a valid file name). In general, partition mapping file 238 includes information that maps each particular operating system component (eg, a package) to a particular partition indicated in memory configuration file 236.

Partitions 209-212 can be of different types (and are usually of different types). For example, in one implementation, a BINARY partition, such as a compressed update loader partition 209 (a BINARY partition only has bits copied to it); One or more RAMIMAGE or ROMIMAGE partitions, such as NK partition 210; One or more Image Update File System (IMGFS) partitions, such as system partition 211; And / or USERSTORE partitions such as TFAT or other partition 212. Although there may be an arbitrary total number of partitions and / or types of partitions, one current implementation may update the total number to four, for example, as shown in FIG. 2 to simplify the configuration of the mechanism. It is limited to a loader (BINARY), NK partition (RAMIMAGE or ROMIMAGE), system partition (IMFGS) and user partition (USERSTORE). Even in the case of such an arbitrary limitation, there may be a repeating type defined with, for example, three binary types and four partitions in which one IMGFS may be allowed, and other types of partitions may also be possible.

Memory configuration file 236 represents the operating system's run-time virtual address space memory map for both nonvolatile storage space and system RAM. This data indicates how the user of the utility wants to use specific storage space resources by specifying one or more partitions where information can be stored and assigning properties to the data to be stored in the partition.

In one implementation, the memory configuration file 236 is an XML-formatted file identified for the next XSD.

An exemplary memory configuration is set as follows.

As can be seen in this example, the hardware section of the memory configuration file contains a full description of each flash part to be managed as storage space by the disk image utility as well as the location of each of the RAM and reserved flash parts. ). NOR and NAND tags are generally used to mean linear or block-based storage space (such as RAM), respectively. Each storage space part is provided with a unique identifier / name. The partition section shows how certain storage space parts should be used for partition-based extraction.

ROMIMAGE means, for example, the contents of a partition that must be determined / relocated (as described below) to actually execute from the storage space part (execute in place or XIP), which is linear- It is a feature of type storage devices. If ROMIMAGE is used, the disk image utility ensures that the executable code in any place is not compressed, and that the individual code sections of the modules are contiguous in physical space, i.e. the execution code in place. It is guaranteed that such sections of code do not extend the reserved area. The RAMIMAGE tag indicates that the contents must be determined / relocated in order to run out of RAM (assuming the loader moves code from storage to RAM when appropriate). In addition to the image storage space, additional partition types may be indicated, in which the USER-STORE is defined as a partition for the data storage space.

Partition mapping file (or SKU) 238 contains a list of uniquely identified packages and is used to map packages to specific partitions. The partition mapping file is an XML file identified for the following XSD.

An example partition mapping (SKU) file 238 will look like the following XML-formatted data.

In this particular example, an exemplary package file (“oem”) is defined in the memory configuration file 236 as a ROMIMAGE partition in which code is determined / relocated for place-in execution in the flash itself, unlike in RAM. It is mapped to a partition named "NK". As can be seen from this example, this particular partition resides on one NOR flash part indicated in the hardware section, which is located at virtual address 0x8000.0000 and is 0x380.0000 bytes long. As can also be seen in this example, a package named "lang" is mapped to a second partition called "OS" that resides within an IMGFS partition (a partition managed by a file system driver called "IMGFS"). It also resides on one NOR part specified in the hardware section (but not overlapping with the previous NK partition).

 Based on the configuration information provided in the two input files, the disk image utility 230 processes the contents of the indicated package. Each executable file located in a given package is properly placed in a unique virtual address space range through a modification or relocation process. Depending on whether the partition contents will use RAM or execute in place in flash, the disk image utility 230 may have a known limitation on where subsections of the executable file can be placed in the overall virtual address space. The address space information along with the details are used to process each executable file and to place the contents into a non-overlapping virtual address space range.

As shown roughly in FIG. 3, a fix-up process may be performed by ROMIMAGE 302 (eg, linked to or otherwise associated with disk image utility 230). Is handled by a component called. In an example implementation, ROMIMAGE 302 is a dynamic link library (DLL), which is also used on the device during package installation processing to modify / relocate code upon installation on the device. During construction, the resulting file 206 is stored in the appropriate partition in the file stored on the desktop computer building the file, using the same file system code as used on the device at run time. Code can be built on a device as well as on a host build system to minimize incompatibilities.

Before building the file, the disk image utility 230 requests the creation of a file of a predetermined size, for example a 64 MB size. After the FSDMGR 304 creates the file, the disk image utility 230 processes the memory configuration file 236 to cause the FSDMGR 304 to distinguish the reserved sections so that they remain intact. The remaining memory, for example 32 MB, is now available through FSDMGR 304. At this point, the file is already built with the necessary partitions.

As can be seen from the exemplary memory configuration file described above, a BINARY partition is preferred. More specifically, FIG. 3 shows an example of how disk image utility 230 works with romimage.dll functions and file system device driver manager 304 (FSDMGR.DLL) to build file 206. To create partitions in the file, disk image utility 230 works with FSDMGR 304 to create a master boot record (since it did not exist so far). Data indicating the accompanying BINARY partition is appended to the master boot record, that is, this data creates a partition. In this implementation, no size is specified, so all remaining flash size is now used for such a BINARY partition.

In this example, disk image utility 230 requests, via ROMIMAGE 302, FSDMGR 304 to write the update loader to the BINARY partition, as shown roughly in FIG. 3 by the arrow labeled ①. . As described in the related patent application entitled "Applying Custom Software Image Updates To Non-Volatile Storage in a Failsafe Manner" above, the update loader essentially consists of the device being updated (instead of the usual operating system code). A special section of operating system code that boots the device. Since the update loader is a binary blob of bots from the disk image utility perspective, the partition is mounted and the FSDMGR 304 uses rawfs.dll 306 to transfer these binary bits to the BINARY partition 209 ( In the space accompanying the master boot record 213).

Once written, by the call to FSDMGR 304, the actual amount of data written is obtained. In an automatic sizing operation, the new offset for the start of the subsequent partition is based on this actual size, whereby the update loader partition 209 consumes only substantially the amount of space it needs in the file.

The disk image utility 230 is recalled to create an NK partition in the file in a similar manner (ie, by writing data to the master boot record 213), which then sends the data to the NK partition. It is written by calling romimage.dll in a request to write. The parameters sent from the disk image utility 230 to build the NK partition required by romimage.dll include a list of files to be built and allocators for allocating flash space and virtual address space, as described below. Can be mentioned. romimage.dll 302 modifies this data into a set of bits and then provides them to FSDMGR 304, which, as indicated in FIG. Write NK partition via dll 306. Virtual modifications as well as physical modifications may be needed, for example, for any in-place executable code.

Again, because the size is not specified, the entire remaining space is used for this NK partition until resizing. However, in this example, instead of shifting the offset back from the end of the file based on the exact size written to the NK partition, as indicated by the shaded portion in FIG. 3, a certain amount of additional space involved in the NK bits ( Buffer) can be left in the NK partition. This free space buffer is specific to the memory XML file and substantially shifts the offset slightly ahead of the actual amount of bytes written, whereby future updates to the NK partition are more than the space consumed by the current NK partition. It allows space to be consumed, ie subsequent updates can grow.

As shown in Fig. 3 by the arrow indicated by 3, an IMGFS partition is created and written (extending the end of the file again) via romimage.dll. At this time, this is an IMGFS partition, not a binary partition, as recognized by FSDMGR 304. Thus, imgfs.dll 308 is used to write a system partition because it is a driver that handles a particular partition at run time on the device. In addition, any physical modifications are extracted via imgfs.dll 308, so that for the system partition, the romimage process 302 only performs virtual address modifications as specified. Then, automatic resizing is performed as described above, in order to shift the offset for the subsequent partition to the written data amount (in the present example, there is no free space buffer, but + any predetermined free space buffer).

The subsequent partition is USERSTORE, which can be any type of partition, in this example a partition of type 4. The USERSTORE partition is created by writing to the master boot record and extends to the end of the file. However, no data is written at this time, and thus this partition is not mounted. If the user later wishes to access this partition, the FSDMGR will do so via TFAT.dll 310 if the appropriate driver, for example, this partition corresponds to a particular file system format. Thus, although TFAT.dll 310 is not required to build the initial file, it is shown in FIG. 3 (as dashed line) as an example of a driver that can be used to access data in a user partition at run time.

Returning to the description of the operation of the present invention, in summary, the disk image utility 230 may include a platform memory configuration file 236 (eg, memory.cfg.xml) and an image listing file 238 (eg, platform. sku.xml) as input and a desktop utility that outputs a data file 206 representing the complete ROM image for the device. Since disk image utility 230 is responsible for relocating the module data, one design goal is to be able to share code with update applications on the device side.

Among other operations, disk image utility 230 is a memory layout for the device, any reserved areas, and pre-built BIN / NB0 files (NB0 file is a layout where all .bin files are displayed in ROM). Parse a memory configuration file 236 that defines the location and size for one or more flash partitions, including < RTI ID = 0.0 > The disk image utility 230 also parses an image listing file 238 that declares package-based partitions and their contents.

In the implementation outlined in FIG. 3, disk image utility 230 may configure various types of partitions, including BINARY, RAMIMAGE, ROMIMAGE, IMGFS, and USERSTORE partitions. BINARY partitions contain prebuilt NB0 files containing arbitrary data, but are not packages. As the name suggests, RAMIMAGE partitions are placed in RAM, while ROMIMAGE partitions are placed in place from the NOR part where they are stored. The image FS partition includes the partition type supported by the disk image utility 230 and can be constructed by simply forming calls to the appropriate version of IMGFS.dll 308 (via FSDMGR 304). . USERSTORE partitions can be of any individualized partition type and are currently used as the location holder in the master boot record 213 for partitions created at boot time.

The following table summarizes the input files and output files from disk image utility 230.

Terms Explanation CFG file Memory configuration file, entered by the disk image utility, that specifies hardware and partition information. Request input to the disk image utility, also known as Memory.CFG.XML. SKU file Partition mapping file / image list file entered into the disk image utility that specifies package-based partition contents. RAMIMAGE Binary partition placed for execution from RAM. May contain packages. ROMIMAGE Binary partition placed for execution from flash. May contain packages. IMGFS Partition types supported by the disk image utility. May contain packages such as packages in the system partition. USERSTORE User-defined partition type. The expected use is to create MBR entries for FAT or extended partitions, but can be of any partition type. BINARY Partition types supported by the disk image utility. Contains any data. It cannot contain packages.

Disk image utility 230 is responsible for relocating the modules to one of the package-based partitions. To realize this, the disk image utility 230 uses a virtual address (VA) allocator. The disk image utility 230 may also output a BIN / NBO file (as described above), and a Master Boot Record (MBR) for each of the flash parts of the device, including partitions for that part. Output files can be generated by using the MSPart desktop component. In addition, many of the code in the disk image utility 230 (eg, VA allocator, IMGFS interactions, module relocations) are also useful for device-side update applications, whereby the disk image utility 230 may Consider device limitations and code portability.

4 shows the overall flow of disk image utility 230. The disk image utility 230 may include a desktop component and may also include separate components for performing various operations. For example, the disk image utility may be executed via the command line, so that the disk image utility 230 may include a command line processor to process command line arguments as indicated by block 400. A separate CFG file parser can process the memory configuration file (block 402) and a separate sku / package parser can process a partition mapping (SKU) file as indicated by block 404. The components and their functions are BINARY partition generator / process (block 406), RAMIMAGE / ROMIMAGE partition generator / process (block 408), IMGFS partition generator / process (block 410), USERSTORE partition generator / process (block 412), and trailing Shown in FIG. 4 by the processor (block 414). The data structures used by the post processor and disk image utility 230 are described in the following separate sections.

As discussed above, the disk image utility 230 (eg, dskimage.exe) may be invoked via command line arguments, such as the following command.

dskimage CFGfile SKUfile

As can be seen clearly, the CFGfile parameter is a path to a memory configuration file 236, which is an input file that details the RAM and flash layouts for the current platform and defines partitions, as described above. The SKU file parameter is a path to a partition mapping / image listing file 238 that, as described above, enumerates sets of packages and assigns them to partitions. In one implementation, disk image utility 230 does not look at file extensions when parsing input files, but expects inputs with the following names when called (eg, via a script).

CFGFile = Memory.cfg.xml

SKUFile =% _TGTPLAT% .sku.xml

Currently, the command line processor only checks for the presence of command line arguments of CFGfile and SKUfile and passes them to their respective (eg XSD) validators. If the argument is specified to have a relative path, the disk image utility 230 searches for the relevant file from the directory from which the disk image utility 230 is called. If the argument is specified to have an absolute path, the disk image utility 230 uses this absolute path to search for the file. In disk image utility 230, path 1 is Environment.CurrentDirectory and path 2 is CFGfile or SKUfile. If no arguments are present, the command line processor will take appropriate action (such as catching an exception in C #, printing a usage message, or exiting).

The memory.cfg.xml parser / process is designed to give manufacturers considerable flexibility in describing hardware and assigning partitions to flash parts. In one current implementation, the memory configuration parser / processing parser (block 402 of FIG. 4) uses two levels of validation on the memory.cfg.xml file, as shown approximately in FIG. 5. First, as shown in step 500, through the C # XMLValidatingReader class, the memory.cfg.xml file is checked to see if it is the proper syntax, and XMLValidatingReader checks whether memory.cfg.xml contains valid xml and required tags. Otherwise, step 502 branches to output an error condition. The second level of verification is performed by disk image utility 230. During the second level of verification, an internal representation of RAM, flash parts, and partitions is generated. XML serialization is used to generate the internal representation (as shown in FIG. 5 by steps 504 and 506), and then detecting invalid configurations, eg, partition mapping for non-existent flash parts. For this purpose, a check on the internal structure is carried out.

In one exemplary implementation (e.g., Windows-based implementation ^CE-?), To the hardware configuration is valid, the RAM START attributes of the file cache valid kernel virtual address - and the need to refer to (0x80000000 0x9FFFFFFF), also START + LENGTH Must be valid. Any RAM_RESERVE sections must begin and end within the kernel's virtual address range specified by the START and LENGTH attributes of the parent RAM device. RAM_RESERVE elements cannot overlap (START to START + LENGTH must be unique for each RAM_RESERVE) and must have unique, non-blank ID strings.

In this example implementation, various rules may be enforced, including that NOR / NAND (collectively referred to as FLASH) must have unique "ID" attributes and cannot be named "RAM". FLASH RESERVE devices must have unique "ID" attributes and cannot have names longer than eight characters. The LENGTH attributes of the FLASH element must be evenly partitioned by BLOCKSIZE, and the BLOCKSIZE must be evenly partitioned by SECTORSIZE. For NOR devices, VASTART must be block-aligned. The LENGTH attributes of the FLASH RESERVE elements should be evenly divided by the BLOCKSIZE of the parent FLASH. For NOR_RESERVE elements, VASTART is block-aligned, and NOR VASTART and VASTART + LENGTH must not overlap with RAM or any other NOR elements and must be a virtual address of a valid cache kernel.

Also, to be valid, the NOR_RESERVE elements must start and end within the virtual kernel's virtual address range specified by the VASTART and LENGTH attributes of the parent NOR element. HARDWARE conditions can be checked using the allocator class hierarchy described below. A global allocator is created for a valid cache kernel address range and used to detect valid addresses for RAM and NOR tags and any conflicts between RAM and NOR parts. Likewise, allocators are created for each RAM and FLASH part to detect valid RESERVE regions. Allocators can be stored in related RAM / FLASH objects for easy retrieval.

Partition data is also stored in the MemoryCFG hierarchy. The rules for validation of PARTITIONs include that partitions have unique ID attributes, that the STORAGE_ID attribute of the PARTITION matches the ID attribute of the FLASH part, and that the STORAGE_ID attribute of the ROMIMAGE partition cannot refer to NAND flash. It can be mentioned. In the case of RAMIMAGE / BINARY, since the COMPRESS attribute is a Boolean type, it must be one of {0, 1, true, false}.

RAMIMAGE / ROMIMAGE / IMGFS (collectively referred to as PACKAGE partitions) is also identified, and in the current implementation, there can be only one RAMIMAGE / ROMIMAGE partition. If both are specified, the justification fails. FSRAMPERCENT and ROMFLAGS attributes (for example, ^Windows? CE- based on implementation) and corresponds to the fields in the table of contents for RAMIMAGE / ROMIMAGE partition. The FIXUP_ADDRESS of the RAMIMAGE partition is where this partition starts in RAM. This attribute must point to a valid location in RAM to have more than 0x1000 bytes of free space immediately accompanying it. Currently, there can be no more than one USERSTORE partition per FLASH part.

As mentioned above, the image listing (package-to-partition mapping or SKU) file 238 includes a list of packages organized by partitions. The XML schema (described above) is relatively straightforward. The image list file parser / process not only checks whether the SKU file contains valid XML, but also matches the partitions specified in the PACKAGE_LIST tags with the PACKAGE partition IDs in memory.cfg.xml. The PACKAGE_ID attribute of the PACKAGE_LIST tag must match the ID attribute of the PACKAGE partition element, and if no match is found, the SKU parser throws an exception. Steps 600, 602, and 604 of FIG. 6 summarize these various operations.

Each PACKAGE_LIST tag has a required PARTITION_ID attribute. Matching packages to partitions includes taking the PARTITION_ID attribute and using it as a lookup into the C # HashTable. If a match is found, the child PACKAGE_FILE tags are converted to an ArrayList and merged with the existing package list for the PACKAGE partition. Extracting the packages can be performed in the following manner.

/// for each PackagePartition

/// {

/// for each package in the PackagePartition

/// create directory .＼DskImage＼PartitionID

/// {

/// open the file .＼Packages＼PackageName

/// error if file not found

/// extract content to .＼DskImage＼PartitionID

/// error if extraction fails

///}

///}

The disk image utility 230 checks for the existence of the _FLATRELEASEDIR environment variable and uses it as the current working directory if found. This is consistent with the behavior of conventional build systems in _FLATRELEASEDIR that only allow users to perform "makeimg" from any directory while only manipulating files.

Partitions are created and managed by the desktop (build system) version of MSPart (such as the traditional Windows ^® CE build system). Due to the MSPart interface, disk image utility 230 can extract details about underlying hardware from the actual configuration of partitions. Any hardware-specific adjustments to the NBO file created by the MSPart are performed in post processing. The MSPart can be used by the rest of the disk image utility 230 tool, if so, before creating any partitions, an MSPart volume is created for each of the FLASH parts and any RESERVE sections are displayed, as described below. The disk image utility 230 includes a separate class fsdmgr.cs that wraps the necessary unmanaged functions. This process includes a global HashTable of flash parts so that each can be accessed by name and repeated through it. The process is realized by iterating over the FlashReserve elements of each of the Flash parts and forming the calls to fsdmgr.dll, as shown roughly in FIG. The RESERVE areas are filled with data as it is actually created. To do this, the FSDMgr class places data to fill the RESERVE area from the disk image into fsdmgr_nt.dll.

The first step in building an NBO is to add BINARY partitions to the MSPart-mounted volume. Because BINARY partitions are entirely self-contained (ie, they do not require modification and do not require SectorData metadata on the NOR), they are processed first. As outlined above, building BINARY partitions is relatively straightforward, and this process repeats through an array of BinaryPartitions and invokes their Create () methods. Since each Partition object points to its parent flash part, finding the appropriate volume handle is also very straightforward.

In one implementation, the PartitionInfo class (part of the MemoryCFG hierarchy) includes a function called CreateAllPartitions that iterates over BinaryPartition objects and begins by calling their Create () method. The BinaryPartition.Create () function creates and mounts a new partition for a particular flash block, opens the file specified by the DATAFILE attribute from memory.cfg.xml, and is called by FSDMgr to write data to the partition. The pseudocode for this specification is set as follows (using some MSPart APIs).

As mentioned above, the disk image utility provides " romimage " used to create partitions of type ROMIMAGE and RAMIMAGE, which are partitions executed in place from ROM and RAM, respectively. These partitions typically contain the minimum set of system components needed to build an IMGFS file system: nk, coredll, filesys, fsdmgr, mspart, imgfs, and any block drivers needed.

ROMIMAGE / RAMIMAGE processing can generally be broken down into various steps (eight listed in the current implementation, and also shown as steps 801 through 808 in FIG. 8).

Build and sort a list of modules and files (step 801);

Allocating virtual address space to all modules (step 802);

Performing module modifications (step 803);

Compression of all data sections and files (step 804);

Perform physical layout (step 805);

Allocation of copy sections (step 806);

Performing kernel module modifications (step 807); And

Actual partition output (step 808)

Each of the above steps may be performed by forming calls to romimage.dll, which facilitates access to function assignment and relocation from various applications (eg, C and C # applications). The disk image utility can interface with romimage.dll through a wrapper class called ROMImage.cs.

romimage.dll includes functions for creating and managing the Allocator class hierarchy and multiple Allocators, creating and managing the File class hierarchy and lists of files, and functions for performing the steps of the ROMIMAGE / RAMIMAGE partition building process. .

The Allocator class hierarchy is used to manage the physical space available in RAM and FLASH. This represents the ability to perform both arbitrary assignments and fixed reservations. The Allocator class (and child AllocNode) is defined as follows:

romimage.dll exports the following functions for manipulating Allocators.

Valid flags for the Allocate function include BOTTOMUP_ALLOC and TOPDOWN_ALLOC. As can be seen from the names, all of these are the first-fit algorithms, which search for free space starting at the bottom and top of the current allocation window, respectively. They require a linear search (so performance bottlenecks can occur when multiple allocations are requested).

The File class is used to store all metadata about a file or module and is defined as follows:

On the desktop computer building the file, the contents of each file are memory-mapped and pointed to by the data members of the File and Section classes. The following data structure is defined to manipulate the File class hierarchy.

The following functions are provided for building RAMIMAGE / ROMIMAGE partitions.

HRESULT BuildNKPartition (HANDLE hFile List,

        HANDLE hVolume,

        HANDLE hSlot0Alloc,

        HANDLE hSLot1Alloc,

        HANDLE hPhysAlloc,

        HANDLE hRAMAlloc,

        DWARD dwReserved);

here,

 hFileList is a handle to a FileList object-the creation of FileList objects is discussed in the next section;

hVolume is a handle to the MSPart volume created by DskImage during partition creation;

hSlot0Alloc is a handle to length 0x1A00000 allocator starting with 0x600000;

hSlot1Alloc is a handle to the length 0x1F00000 allocator starting with 0x210000.

hPhyAlloc is the physical allocator (flash part for ROMIMAGE partitions, RAM for RAMIMAGE partitions);

hRAMAlloc is a RAM allocator corresponding to the RAM element of memory.cfg.xml;

dwReserved is a pointer to the MiscNKInfo structure defined as follows:

typedef struct _MiscNKInfo

{

USHORT cbSize;

USHORT usCPUType;

DWORD dwROMFlags;

DWORD dwFSRAMPercent;

BOOL fCompressPartition

} MiscNKInfo;

To build and sort the list of modules and files (step 801 of FIG. 8), Romimage.dll manages a linked multiple list of files and modules. To build the list, Romimage.dll provides the following functions.

HRESULT CreateFileList (PHANDLE phFileList);

HRESULT DestroyFileList (HANDLE hFileList);

HRESULT AddFileToList (HANDLE fFileList,

        wchar_t * szFileName,

        DWORD dwFlags,

        wchar_t * szPathToFile,

        BOOL fLoadData,

        PHANDLE phFile);

There may be APIs for moving File objects from one file list to another. Such a function may be of the form

HRESULT SpliceFile (HANDLE hSrcList,

        HANDLE hDstList,

        HANDLE hFile);

To allocate the virtual address space to the modules (step 802 of FIG. 8), Slot 0/1 virtual address assignment requires a FileList, an Allocator for Slot 0, and an Allocator for Slot 1. The FileList may already be sorted in the proper order, and then the built-in DoVAAlloc method should perform the assignment according to the following logic.

/// find FileList and Allocators referenced by handles passed to DoVAAlloc

/// error if none of these components is found for each File in the FileList

/// {

/// Is File a kernel or kernel module?

/// {

/// save for later-proceed to subsequent file

///}

/// Is the file a slot 1 DLL?

/// {

/// perform slot 1 code assignment

/// go to slot 0 if allocation fails

/// perform slot 0 data allocation

/// error if allocation fails

///}

/// Is the file a slot 0 DLL?

///}

/// perform slot 0 code assignment

/// error if allocation fails

/// perform slot 0 data allocation

/// error if allocation fails

///}

/// Is File just a File?

/// {

/// do nothing-proceed to subsequent file

///}

///}

Module modifications are performed for everything except kernel modules, as indicated by step 803 of FIG. 8. To do this, the following function is provided in the FileList class:

HRESULT DoVAFixups (BOOL fReverse);

The fReverse argument specifies whether the module should be modified or returned to its original value. This functionality is requested by the device-side update application, but on desktop computers building files, fReverse will always be FALSE (caller only needs to specify a list of files). Previously, romimage.exe was iterated through a .rel file and modified the entire module at once, but with a componentized update, "the ability to modify only certain pages in a section" is needed. The FixupBlob function in the Module class supports passing arbitrary pointers to module data, modifying it by iterating through the creloc section and finding only the fixes that apply to that data. Disk image utility 230 calls it once per module section. The device-side update application will call it after each bandiff page it reconfigures. At this point, relocation information for the module is stored within the module (in the .creloc section). Thus, for device-side updates, the necessary information is included in the module itself, so no further repetition is necessary.

Before the physical layout is performed in step 808 of FIG. 8, the module data sections are compressed as shown in step 804 of FIG. 8. Disk image utility 230 does not support compression of code sections of modules because ROMIMAGE and RAMIMAGE partitions are intended to be executed in place. However, if desired, code compression can be easily added.

The following functions are provided in the FileList class for compression.

HRESULT DoCompression ();

DoCompression repeats for a particular FileList and compresses all data sections except kernel modules. The psize member of the o32rom header stored in the Section class is updated to reflect the compressed data length. Any suitable compression algorithm would be used, for example one current romimage.exe implementation uses an algorithm that is optimized for decompression. However, since romimage.dll is used by the device side update application, other algorithms may be used instead.

Once the data sections are compressed, this process has the information needed to perform the physical layout. To do this, the following function is provided in the FileList class:

HRESULT DoPhysicalLayout (Allocator & Alloc)

Step 805 of FIG. 8 shows outputting partitions. For ROMIMAGE partitions, the Allocator of the associated FLASH part is used. The starting position of this partition is determined by the MSPart being queried. For RAMIMAGE partitions, a RAM Allocator for the physical layout is used. The starting position of this partition is determined by the FIXUP_ADDRESS attribute for the RAMIMAGE element of the partition.

DoPhysicalLayout uses the most appropriate algorithm and iterates through the contents of the FileList in the following order:

1. Code sections (page aligned)

2. Data sections (including .creloc and all files)

3. A table of contents (including all TOC entries)

4. All e32 headers

5. All o32 header blocks

6. Copy section block

7. File Names

During this phase, the majority of TOCs are generated. This is necessary for a place to store the physical location of the module headers. By generating the TOC, since the module headers are laid out, there is no need to create another data structure to hold this metadata.

To allocate space for copy sections (step 807 of FIG. 8) and kdata, a RAM Allocator is used. This step may be performed for ROMIMAGE partitions first, but not to keep the ROMIMAGE and RAMIMAGE processes as similar as possible. As with slot 0/1 allocation, a function is provided in the FileList class.

HRESULT DoCopySectionAlloc (Allocator% Alloc);

Once this step is complete, this process can populate the pToc's RAMStart, RAMFree, and RAMEnd attributes.

Once the copy sections have been allocated, the kernel and kernel modules are modified, as indicated by step 806 of FIG. As with slot 0/1 modification, the following function is provided in the FileList class:

HRESULT DoKernelVAFixups (BOOL fReverse);

DoKernelVAFixups iterates through the list of kernel modules and performs the necessary modifications by calling the DoKernelFixups method for each module object.

At this point, everything is modified and the physical allocations have already been made. Disk image utility 230 has already communicated with the MSPart and has a handle to the partition seeking data. In order to output the final image, a function for writing partitions is provided.

HRESULT DoWriteNKPartition (HVOL hVolume, Allocator &Alloc);

For RAMIMAGE and ROMIMAGE partitions, DoWriteNKPartition generates a representation of a partition in RAM and then outputs that memory block to a file, similar to how disk image utility 230 itself handles BINARY partitions. . When writing, the Alloc argument is required for ROMIMAGE partitions that must skip the RESERVE areas.

While the physical layout for RAMIMAGE partitions uses the RAM Allocaor, there are only relatively small differences between ROMIMAGE and RAMIMAGE partitions, including the physical layout for ROMIMAGE partitions using the Allocator of the parent flash part. Also, because there may not be enough space in the flash part, the DoWriteNKPartition for the RAMIMAGE partitions may fail. Since ROMIMAGE partitions use the Allocator of the parent flash part, DoWriteNKPartition never fails for ROMIMAGE partitions. An implementation in which managed dskimage.exe forms calls to unmanaged romimage.dll may be possible in both C and C #.

The disk image utility 230 is responsible for iterating through the list (DSM) file in _FLATRELEASEDIR_DskImage_Partition to add DSM entries (and the DSM file itself) to a FileList for romimage.dll to process. For ROMIMAGE partitions, disk image utility 230 creates a new partition before it is called into MSPart to attempt a physical layout (in RAMIMAGE, disk image utility 230 can create a partition at any time). After the partition is output, the disk image utility 230 resizes it, as described above. Other operations are handled by romimage.dll.

As mentioned above, another package partition type built is IMGFS. This is built after others for a variety of reasons, including the allocation of RAMIMAGE / ROMIMAGE areas first because of the limitations imposed by the Windows CE kernel. IMGFS partitions require SectorInfo for the NOR. . The example NOR flash media driver assumes that the flash is organized so that partitions containing SectorInfo follow those without SectorInfo. The steps in building an IMGFS partition are similar to the steps for ROMIMAGE / RAMIMAGE partitions. The following steps are substantially recycled from the ROMIMAGE / RAMIMAGE partition generator.

Building and sorting lists of modules and files;

Allocating virtual address space to all modules;

Performing module modifications; And

Physical partition output

The physical layout for IMGFS is handled by IMGFS and MSPart. Like the RAMIMAGE / ROMIMAGE partitions, there is a BuildIMGFSPartition API for writing IMGFS partitions.

HRESULT BuildIMGFSPartition (

        HANDLE hFileList,

        HANDLE hVolume,

        HANDLE hSlot0Alloc,

        HANDLE hSlot1Alloc,

        DWORD dwReserved);

The specified Slot 0 and Slot 1 allocators are expected to be the same as those used earlier to build the RAMIMAGE / ROMIMAGE partition.

IMGFS is responsible for compression. By default, the Files and Module data sections are compressed.

IMGFS partitions cannot contain kernel modules (modules with the K flag in ce.bib). Thus, before performing VA allocation, the BuildIMGFSPartition verifies that a particular FileList does not contain any kernel modules.

Next, the following FileList member functions are called.

1.DoVAAlloc

2. DoVAFixups

3.DoWriteIMGFSPartition (Figure 9)

As shown roughly in Figure 9, after performing module modifications, this process iterates through the particular FileList (step 900 and step 918), creating a new file of IMGFS for each entry. If the current list item is a module (step 902), it is processed in sections (steps 904 to 912). Otherwise, a file is created (step 914) and data is written (step 916).

Another partition type built is USERSTORE, which is virtually any type of file system the user wants. This is ideally designed for FAT or extended partitions (PART_TYPEs 0x04 and 0x05). In one current implementation, memorycfg.xsd does not allow users to specify the length for USERSTORE, so this partition extends the rest of the flash. To build a USERSTORE, this process is called with FSDMGR to create a partition of a particular PART_TYPE, instructing FSDMGR to use the remaining space on the flash part, i.e. auto-sized. , There is a limit of one USERSTORE per flash part).

Post-processing

According to one aspect of the invention, when complete, the disk image utility creates one file 206 on a build (eg, desktop) system that includes one or more partitions corresponding to different file systems. . Within these partitions, the contents of packages whose executable modules have been modified in the virtual address space will be installed. At this point, the user is only instructed that certain features of the hardware, that is, RAM and storage space locations (addresses), their sizes, and whether the storage space is linear or block-based. Whether the flash is a NOR flash, a NAND flash, a hard disk drive, or any other type of storage space is not yet specified. The storage technology can affect the image, depending on how it is managed.

For example, flash storage space is typically divided into blocks and further divided into pages or sectors, as shown approximately in FIGS. 10A and 10B. The size of each of these sub-components, the manner in which the storage technology identifies each (e.g. numerically), and the manner in which the bad / reserved / readable state for each page or sector is managed are storage-technology specific. to be.

The purpose of the post processing step is to introduce this management information into the image in a manner that does not violate the requirements of the image layout, as specified in the input files to the disk image utility. For example, if one of the partitions runs in NOR flash, there are CPU requirements that specify that this should be able to be mapped to the CPU in CPU page increments and that this cannot be changed due to storage management requirements.

The post processing step of the disk image utility 230 tool is used to form storage hardware-specific adjustments to the MSPart-generated NB0 files. For example, as shown in FIG. 10A, a NAND flash has sector information (metadata m for each sector) with sectors being separate spaces. However, the NOR hardware uses the SectorInfo in the block for each sector, as shown approximately in FIG. 10B by the metadata m for the three sectors of the 4-sector block contained in the remaining sectors of each block. You must change the IMGFS partition to include it. To align the blocks, some space may not be used, as indicated by the shaded areas in FIG. 10B. When manufacturing a device with a paired flash, one may also want to distinguish NB0 into separate files for each flash part.

Post processor 232 (FIG. 2, for example postproc.exe) may be automatically executed by disk image utility 230 on any NOR flash elements of memory.cfg.xml. Given the ID, VASTART, BLOCKSIZE, and SECTORSIZE attributes of the NOR element, the post processor outputs ID.nb0.postproc and ID.bin. For further post processing of the disk image utility 230 output, the user (eg, an OEM) may create a postdiskimage.bat file to be called by the buildpkg script when the disk image utility 230 processing is complete. .

In operation, post processor 232 opens NB0 to retrieve the mask boot record and uses the data therein to place the IMGFS partition. Subsequent processor 232 then adds sector data in a format that can be recognized by the block driver (e.g., NOR) to each sector. Also, if USERSTORE exists, post processor 232 moves the start of USERSTORE and stores the changed NB0 since sector data can no longer correspond to the start of the flash block after it has been added to IMGFS. The post processor 232 may further convert the changed NB0 into a binary file for legacy bootloaders.

While the present invention may be modified in various changes and other configurations, certain exemplary embodiments of the invention have been shown in the drawings and described above. It is to be understood, however, that the intention is not to limit the invention to the particular forms disclosed, but rather, to cover all modifications, other configurations, and equivalents falling within the spirit and scope of the invention.

As can be seen from the above detailed description, a mechanism is provided for converting operating system image components into file system-based manufacturing images. The image file is independent of any particular storage technology and facilitates componentized updating of the device while being suitable for use as the initial image.

1 is a block diagram schematically illustrating a computer system in which the present invention may be incorporated.

FIG. 2 is a block diagram illustrating an output file in which different partitions are constructed that contain data for writing as an image on an embedded device or other medium, in accordance with an aspect of the present invention.

3 is a block diagram illustrating various components used to construct an output file, in accordance with an aspect of the present invention.

4 is a flowchart showing the overall flow of a disk image utility constituting an output file, according to one aspect of the present invention.

5 is a flow diagram illustrating logic for identifying a memory configuration file, in accordance with an aspect of the present invention.

6 is a flowchart illustrating a process of identifying a package-to-partition mapping file and matching specific partitions to packages in accordance with an aspect of the present invention.

7 is a flowchart illustrating processing of flash elements, in accordance with an aspect of the present invention.

8 is a flowchart illustrating a process of configuring ROM / RAM-based partitions, in accordance with an aspect of the present invention.

9 is a flowchart showing a process of writing a system partition according to an aspect of the present invention.

10A and 10B are block diagrams illustrating different ways in which sectors and blocks are aligned to flash memory as handled by a post processing in accordance with one aspect of the present invention.

<Explanation of symbols for main parts of the drawings>

202: full flash

204: Available (Virtual) Flash

206: output file to write

209: compressed UL

210: kernel (NK) partition

211: system partition

212: user storage

213: MBR

214: Existing boot loader on older devices

215: IPL

230: Disk Image Utility

232: postprocessor

234: Packages

236: memory configuration file

238: SKU file

Claims (41)

In a computing environment, Accessing packages containing image data for installation in a first storage medium; Accessing a description of partitions into which the contents of the package will be written; And Generating an output file on a second storage medium, the output file comprising partitions, the contents of each package being stored in one of the partitions based on the description. The method of claim 1, Accessing a memory configuration file to determine the location of one or more of the partitions in the output file. The method of claim 1, One or more package contents correspond to operating system components, One of the partitions comprises a system partition, Based on the technique, further comprising writing the operating system component to the system partition. The method of claim 1, One or more package contents correspond to kernel components, One of the partitions comprises a RAM-based image partition, Based on the technique, further comprising writing the kernel component to the RAM-based image partition. The method of claim 1, The one or more package contents correspond to kernel components, One of the partitions comprises a ROM-based image partition, Based on the technique, further comprising writing the kernel component to the ROM-based image partition. The method of claim 1, The one or more package contents correspond to an update loader component, One of the partitions comprises a binary image partition, Based on the technique, writing the update loader to the binary image partition. The method of claim 1, Generating the output file, Writing data to a partition extending to the end of the file, and Adjusting the size of the partition based on the actual amount of data written. The method of claim 1, Generating the output file, Writing data to a partition extending to the end of the file, Adding a free space buffer after the end of the written data, and And resizing the partition based on the actual amount of data written and the free space buffer. The method of claim 1, Writing data to a master boot record of the file to define a partition. The method of claim 7, wherein Writing data to the master boot record comprises defining a user storage space partition. The method of claim 1, Writing additional data to the output file. The method of claim 1, Executing post-processing to prepare for data transfer from the output file to the first storage medium. The method of claim 12, The first storage medium includes a flash memory in which code therein may be executed in place, The method is Accessing a memory configuration file to modify one or more of the partitions such that code therein is executed in place. The method of claim 1, Accessing a memory configuration file to determine which sections of the first storage medium are reserved. One or more computer-readable media having computer-executable instructions that, when executed, perform the method of claim 1. In a computing environment, Accessing a file containing partitions having image data for installation on a storage medium; And Processing the file to introduce any changes to the partition and file system layout as required by a particular storage technology. The method of claim 16, Delivering data corresponding to the particular storage technology from the file to the storage medium. The method of claim 16, Accessing a memory configuration file to determine a location of one or more of the partitions in the output file. The method of claim 16, The image data corresponds to packages, Generating the file from a partition-to-package mapping file and a memory configuration file. One or more computer-readable media having computer-executable instructions that, when executed, perform the method of claim 17. In a computing environment, Disk image utility processing for inputting a partition-to-package mapping file including partition information and package information-outputting an image file using the identified package in the package information based on the data of the files, and outputting the image file. Includes a plurality of partitions identified in the partition information, wherein the contents of each package are stored in one of the partitions based on the description; And A post processing to process the image file to introduce any changes to the image as required by a particular storage technique. The method of claim 21, The disk image utility processing further inputs a memory configuration file containing data indicating how storage space for the device is configured. The method of claim 22, The apparatus is configured to have a memory therein in which code can be executed in situ, The memory configuration file is accessed to modify one or more of the partitions so that code is executed in place therein. The method of claim 22, The memory configuration file is accessed to determine which sections of device memory are reserved. The method of claim 21, One or more package contents correspond to operating system components, One of the partitions comprises a system partition, And the disk image utility writes the operating system component to the system partition based on the description. The method of claim 21, One or more package contents correspond to kernel components, One of the partitions comprises a RAM-based image partition, And the disk image utility writes the kernel component to the RAM-based image partition based on the description. The method of claim 21, The one or more package contents correspond to kernel components, One of the partitions comprises a ROM-based image partition, And the disk image utility writes the kernel component to the ROM-based image partition based on the description. The method of claim 21, The one or more package contents correspond to an update loader component, One of the partitions comprises a binary image partition, And the disk image utility writes the update loader to the binary image partition based on the description. The method of claim 21, And the disk image utility writes data to a partition extending to the end of the file and adjusts the size of the partition based on the actual amount of data written. The method of claim 21, The disk image utility writes data to a partition extending to the end of the file, adds a free space buffer after the end of the written data, and based on the actual amount of data written and the free space buffer, System to resize. The method of claim 21, The disk image utility writes data to the master boot record of the file to define a partition. The method of claim 31, wherein The disk image utility defines a user storage space partition by writing data to the master boot record. One or more computer readable media having stored thereon data structures that are processed to create an operating system image on a storage medium. The data structure is, A first data set comprising a master boot record, each defining partitions corresponding to a file system; A second data set comprising a binary partition; A third data set comprising a storage-based partition; And One or more computer readable media comprising a fourth data set comprising a system partition The method of claim 33, wherein And the binary partition comprises update loader code. The method of claim 34, wherein And the update loader code is compressed in the binary partition. The method of claim 33, wherein And the storage-based partition comprises a RAM image partition containing kernel code. The method of claim 36, The kernel code is compressed in the RAM image partition. The method of claim 33, wherein And the storage-based partition comprises a ROM image partition containing kernel code. The method of claim 33, wherein At least one computer readable medium comprising operating system components. The method of claim 33, wherein And the master boot record of the first data set defines a user storage space partition as one of the defined partitions. The method of claim 33, wherein The data structure is, At least one computer readable medium further comprising a fifth data set containing initial program loader code.