EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 85 of 197

FIGURE 3 Flash Space Symbol Table (stripped) F.ile decompression method Flash Space RAM Space f ~ .rodata secti~~ ... ........... : data section : .data section I .data section I I ................ J.~ I .text section Ii : · · ·· ·· ··· ····· ·· ·· f·~ File and Section Headers File and Section Headers Transfer of one ELF, COFF, or AOUT file from Transfer of one ELF, COFF, our AOUT file from TFS to RAM without using decompression. TFS to RAM using decompression. othe r autobootable fi le in TFS. ACl1.1ally, it is run prior to the monitor having completed its own initializa- tion. This is done so that the execu- tio n of monrc can be used to configure the monito r as it starts up. Refer to the source code for furth er details on the monrc fil e. The remaining autobootable fil es are run after the mo nitor has com- pleted initialization. They will be run in alphabetical order, so the order in which they are placed in TFS doesn 't matter. The o rde r in which they ar e listed by "tfs Is" (alphabetically) is the o rder in which they wi ll be executed, as shown in Table 2. In Table 2, the order of autoboot execution would be monrc, boot_diag, and ias_app. All other fi les listed are simply data fil es used by the applica- tion. The two autobootable attributes supported are "B" and "b," both of which will run at startup; but the "B" type will query the user at the console po rt, providing an oppo rtuni ty to abort the autoboot of that fi le. Both scripts and binary executables can be configured with autoboot enabled. fl ags What is an "in-place-modifiable" me? Typically, when a fil e is mod ified, the original fi le is marked as deleted , and the new versio n of the fil e is append- ed to the end of th e list of fil es cur- rently stored in TFS. This can involve a relatively large amount 0(" overhead if the modification to be made is triv- ial. As an alternative, a fil e can be cre- ated as an "in-place-modiliable" fi le, which means that the API provides a means by which a fil e can be modifi ed without the typical deletion/ re-ue- ation step. Creating the fi le as in- place-modifiable and specifying the fi le to be of some size does this. The space is then allocated in TFS fo r this fi le, but the fl ash is all left in an erased state . This usually means that the bytes in the fl ash al-e a ll Oxff (usually, bits in flash can be cleared on a bit-by- bit bas is, but to reset them, an entire secror must be e rased) . Al l subse- quent writes to th is fil e, th en, al-e done d irectly to the currently allocat- ed fl ash instead of to a new block of fl as h. Obviously th is puts some responsibi lity back on the program- mer, but it can pote ntially save quite a bit of overhead if necessary. 84 DECEMBER 2000 Embedded Systems Programming .text sec:;~: -I: II I i per-sector compression !' Ii .rodata sectio~/( • ..... RAM Space "--=--- --~ I .rodata section i' .( {' - .... .: .... ':,i .data section I .~ j, ~' .data section " ........... . .text section .. ··'1···· ···· II .text section .J .. ~ User levels The moni tor supports tlle concept of user leve ls. At any given time, tllere is an active user level. TFS SUPP0rlS the abi lity to store a Iile at a particular user level, then limit acces of that fi le based on the user level at the time of the access. The access can be limited to read-only or not even readable. This means that certain fi les (and executa- bles) can be configured to be accessi- ble only at cerlain user levels. Since each user level is attainable only via password, a system can be built at user level 3, then lowered to use r level 2, 1, or 0 and provide a certain degree of protection from unauthorized acces . File decompression A typical application fi le will be COFF, ELF, o r a.out. Each of these exe- cutable fi le formats has multiple sec- tions of text and data tllat must be transferred out of the nash space in which the file resides, and into some RAM space in which the application was bui lt to run. These files are inflat- ed by decompressing each of the sec- tions within the fi le from flash, d irect- ly into the RAM pace for which tlle section is destined. This "section-at-a- time" decompression eliminates the need to decompress the entire fi le into some block of memo ry, then load from that block into the actual memo- ry space for which the image was buil t. This mechanism requires some post processing of the final applica- tion fi le buil t on a host using the ELF, COFF, and a.out support tools. Two diffe re nt decompression methods are supported : Huffman and zlib. Each method has its own set of advantages and d isadva ntages. Using th e Huffman decompressor requiresjust a small extension to the monitor foot- print (3KB to 5KB) and no additional memory for malloc, but typical com- pl-ession is only about 15% to 20%. Using the public domain zlib utiliti es requires a larger extension to the moni tor footprint (35KB to 40KB) and additional heap space (see app- note on heap space expansion for fi le

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13