EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 83 of 197

TABLE 1 Auto-boot AOUT Compressed In-place-modifiable Unreadable e b Auto-boot with query B COFF ELF C E A c I u not File is to be run at boot time File is run at boot time, after querying user COFF file format ELF file format AOUT file format File is compressed File is in-place-modifiable File is not readable when monitor is below required user level __ --':!i 0ur different user levels TABLE 2 Output of "tfs Is" command form.html ias_app index.html info1 .html info2 .html lucentiogo.gif monrc 5976 6099 109358 20222 466 792080 442 1053 734 1680 823 the RAM is volatile and may have been corrupted. A more practical app roach is to provide a means of defragme ntation that is robust eno ugh to deal with the possibility of sys tem reset durin g defragmenta tion. For th is approach, no large block of RAM is needed, but one non-volatil e block of memo- ry (at least as large as the largest sec- to r that TFS cove rs) must be pre- allocated to the de fl-agme nta tio n process. In TF , th is block of memo- ry is the secto r in the fl ash space immediately fo llowi ng the las t sector used by TFS fo r fi le sto rage. Because this space is likely to be smalle r than the amount of space needed to store copies of all "non-dele ted" fil es, th e defragme nta tion proces gets quite a b i t more com p i icated because it must now be done in chunks instead of all at o nce. T he advantage of th is is tha t the defragmentation process ca n be restarted a t any time; hence, there is no cor rup tion as a resu lt ofa power hi t or reset. The one disad- vantage of this technique is that the Ox80040c1c Ox8004921 c Ox8004243c Ox8004004c Ox80155a7c Ox8004026c Ox8004047c Ox800408ec Ox8004738c Ox80154d2c suppor ts multiple devices that are not necessari ly in con tiguous address space. Each device appears to the user as a d irectory, so any file can be stored in any device (limited by the size of the device, of course), but a fi le cannot span acro s multiple non- contiguous devices. Fo r each device, the same powe r-safe defragme ntation method is used; hence, if batte ry- backed RAM was on-board, it could be used to reduce the problem of flash-li fe expectancy (see below) if the re is a need to modify fi les at a high frequency. To "steer" a fi le to a particular BeE BeE e spare secto r is hit hard . I t is the sp are sector that is li kely to reach the tech nological lim it (number of erase cycles) and begin to fail. The po in t a t which this lim it is reached depends o n the device used, the number of sectors ded icated to TFS, and the rate at whi ch fi les are de le t- ed and rec rea ted . One maj o r improveme n t to this scheme ( to enhance the overall li fetime of the fl ash ) wou ld be to use ba tte ry- backed RAM instead of the spa re sec- to r, but obviously thi s is a luxury that is unli kely to be approved for a bud- ge t-sensi tive appl ication. Multiple storage devices ome hardware designs may have more than one device that could be used for fi le storage. TFS supports this. A bas ic sys tem has a boot moni- to r in the base of the flash; all remain- ing flash in that device is used by TFS and tha t's it. A more complicated sys- tem may co nta in ba tter y-backed RAM, a boot fl ash device, a seconda ry to rage fl ash device, and so on. TFS 82 DECEMBER 2000 Embedded Systems Programming device, each device has a unique pre- fix that, when made part of the file name, tells TFS that the fi le is destined for that device. If the prefIX is omitted from the filename, the default device is used for storage. Similarly, the fi le- system maintenance commands (tfs check, tfs clean, tfs freemen, and so on) can also be pointed to a particular device by specifyi ng the device prefIX . File attributes TFS supports fi le a ttributes. The attribute describes the file to TFS. It lets TFS know if the fil e tis to be auto- booted, whether it is execttaable or j ust data, the user level of the fi le, and so on. It is part of the fi le header created when the fi le is added to the fl ash. An attribute in the fi le header is simply a bit setting. At the command lin e, each attribute is assigned a le tter that is used to di splay (in a non-verbose mode) or create the fi les in TFS. Table 1 is a list of all the fil e attributes, including a bl-ief description of each. Auto-bootable files At some poin t in the monitor startup, the system looks to TFS for auto- boatable fi les. Three di ffe rent types of au tobootable fil es exist: two types es tablished by the attribu tes assigned to the fi le and one special case, the moni tor run-control (monrc) fi le. For the monre fi le to automatically run , it must exist and be marked as executable. It wi ll be run prior to any

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13