WO2006010715A2

WO2006010715A2 - Application firmware library

Info

Publication number: WO2006010715A2
Application number: PCT/EP2005/053407
Authority: WO
Inventors: Stefan Basler
Original assignee: Deutsche Thomson Brandt GmbH; Thomson Licensing SAS
Current assignee: Deutsche Thomson Brandt GmbH; Thomson Licensing SAS
Priority date: 2004-07-30
Filing date: 2005-07-15
Publication date: 2006-02-02
Anticipated expiration: 2007-01-30
Also published as: WO2006010715A3

Abstract

The present invention relates to a method for storing application firmware, and to a system having firmware which is stored in accordance with this method. According to the invention, a method for storing application firmware in a system having boot code memory (5) and application firmware memory (4) includes the step of storing parts of the application firmware as library functions in the boot code memory (5).

Description

Application firmware library

The present invention relates to a method for storing application firmware, and to a system having firmware which is stored in accordance with this method.

Fig. 1 depicts a system block diagram of a processing system 1, which is built of a central processing unit (CPU) 2, a couple of memory blocks 3, 4, 5, and further peripheral blocks 6 (SoC, System on Chip) . The memory blocks 3, 4, 5 and the peripheral blocks 6 are memory-mapped to the linear address space of the CPU 2 and accessible at all time. This is shown in the memory map in Fig. 2. Assuming that the memory block 4 holding the application code is a volatile memory, e.g. RAM type, for such a system 1 usually a small non-volatile memory block 5 (ROM type) is employed, which holds a boot code to upload the application code from an off-chip non-volatile memory 7 to the on-chip volatile memory 4 on power-up of the system. Such configurations are found for example as prototype systems, but also where on-chip, non-volatile, programmable memory (e.g. EPROM, EEPROM, Flash EEPROM type) is not feasible, but on-time programming is required.

For the above mentioned cases there is the problem that at the time the hardware configuration needs to be defined exactly the final figures for the sizes of the memory blocks can only be estimated, e.g. because the firmware is not yet fully implemented. In addition, for many types of systems the application firmware keeps evolving until the system is no longer produced.

Redefining the sizes of the memory blocks with every chip iteration is not practicable, as this is a time consuming and costly process. Another issue to consider are the chip design related constraints for defining memory blocks. For example, memory blocks are ideally a power of two. Consequently, memory block sizes have to be defined at a very early stage of system development. Fixed size memory blocks will be at hand whereas only a best-guess figure is derived for the boot code and application code memory blocks 4, 5. Slightly bigger boot code memory 4 than estimated is feasible,, for ROM type memory is commonly smaller in die size than static RAM type memory and the die size is a major cost factor.

This may, in the end, lead to a configuration where the boot code ROM memory block 5 is bigger than actually required and the application firmware RAM memory block 4 is short for the (final) code. In other words, application firmware memory is always sparse, while boot code ROM is usually not completely used.

It is an object of the invention to propose a method for storing application firmware in a system having boot code memory and application firmware memory, which is capable of coping with a lack of application firmware memory.

According to the invention, the lack of application firmware memory is overcome by placing parts of the application firmware as library functions in the boot code memory block, which is not needed for the boot code itself, but available for the application firmware. These library functions can then be used for the application firmware, hence saving application firmware memory by the amount of library functions stored in the boot code memory.

For a better understanding the invention shall now be ₀ explained in more detail in the following description with reference to the figures. It is understood that the invention is not limited to this exemplary embodiment and that specified features can also expediently be combined and/or modified without departing from the scope of the present invention. In the figures: Fig. 1 depicts a system block diagram of a processing system according to the invention;

Fig. 2 shows a memory map of a CPU of the processing system; and

Fig. 3 schematically depicts application firmware library functions stored in the boot code ROM memory.

Fig. 3 schematically depicts application firmware library functions stored in the boot code ROM memory 5. In the boot code ROM memory 5 a certain area 8 is used for the boot code, while the remaining area 9 is available for application firmware library functions. Usually at the latest at the second iteration of a chip design there are a plurality of stable application firmware functions at hand, which can be stored in the boot code ROM memory 5 and allow to make good use of the approach according to the invention. At this time it is more sensible to change only the ROM code of the boot code ROM memory and to retain the sizes of all memory blocks. Just changing the ROM code is much less time consuming and much cheaper than adapting memory block sizes.

According to the invention, an application firmware library is created at the time the boot code is released. The library functions are taken into account for application firmware coding. In case a library function is outdated at the time of application firmware development, it is simply not used. However, advantageously as many library functions as possible are employed since this is a major factor to reduce the application firmware code size relative to the size of the application firmware RAM memory block 4 available.

Claims

1. Method for storing application firmware in a system having boot code memory (5) and application firmware memory (4) , including the step of storing parts of the application firmware as library functions in the boot code memory (5) .

2. Method according to claim 1, wherein the application firmware memory (4) is a RAM memory.

3. Method according to claim 1 or 2, wherein the boot code memory (5) is a ROM memory.

4. Method according to one of claims 1 to 3, further including the step of memory-mapping the memories (4, 5) to the address space of a processing unit (2) .

5. Method according to one of claims 1 to 4, wherein the boot code uploads at least part of the application code from an off-chip non-volatile memory (7) to the on-chip application firmware memory (4) .

6. System having boot code memory (5) and application firmware memory (4) , characterized in that parts of the application firmware are stored as library functions in the boot code memory (5) .

7. System according to claim 6, wherein the application firmware memory (4) is a RAM memory.

8. System according to claim 6 or I₁ wherein the boot code memory (5) is a ROM memory.

9. System according to one of claims 6 to 8, wherein the memories (4, 5) are memory-mapped to the address space of a processing unit (2) .

10. System according to one of claims 6 to 9, further including an off-chip non-volatile memory (7) from which the boot code uploads at least part of the application code to the on-chip application firmware memory (4) .