WO2008054132A1

WO2008054132A1 - Terminal having platform library dynamic linking function and method of controlling the same

Info

Publication number: WO2008054132A1
Application number: PCT/KR2007/005422
Authority: WO
Inventors: Jung Yun Won; Jong Bae Kim; Hoo Jong Kim
Original assignee: Sk Telecom Co., Ltd.
Priority date: 2006-10-31
Filing date: 2007-10-31
Publication date: 2008-05-08
Also published as: KR20080038970A; KR101273914B1

Abstract

The present invention relates to a terminal having a platform library dynamic linking function and a method of controlling the terminal. The terminal includes a first storage medium, which is non- volatile memory for configuring platform functions, located in an RO region, as modules, and placing values of respective platform functions, configured as modules, in stub function blocks of an RW region. A second storage medium is volatile memory for loading stub function block data into an RW region when the stub function block data is received from the RW region of the first storage medium together with execution data. A control unit performs control such that an execution program located in the RW region of the first storage medium and the stub function blocks are loaded, an address value of an API to be executed is searched for in the stub function blocks, and linking is performed.

Description

TERMINAL HAVING PLATFORM LIBRARY DYNAMIC LINKING FUNCTION AND METHOD OF CONTROLLING THE SAME

Technical Field

[1] The present invention relates, in general, to a terminal having a platform library dynamic linking function and a method of controlling the terminal, and, more particularly, to a terminal having a platform library dynamic linking function and a method of controlling the terminal, which configure the functions of platforms, located in the RO region of ROM of the terminal, as modules, record the actual addresses of the functions, configured as modules, in the stub function blocks of an RW region, retrieve the actual addresses of the functions from the stub function blocks at the time of performing loading into RAM, and perform linking to the locations corresponding to the actual function addresses. Background Art

[2] Generally, a communication function, which allows a traveling person to exchange various types of data, such as characters, numbers, and images, with the other party using his or her mobile terminal enabling wireless transmission or reception, in a wireless manner through a base station system, is called wireless data communication. Such wireless data communication is a mobile communication system for bid- rectionally exchanging or searching data in travel through various types of terminals, for example, a cellular phone, a portable computer, a fax machine, and a credit card checker.

[3] However, in the terminal of the mobile communication system, a region for a manufacturing company (Original Equipment Manufacturer: OEM) that produces the terminal is included in an operating system for managing internal memory, and a region for Wireless Internet Platform for Interoperability (WIPI), managed by a network operator that operates the communication network of such s terminal, is also included.

[4] Further, when the conventional terminal uses an application to execute a set application program, the application program uses the Application Program Interface (API) of an OEM platform or a WIPI platform. Such an API is an interface allowing an application program to use the function of other programs, such as a computer OS, or a Database Management System (DBMS), and is also called an application programming interface. Typically, the application program interface is abbreviated to "API". In practice, the term "API" means a set of functions for defining the functions of an OS or the like and methods for utilizing the functions. Application programs may use various functions provided in the OS or the like using the API. Further, the ROM of the terminal for storing the above -described platform information is implemented using typical NOR flash memory.

[5] The above -described terminal having a platform loading function is described below with reference to FIG. 1. A terminal 74 includes Read-Only Memory (ROM) 71, Random- Access Memory (RAM) 72, and a control unit 73. The ROM 71 is nonvolatile memory divided into a Read-Only (RO) region, a Read- Write (RW) region, and a Zero-Initialized (ZI) region, and is configured such that executable codes, in which the address values of statically linked application functions are stored, are located in the RO region, and a phone Basic Input/Output System (BIOS) or application programs for platform operation are stored in the RW region in an embedded form. The RAM 72 is volatile memory for storing internally processed temporary data, including execution data of the phone BIOS or the application programs loaded from the ROM 71, and is divided into an RW region, a ZI region, and a heap region. The control unit 73 performs control such that a phone BIOS or an application program set by a user is loaded into the RW region of the RAM 72, and such that the function of a platform, for example, an OEM platform or a WIPI platform, is executed through APIs.

[6] Meanwhile, the loading operation of the conventional terminal having the platform loading function is described. First, when a system is turned on, the control unit 73 of the terminal 74 performs boot. When a terminal user executes his or her desired application program, for example, a game program provided in the WIPI region, or an application program having a calculator function provided in another OEM region, using a keypad 75, the control unit 73 loads all libraries related to that application into the RAM 72 from the ROM 71.

[7] That is, when boot is performed or a program is executed, the control unit 73 of the terminal 70 loads libraries related to boot or to the program into the RAM 72. For example, OS and application programs located in the RW region of the ROM 71 are stored in the form of images, and are copied to the RW region of the RAM 72 at the same time that boot is performed or the program is executed, so that a RAM disk is created, and the OS and the application programs, for example, OEM applications or WIPI applications, are executed on the RAM dsk. Further, information located in the ZI region of the ROM 71, for example, size information, is also loaded into the ZI region of the RAM 72, together with the information located in the RW region.

[8] In this case, executable codes having address values of statically linked application functions, which are located in the RO region of the ROM 71, are directly executed in the ROM 71, without being loaded into the RAM 72.

[9] Therefore, when a required API is called to execute the loaded program, the control unit 73 of the terminal 70 finds the executable codes of a library related to that API from the executable codes located in the RO region of the ROM 71, and thus calls and uses the API.

[10] Meanwhile, when an API is additionally upgraded in a WIPI platform or an OEM platform, the conventional terminal having the platform loading function must change the executable code of the newly upgraded API, that is, the addresses of functions. However, since the executable code having the address values of the functions is statically fixed, and is located in the RO region of the ROM 71, it cannot be changed, thus greatly decreasing the upgrade characteristics of a platform module. If it is desired to change the address values of the upgraded functions without regard to such characteristics, all of the executable code located in the RO region of the ROM 71 must be changed, and thus the costs incurred by the change are greatly increased. Disclosure of Invention Technical Solution

[11] Accordingly, the present invention has been made keeping in mind the above problems occurring in the prior art, and an object of the present invention is to provide a terminal having a platform library dynamic linking function and a method of controlling the terminal, in which the actual address of a platform function can be located in an RW region, and can be subsequently loaded into the region of RAM, so that the actual address of the platform function is substantially changed to call an API, thus greatly improving the dynamic linking characteristics of the platform function.

[12] Another object of the present invention is to provide a terminal having a platform library dynamic linking function and a method of controlling the terminal, in which the actual address of a platform function can be loaded from an RW region into the region of RAM, so that a new function can be called by replacing the address of the platform function with the address located in the RAM region at the time of the update, thus maximizing the update characteristics of the terminal. Advantageous Effects

[13] The present invention is advantageous in that the functions of platforms located in the RO region of the ROM of a terminal are configured as modules, actual addresses of the functions, configured as modules, are recorded in the stub function blocks of an RW region, the actual function addresses are retrieved from the stub function blocks at the time of performing loading into RAM, and linking to the locations corresponding to the actual function addresses is performed, so that the actual addresses of the platform functions can be substantially changed to call an API, thus greatly improving the dynamic linking characteristics of the platform functions.

[14] Further, the present invention is advantageous in that the actual addresses of platform functions can be loaded from an RW region into the region of RAM, so that the actual addresses of the platform functions can be replaced with the addresses located in the RAM region at the time of the update, and new functions can be called, thus maximizing the update characteristics of the terminal. Brief Description of the Drawings

[15] The above and other objects, features and other advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

[16] FIG. 1 is a diagram showing a conventional terminal having a static linking function;

[17] FIG. 2 is a diagram showing a terminal having a platform library dynamic linking function according to the present invention;

[18] FIG. 3 is a diagram showing an embodiment of the present invention; and

[19] FIG. 4 is a flowchart showing a control method according to the present invention.

Best Mode for Carrying Out the Invention

[20] In accordance with an aspect of the present invention to accomplish the above objects, there is provided a terminal having a platform library dynamic linking function, comprising a first storage medium, which is non-volatile memory for configuring platform functions, located in a Read-Only (RO) region, as modules, and placing values of respective platform functions, configured as modules, in stub function blocks of a Read- Write (RW) region; a second storage medium, which is volatile memory for loading stub function block data into an RW region when the stub function block data is received from the RW region of the first storage medium together with execution data; and a control unit for performing control such that an execution program located in the RW region of the first storage medium and the stub function blocks are loaded, an address value of an Application Program Interface (API) to be executed is searched for in the stub function blocks, and linking is performed.

[21] In accordance with another aspect of the present invention to accomplish the above objects, there is provided a method of controlling a terminal having a platform library dynamic linking function, comprising a function loading step of loading a stub function block from a Read- Write (RW) region of a first storage medium (Read-Only Memory: ROM) into an RW region of a second storage medium (Random- Access Memory: RAM), together with execution data required for current execution when a specific function is set in the terminal; an actual function value search step of, after the function loading step, searching the stub function block, previously loaded into the RW region of the RAM, for an actual function value of a function located in a Read- Only (RO) region of the ROM, when the function previously located in the RO region of the ROM is intended to be executed so as to execute a loaded platform module; and a linking step of, after the actual function value search step, performing linking to a location corresponding to a found actual address value of the function using the actual address value, and calling an API to be currently executed, thus executing content of the platform module. Mode for the Invention

[22] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

[23] As shown in FIG. 2, the present invention includes a first storage medium 5, a second storage medium 6, and a control unit 7. The first storage medium 5, which is non- volatile memory (Read-Only Memory: ROM) (hereinafter referred to as 'ROM'), configures platform functions, located in the Read-Only (RO) region in the memory area divided into the RO region IA, a Read- Write (RW) region 2A, and a Zero- Initialized (ZI) region 3A, as modules, places the values of respective functions 1 to N of the platform functions, configured as modules, in the stub function blocks 4 of the RW region, and stores the phone BIOS or application programs required for platform operation.

[24] The second storage medium 6, which is volatile memory (Random Access Memory:

RAM) (hereinafter referred to as 'RAM'), loads execution data of a phone Basic Input/ Output System (BIOS) or an application program from the first storage medium 5, together with the stub function blocks 4, changes the content of the stub function blocks 4 at the time of the update, and temporarily stores data processed through the execution of the stub function blocks, the second storage medum 6 being divided into an RW region 2B, a ZI region 3B, and a Heap region.

[25] The control unit 7 performs control such that a phone BIOS or an application program, set by a user, and the stub function blocks 4 are loaded into the RW region 2B of the ROM 6, the address value of an API to be executed is searched for in the stub function blocks 4, and linking to the API is performed. Further, the control unit 7 performs control such that, when a platform module is updated, the address value of a new function, which is desired to be changed, is changed and replaced in the stub function blocks 4 located in the RW region 2A.

[26] In this case, the first storage medum 5, which is non-volatile memory (ROM), may be implemented using NOR flash memory.

[27] Further, the terminal 8 can be a Personal Digital Assistant (PDA), a notebook computer, a Personal Computer (PC), or a mobile phone, each provided with a Rado Frequency (RF) module.

[28] Each of the stub function blocks 4 is located in the RW region 2A of the ROM 5, and is configured to store the actual address values of APIs searched for by the functions, which are configured as modules and are located in the RO region IA of the ROM 5.

[29] Meanwhile, the terminal 8 further includes an RF module unit 10 for processing a rado call signal (includng a multimeda signal) includng video and audo signals that are transmitted or received through the terminal 8 via a mobile communication network system 9 in response to a transmission control signal from the main control unit 7, a dsplay 11 for externally dsplaying various types of data processed by the terminal 8 in response to a dsplay function control signal from the main control unit 7, a codec unit 11 for converting an analog audo signal, input through a microphone 12, into a dgital signal, or converting a dgital audo signal into an analog signal and outputting the converted signal in response to a call connection control signal from the main control unit 7, and a key panel unit 14 connected to one end of the main control unit 7 and configured to input a function setting signal, input by the user, to the main control unit 7.

[30] Next, the control method applied to the above-described terminal is described.

[31] As shown in FIG. 4, the process of the method of the present invention proceeds from an initialization step S 1 to a function setting determination step S2, in which whether a specific function, for example, an application program, has been currently set in the terminal is determined. If it is determined at the function setting determination step S2 that the specific function, for example, the application program, has not been currently set in the terminal, the process terminates the current step and proceeds to a standby state.

[32] However, if it is determined at the function setting determination step S2 that the specific function, for example, the application program, has been set in the terminal, the process proceeds to a function loading step S3, in which a stub function block is also loaded from the RW region of the ROM into the RW region of the RAM, together with execution data of a phone BIOS or an application program required for current execution.

[33] Further, after the function loading step S3, the process proceeds to an actual function value search step S4, in which the actual address value of the function in the RO region of the ROM is searched for in the stub function block, previously loaded into the RW region of the RAM, when the function previously located in the RO region of the ROM is intended to be executed so as to execute the loaded platform module.

[34] Further, after the actual function value search step S4, the process proceeds to a linking step S5, in which linking to the location corresponding to the found actual address value of the function is performed using the found actual address value, and the actual API to be currently executed is called, and thus the content of the platform module is executed.

[35] Meanwhile, after the linking step S5, the process proceeds to a function update determination step S6, in which whether the platform module of the terminal has been updated is determined. If it is determined at the function update determination step S 6 that the platform module has not been updated, the process proceeds to an execution program termination determination step S8.

[36] In contrast, if it is determined at the function update determination step S6 that the platform module of the terminal has been updated, the process proceeds to a function update step S7, in which the address value of a new updated function is changed and replaced in a stub function block located in the RW region of the ROM. Thereafter, the method returns to the actual function value search step S4, thus repeating the loop.

[37] Meanwhile, at the execution program termination determination step S8, whether the execution of the currently executed specific function, for example, the application program, has been completed, is determined. In this case, if it is determined at the execution program termination determination step S 8 that the execution of the currently executed specific function, for example, the application program, has not been completed yet, in other words, that a program to be executed at the subsequent step still remains, the process returns to the actual function value search step S4, thus repeating the loop. However, if it is determined at the execution program termination determination step S 8 that the execution of the currently executed specific function, for example, the application program, has been completed, the process terminates the specific function, and proceeds to a standby state.

[38] In other words, when the user sets the execution of, for example, an application program, provided in the terminal 8, the terminal 8 according to the present invention also loads the stub function block 4 from the ROM 5 into the RAM 6, together with execution data of the application program required for current execution.

[39] That is, when the program is set as described above, the control unit 7 of the terminal

8 allows the platform functions, which are configured as modules and are located in the RO region IA of the ROM 5, to be executed in the ROM itself, and allows stub function blocks 4 having the address values of respective functions 1 to n of the platforms, which are configured as modules and are located in the RW region 2A of the ROM 5, to be loaded into the RAM 6, together with a phone BIOS or an application program required for platform operation.

[40] Further, as described above, when the platform module is loaded and executed, a corresponding one of the functions 1 to n, located in the RO region IA of the ROM 5, is executed so as to call the currently executed API, and the actual function value of the executed function is searched for in the stub function blocks 4 loaded into the RW region 2B of the RAM 6.

[41] In this case, the control unit 7 performs linking to the location of the API corresponding to the actual address value of the currently executed function using the actual address value of the currently executed function found in the stub function blocks 4, and calls the actual API to be currently executed, thus executing the content of the platform module.

[42] In this case, when some of the platform modules are updated, for example, when the address value of a predetermined function 2, located in the RO region IA of the ROM 5, is updated, as shown in FIG. 3, the main control unit 7 of the terminal 8 updates the address value by actually changing the address value of the function 2 in the stub function block 4 located in the RW region 2A of the ROM 5, without changing the address value in a corresponding one of the functions 1 to n located in the RO region IA of the ROM 5.

[43] In this case, unlike the conventional static linking method, the actual address values of functions located in the RO region IA can be freely updated through the stub function blocks 4 located in the RW region 2A, in which content can be changed. [44] Meanwhile, when the address value of a specific platform module is changed through the update process, the main control unit 7 of the terminal 8 applies the changed address value to the execution process, thus executing again the above -described procedure for searching stub function blocks.

[45] Therefore, the method of the present invention is performed by searching the stub function blocks 4 for a required library value having an actual API, by dynamically linking the library value, and by calling the API, at the time at which the actual API is required to be called while repeating the above process, until the last step of the set application program.

[46] In this case, when the application program of the terminal 8 is executed, the main control unit 7 transmits an audio signal to the microphone 12 through a codec unit 13 while displaying executed content on the display 11. When an external radio call is received through the RF module unit 10, the main control unit 7 of the terminal 8 provides notification of the radio call through the display 11 or the microphone 12. Further, when the user of the terminal 8 desires to answer the call, the main control unit 7 transmits a response call to the other party's terminal 15 through the mobile communication network system 9, thus performing typical communication. Industrial Applicability

[47] As described above, the present invention is advantageous in that the functions of platforms located in the RO region of the ROM of a terminal are configured as modules, actual addresses of the functions, configured as modules, are recorded in the stub function blocks of an RW region, the actual function addresses are retrieved from the stub function blocks at the time of performing loading into RAM, and linking to the locations corresponding to the actual function addresses is performed, so that the actual addresses of the platform functions can be substantially changed to call an API, thus greatly improving the dynamic linking characteristics of the platform functions.

[48] Further, the present invention is advantageous in that the actual addresses of platform functions can be loaded from an RW region into the region of RAM, so that the actual addresses of the platform functions can be replaced with the addresses located in the RAM region at the time of the update, and new functions can be called, thus maximizing the update characteristics of the terminal.

[49] Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.

Claims

[1] A terminal having a platform library dynamic linking function, comprising: a first storage medium, which is non-volatile memory for configuring platform functions, located in a Read-Only (RO) region, as modules, and placing values of respective platform functions, configured as modules, in stub function blocks of a Read- Write (RW) region; a second storage medium, which is volatile memory for loading stub function block data into an RW region when the stub function block data is received from the RW region of the first storage medium together with execution data; and a control unit for performing control such that an execution program located in the RW region of the first storage medium and the stub function blocks are loaded, an address value of an Application Program Interface (API) to be executed is searched for in the stub function blocks, and linking is performed.

[2] The terminal according to claim 1, wherein the control unit is performed such that, when a platform module is updated, an address value of a new function to be changed is changed and replaced in a stub function block located in the RW region of the first storage medium.

[3] The terminal according to claim 1, wherein the second storage medium updates content of a stub function block, changed when an update is performed, and temporarily stores data that is executed again.

[4] The terminal according to claim 1, wherein the first storage medium is NOR flash memory.

[5] The terminal according to claim 1, wherein the terminal is one of a Personal

Digital Assistant (PDA), a notebook computer, a Personal Computer (PC), and a mobile phone, each provided with a Radio Frequency (RF) module.

[6] The terminal according to claim 1, wherein the stub function blocks are located in the RW region of the first storage medium, and individually store actual address values searched for by the functions, configured as modules and located in the RO region.

[7] A method of controlling a terminal having a platform library dynamic linking function, comprising: a function loading step of loading a stub function block from a Read- Write (RW) region of a first storage medium (Read-Only Memory: ROM) into an RW region of a second storage medium (Random-Access Memory: RAM), together with execution data required for current execution when a specific function is set in the terminal; an actual function value search step of, after the function loading step, searching the stub function block, previously loaded into the RW region of the RAM, for an actual address value of a function located in a Read-Only (RO) region of the ROM, when the function previously located in the RO region of the ROM is intended to be executed so as to execute a loaded platform module; and a linking step of, after the actual function value search step, performing linking to a location corresponding to a found actual address value of the function using the actual address value, and calling an API to be currently executed, thus executing content of the platform module.

[8] The method according to claim 7, wherein the linking step comprises a function update step of changing and replacing an address value of a new updated function in the stub function block located in the RW region of the first storage medium when the platform module of the terminal is updated, and returning to the actual function value search step, thus repeating a loop.