KR20060095133A - Method for operating system program stored in non-volatile memory - Google Patents

Abstract

The present invention relates to a method for running a system program stored in a nonvolatile memory.

The present invention provides a method of driving a system program stored in a nonvolatile memory, comprising: (a) checking whether boot header information is valid in a controller; (b) if the boot header information is valid, initializing an internal register of the controller using the boot header information, and executing a startup program for system initialization; (c) checking whether a system program stored in a 'Not Used Sectors' area of the nonvolatile memory is valid; (d) if the system program is valid, moving the system program to an address of the volatile memory included in the boot header information; And (e) running the system program transferred to the volatile memory in the controller to drive the system.

According to the present invention, the system program stored in the 'Not Used Sectors' area of the nonvolatile memory can be moved to the volatile memory using the boot header information to be driven.

 Nonvolatile Memory, Volatile Memory, Controllers, System Programs, Boot Header Information

Description

Method for Operating System Program Stored in Non-Volatile Memory

1 is a view showing the structure of a general FAT,

2 is a view showing the structure of a FAT according to a preferred embodiment of the present invention;

3 is a diagram showing boot header information for driving a system program according to an embodiment of the present invention;

4 is a flowchart illustrating a method of driving a system program stored in a nonvolatile memory according to an exemplary embodiment of the present invention.

The present invention relates to a method for running a system program stored in a nonvolatile memory. More specifically, the controller controlling the memory checks whether the boot header information is valid, and if the boot header information is valid, initializes an internal register of the controller and executes a startup program for system initialization. Check whether the system program stored in 'Not Used Sectors' area is valid.If the system program is valid, move the system program to the address of volatile memory included in the boot header information, and execute the system program moved from the controller to volatile memory. A method of driving a system program stored in a nonvolatile memory for driving a system.

As electrical and electronic technologies are rapidly evolving, various functions that provide specific functions are provided with data input / output units, memory, data processing and control signals such as MP3 players, electronic dictionaries, and personal digital assistants (PDAs). Electronic products are used in everyday life. These electronic products can exchange data by connecting to an external device such as a computer, and have a controller that accesses the memory to perform read / write operations and drives a program stored in the memory. In order for the controller to operate, the initialization program must be stored in non-volatile memory. Since volatile memory loses its stored information when the power is turned off, volatile memory usually cannot operate the controller alone.

If you store a program in nonvolatile memory, such as NOR-FLASH or ROM, you can run the program stored in nonvolatile memory directly on the controller. However, if a program is stored in nonvolatile memory such as NAND-FLASH, Serial-FLASH, or HDD, the stored program cannot be executed directly from the controller. It must be run after moving to volatile memory such as SDRAM.

For example, if an electronic product has NAND-FLASH memory and volatile memory, the initialization program should be stored in ROM inside the controller, and the program stored in NAND-FLASH is moved to volatile memory according to the ROM code. The program will run later.

Here, the volatile memory is controlled by the controller according to the type, so in order to execute the program after moving the program stored in the nonvolatile memory to the volatile memory, the controller must know the type of the volatile memory. Conventionally, in order to check the type of volatile memory in the controller, a method using an external pin option of the controller, a method of checking the type of volatile memory through a bit configuration, and a specific type of volatile memory in a ROM inside the controller A method of determining a volatile memory to be controlled is used. However, the above-described schemes have a problem in that they cannot control all kinds of volatile memories.

Meanwhile, the nonvolatile memory of the electronic product may store a system program for driving the entire system in the controller, and it is necessary to consider in which position of the nonvolatile memory storage area the system program is to be stored.

Because electronics with nonvolatile memory can be connected to a computer, nonvolatile memory must store data in a format that can be processed by a computer, such as a file allocation table (FAT), so that system code must not be stored in the boot area. . The computer will boot the computer by executing a boot program stored on the hard disk. The booting process is performed according to the promised procedure according to the information of the boot area in the FAT. If the system code is stored in the boot area of the nonvolatile memory, the computer may recognize a system program executed by the controller as the boot program of the computer and cause a malfunction.

Therefore, in order to prevent the system program stored in the nonvolatile memory from affecting the computer, the area in which the system program is stored is treated as a 'Bad Block' so that only the controller can access it, or the size of the total memory capacity excluding the system program occupies I'm using a computer to tell me. However, if the above-described methods are applied, the area in which the system program is stored in the external computer cannot be recognized, and thus, the system program becomes inaccessible even when the system program needs to be upgraded. In this case, the controller is inconvenient to have a program for managing an area accessible by the computer and a program for managing other areas.

In order to solve the above problems, the present invention checks whether the boot header information is valid in the controller controlling the memory, and if the boot header information is valid, initializes an internal register of the controller and executes a startup program for system initialization. The system checks whether the system program stored in the 'Not Used Sectors' area of the nonvolatile memory is valid.If the system program is valid, the system program is moved to the address of the volatile memory included in the boot header information. It is an object of the present invention to provide a method of driving a system program stored in a nonvolatile memory that drives a system by executing a transferred system program.

According to an object of the present invention, a system program stored in the non-volatile memory in a system including a non-volatile memory (Volatile), a volatile memory (Volatile) and a controller for controlling the non-volatile memory and the volatile memory A method comprising: (a) checking at a controller whether boot header information is valid; (b) if the boot header information is valid, initializing an internal register of the controller using the boot header information, and executing a startup program for system initialization; (c) checking whether the system program stored in the 'Not Used Sectors' area of the nonvolatile memory is valid; (d) if the system program is valid, moving the system program to an address of the volatile memory included in the boot header information; And (e) running the system program transferred to the volatile memory in the controller to drive the system.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used as much as possible even if displayed on different drawings. In addition, in describing the present invention, when it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

1 is a view showing the structure of a general FAT.

In order to access data stored in a storage device such as a memory, a file system for collectively maintaining file naming, storage, organization, and the like is required. The FAT file system searches a file arrangement table called FAT to find a file stored in a storage device and finds a location where the data exists and accesses the data. In a storage device such as a nonvolatile memory that stores data according to the FAT file system, an area for managing data exists in addition to the data storage area.

The area for managing data is composed of areas such as MBR (Master Boot Record), 'Not Used Sectors', 'Reserved Sectors', FAT1, FAT2 and the like as shown in the FAT structure shown in FIG.

The MBR is the first sector of nonvolatile memory, and is the first sector to be read when power is applied to perform the boot process. The MBR has a partition table that contains information about the location of each partition in memory, and contains a program that can read the boot sector of a partition.

The 'Not Used Sectors' area is located between the MBR and the 'Reserved Sectors' area. The area used for data management remains unused and generally has a capacity of several tens of sectors. The 'Not Used Sectors' area can be allocated to protect the MBR and 'Reserved Sectors' areas, or can be allocated to locate FAT1 and FAT2.

The 'Reserved Sectors' area consists of a boot record, a FAT32 information sector and a number of reserved sectors. The boot record has information on the physical structure of the memory, such as FAT parameter (PBB) information, memory capacity, and stores an operating system (OS) driving program. Therefore, the boot process is performed by reading a boot record and executing a stored OS driving program. The FAT32 information sector is a sector existing in the FAT32 file system and includes information such as the number of FATs, the number of bytes constituting one sector, the number of sectors constituting one cluster, and the number of reserved sectors.

FAT1 is a file information allocation area and contains information on a location where a file is stored in memory, a file size, an attribute, and the like. Since FAT1 manages memory in cluster units, it records the empty clusters and the clusters in use. When a file is stored in multiple clusters, FAT1 records and manages the location and order of each cluster that stores the files. FAT2 has the same information as FAT1 as a backup copy of FAT1. When FAT1 is damaged, the damaged information of FAT1 can be recovered by using the information stored in FAT2.

2 is a view showing the structure of a FAT according to a preferred embodiment of the present invention.

As shown in FIG. 2, in the present invention, a system program for driving a system incorporating a nonvolatile memory using an unused area remaining in data management area is stored in a 'Not Used Sectors' area. Manage it.

If the system program is stored in the 'Not Used Sectors' area, the external computer can recognize the area where the system program is stored, but since the system program is not stored in the boot area of the non-volatile memory, the system program operates in the external computer. Will not affect. In addition, it is not necessary to have a separate driver program for accessing the area where the system program is stored.

3 is a diagram illustrating boot header information for driving a system program according to an exemplary embodiment of the present invention.

The boot header information includes information for operating a system program stored in nonvolatile memory in the controller. A description of each item of the boot header information is as follows.

As illustrated in FIG. 3, the boot header information may distinguish each item in units of 32 bits, which is basically a word size, but may allocate fewer bits according to the item. The 'Startup Code Size' item in the first line of the boot header information indicates the size of the startup code of the startup program for system initialization, and the 'Header Size' item indicates the size of the boot header information. Bits 20, 21, and 22 of the first line are set to C, T, and S items, respectively, and their roles are as follows.

The S item is a bit to set whether to execute the startup code. When the S item is set to '1', the controller executes the startup code. The L item is a bit for setting whether to transfer the system code from the nonvolatile memory to the volatile memory. When the L item is set to '1', the system code stored in the nonvolatile memory is transferred to the volatile memory. Therefore, L type should be set to '1' if nonvolatile memory where system code is stored is the kind that NAND-FLASH, Serial-FLASH, hard disk, etc. can't directly execute the program stored in nonvolatile memory. . If the L item is set to '1', the system code is downloaded to the main code start address. The C item is a bit to set whether to perform a checksum for validating the code area. When the C item is set to '1', the controller performs a checksum for the code area. .

The 'Register Number' item on the second line of the boot header information indicates the number of registers to be used by the controller. As shown in FIG. 3, the boot header information has an address and a register value of each register as many as the number N of registers set in the 'Register Number' item. Each register value is assigned to the address of the corresponding register to initialize and use the internal registers of the controller. The 'R / B GPIO Number' item sets the General Purpose Input Output (GPIO) pin number assigned to detect the Ready / Busy signal and is valid when the nonvolatile memory is NAND-FLASH. From the third line of the boot header information, the aforementioned N register addresses and register values are displayed in order.

The 'Serial Number' item displays the serial number of the system. The 'Startup Code Load Address' and 'Main Code Start Address' items respectively indicate the startup code drive address and the main code start address. The startup code is executed after it is copied to the startup code drive address, and the main code (ie system code) is executed after it is copied to the main code start address. Since the system code stored in the nonvolatile memory must be executed by the controller after being transferred to the volatile memory, the main code start address can be set to point to a specific location of the volatile memory for moving the system code.

The 'Main Code Size' item indicates the size of the system code, the 'Code Area Checksum' item and the 'Header Area Checksum' item respectively record the code area checksum and header area checksum result, and the 'Header Signature' item. Records the header signature. Here, the code region checksum is performed to verify whether the system program is valid, and the header region checksum is performed to verify whether the information recorded in the boot header is valid.

On the other hand, the configuration order of the boot header information is not limited to the above-described configuration, and the boot header information may be configured by changing the position of each item in accordance with the manner in which the controller analyzes the boot header information.

4 is a flowchart illustrating a method of driving a system program stored in a nonvolatile memory according to an exemplary embodiment of the present invention.

As described above with reference to FIG. 2, the system program is stored in the 'Not Used Sectors' region located between the MBR of the nonvolatile memory and the 'Reserved Sectors' region, and the process of driving the system program is as follows.

When power is applied to a system including a nonvolatile memory, a volatile memory, and a controller that controls the memory, the controller performs a booting process (S400). The controller checks whether the boot header information is valid to perform a booting process (S402). To this end, the header area checksum result value of the 'Header Area Checksum' item of the boot header information may be checked to verify whether the information recorded in the boot header is valid.

If the boot header information is valid, the internal register of the controller is initialized using the register setting information recorded in the boot header information (S404), and a startup program for system initialization is executed (S406). Here, the startup code of the startup program is executed after being copied to the startup code driving address recorded in the 'Startup Code Load Address' item of the boot header information.

After executing steps S404 and S406, it is checked whether the system program stored in the nonvolatile memory is valid (S408). To this end, it is possible to verify whether the system program is valid by checking the code area checksum result value of the 'Code Area Checksum' item of the boot header information.

If the system program is valid, the controller moves the system program stored in the nonvolatile memory to the address of the volatile memory included in the boot header information (S410). That is, the controller copies the system program to the address of the volatile memory recorded in the 'Main Code Start Address' item of the boot header information. When the system program is transferred to the volatile memory, the controller executes the system program stored in the volatile memory, and drives the system by the executed system program (S412).

The above description is merely illustrative of the present invention, and those skilled in the art to which the present invention pertains may various modifications without departing from the essential characteristics of the present invention. Accordingly, the embodiments disclosed herein are not intended to limit the present invention but to describe the present invention, and the spirit and scope of the present invention are not limited by these embodiments. It is intended that the scope of the invention be interpreted by the following claims, and that all descriptions within the scope equivalent thereto shall be construed as being included in the scope of the present invention.

As described above, the present invention can be executed after the system program stored in the nonvolatile memory is transferred to the volatile memory using boot header information, and the hardware of the controller needs to be changed according to the type of volatile memory to be controlled by the controller. The effect is that the system program can be run by modifying the boot header information without

In addition, the present invention is to store a system program in the 'Not Used Sectors' area of the non-volatile memory so that the system program does not affect the external device, such as a computer, and have a separate program for accessing the area where the system program is stored. There is no need to do this.

Claims (7)

A method of driving a system program stored in the nonvolatile memory in a system including a non-volatile memory, a volatile memory, and a controller controlling the nonvolatile memory and the volatile memory. (a) checking whether boot header information is valid in the controller; (b) if the boot header information is valid, initializing an internal register of the controller using the boot header information, and executing a startup program for system initialization; (c) checking whether the system program stored in the 'Not Used Sectors' area of the nonvolatile memory is valid; (d) if the system program is valid, moving the system program to an address of the volatile memory included in the boot header information; And (e) driving the system by executing the system program transferred to the volatile memory in the controller; And a system program stored in the nonvolatile memory. The method of claim 1, The 'Not Used Sectors' region is a region located between the Master Boot Record (MBR) and the 'Reserved Sectors' region of the nonvolatile memory. The method of claim 1, In step (a), And verifying whether the boot header information is valid by checking a header area checksum result value recorded in a 'header area checksum' item of the boot header information. The method of claim 1, In step (c), And verifying whether the system program is valid by checking a code area checksum result value recorded in the 'Code Area Checksum' item of the boot header information. The method of claim 1, The boot header information is nonvolatile, characterized in that the bit of item C is set to '1' to perform step (c), and the bit of item L is set to '1' to perform step (d). A method of running a system program stored in memory. The method of claim 1, In step (d), And moving the system program to an address of the volatile memory recorded in the 'Main Code Start Address' item of the boot header information. The method of claim 1, And wherein the nonvolatile memory includes one or more of NAND-FLASH, Serial-FLASH, and a hard disk.

Images